There is no guarantee that a fix delay is actually enough, because with
the BT_EN gpio, we only control activation of bluetooth on the chip. But
we don't know the status of the whole chip.
Also hciattach has anyway a timeout of 5 seconds, so 0.1 seconds does
probably not make a big difference in this regard.
So in order to make it the safest possible, we can only rely a failure
handling and retrying. The number 5 for retries has been defined since
repeated restart of the service with only 3 retries leads to failure
pretty quickly. At 4 there is no failure anymore. So with 5 we are sure
the risk of failure is really low.
BugzID: 70195
This package contains gpioset, gpiofind, etc
This tools are required to access the gpios from shell scripts.
Also fixes the RDEPENDS ${PN}
BugzID: 65420
Name the BT_EN gpio in the device tree when you want to use this service.
It has to be found with the command: "gpiofind BT_EN".
Signed-off-by: Lucien Mueller <lucien.mueller@netmodule.com>
The wifi and bluetooth chip ti wl18xx firmware files are handled by seperate
meta-netmodule-wlan layer.
BugzID: 67576
Signed-off-by: Ramon Moesching <ramon.moesching@netmodule.com>
It can happen that hciattach fails because of timeout.
Reexecuting the service in this case makes sure that the bluetooth
device is handled by bluetoothctl.
BugzID: 65391
The BLE connect needs too much time (>2s) which can trigger the kernel
to send an error. This is unwanted with the new firmware it works a
little better but an increase of the timeout to 5s in the kernel is
still necessary.
If bluetooth is used in non_st mode we can use the normal uart_hci
driver. This driver works much better and the whole setup is much
easier. We don't need the Shared Transfer stuff anyhow, because the
module does not have GPS or FM.
Alexandre Bard
Lucien Mueller
Ramon Moesching
Alexandre Bard
Patrick Zysset
Stefan Eichenberger