summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChen-Yu Tsai <wens@csie.org>2018-12-17 12:04:44 +0800
committerMarcel Holtmann <marcel@holtmann.org>2018-12-19 00:28:39 +0100
commit91927a9b351f9779e323be1fb4e219a5951b1649 (patch)
treec8cb0e68ead4e4fae9abfe1609930e3ec8586141
parent75d11676dccb643de1e850c8a29f5e9aa58157c0 (diff)
downloadtalos-op-linux-91927a9b351f9779e323be1fb4e219a5951b1649.tar.gz
talos-op-linux-91927a9b351f9779e323be1fb4e219a5951b1649.zip
Bluetooth: hci_bcm: Wait for device to come out of reset after power on
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-rw-r--r--drivers/bluetooth/hci_bcm.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index f2101038284e..538ce8059bff 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -256,6 +256,9 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered)
regulator_bulk_disable(BCM_NUM_SUPPLIES, dev->supplies);
}
+ /* wait for device to power on and come out of reset */
+ usleep_range(10000, 20000);
+
dev->res_enabled = powered;
return 0;
OpenPOWER on IntegriCloud