| 48ebe2c6928d8fd4dc97c8adb138c3440714dc89 |
24-Apr-2013 |
YK Jeffrey Chao <jechao@broadcom.com> |
Preload timeout and retry mechanism (1/3)
If the Preload process was stuck due to unknown hardware init failure,
a 8-second ENABLE_TIMEOUT timeout would be eventually expired in Java layer
at AdapterState and attempted to set BT state back to STATE_OFF.
However BluetoothManagerService did not handle this case accordingly and led
to state mis-matching between Java layer and BTIF at the end.
Add a timeout and retry mechanism to manage Preload process.
Clean up native space resource and explicitly report STATE_OFF back to Java
space when Preload did not go through.
bug 7566317
Change-Id: I99a225e524f2b951249618990a2d0a8a39b43ff3
rc/bt_hci_bdroid.c
rc/bt_hw.c
|
| 67e4077c23bb9cc045885ae01cc83b38faecb71b |
08-May-2013 |
YK Jeffrey Chao <jechao@broadcom.com> |
New call-in/-back functions for Controller to do vendor-specific shutdown (1/2)
A pair of asynchronous call-in and call-back API are added into the Host
Controller Vendor Lib interface (bt_vendor_lib.h). The caller calls this new
call-in function to inform the vendor module to perform vendor-specific
shutdown process (e.g. send HCI_RESET to BT Controller) before the caller calls
for interface cleanup() function. The vendor module is responsible for calling
call-back function to notify the caller completion of vendor-specific shutdown
process.
bug 7390787
Change-Id: I29e3c94ff78e17cdd7a06b44ae537e3b0ad1516d
nclude/bt_hci_bdroid.h
nclude/bt_vendor_lib.h
rc/bt_hci_bdroid.c
rc/bt_hw.c
|
| 260b515963a4ef73600cf5cd0b5496a608f118bc |
10-Apr-2013 |
Ying Wang <wangying@google.com> |
Add liblog
Bug: 8580410
Change-Id: I3475705985b5db2cd3a640f8bc0ef173378edad2
ndroid.mk
|
| ead3cde4bac0c3e32cd31f149093f004eef8ceeb |
06-Feb-2013 |
Ganesh Ganapathi Batta <ganeshg@broadcom.com> |
Initial version of BLE support for Bluedroid
Change-Id: I9825a5cef9be2559c34c2a529b211b7d471147cf
rc/userial.c
|
| 6ff9944c9dda368fd79ebdf8d6748fc4922eafec |
08-Feb-2013 |
Toshi Kikuchi <toshik@google.com> |
fix bt_hc_worker_thread() sometimes transmit more than num_hci_cmd_pkts
bt_hc_worker_thread() checks the controller's outstanding HCI
command credits (maintained in num_hci_cmd_pkts) and skips the rest
of the tx queue after it has used up the credits. But the skip
condition is not correct in the loop:
if ((tx_cmd_pkts_pending == TRUE) || (num_hci_cmd_pkts <= 0))
{
tx_cmd_pkts_pending = TRUE;
// skip the rest of the packets in the tx queue
...
}
Since num_hci_cmd_pkts doesn't change during the loop, this condition
never becomes true. As a result, all the HCI commands in the tx queue
are sent if num_hci_cmd_pkts > 0. That is why sometimes more than
num_hck_cmd_pkts are sent.
To check a correct skip condition, we should count how many HCI
command packets are being sent:
if ((tx_cmd_pkts_pending == TRUE) ||
(sending_hci_cmd_pkts_count >= num_hci_cmd_pkts))
sending_hci_cmd_pkts_count is incremented every time a HCI command is
pushed for sending. It should never go beyond num_hci_cmd_pkts.
Change-Id: I58101b2785fc3ab4171cdf22497ca97a3ae3124a
Signed-off-by: Toshi Kikuchi <toshik@google.com>
rc/bt_hci_bdroid.c
|
| 5738f83aeb59361a0a2eda2460113f6dc9194271 |
13-Dec-2012 |
The Android Open Source Project <initial-contribution@android.com> |
Snapshot cdeccf6fdd8c2d494ea2867cb37a025bf8879baf
Change-Id: Ia2de32ccb97a9641462c72363b0a8c4288f4f36d
ndroid.mk
nclude/bt_hci_bdroid.h
nclude/bt_hci_lib.h
nclude/bt_vendor_lib.h
nclude/hci.h
nclude/userial.h
nclude/utils.h
rc/bt_hci_bdroid.c
rc/bt_hw.c
rc/btsnoop.c
rc/hci_h4.c
rc/hci_mct.c
rc/lpm.c
rc/userial.c
rc/userial_mct.c
rc/utils.c
|