Re: Problem with re-loading hci_uart.ko on RPi3

[Stefan Wahren <stefan.wahren@i2se.com>]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 19. Februar 2018 um 19:58 ge=
schrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>>>>>> One option is of course to keep the max-speed in the DT at 1152=
00 Mbps. It would work, but seriously slow down the transport. Maybe this s=
hould be done until we get access to the GPIOs.
> >>>>>>> So I am convinced when we run on hardware that has no GPIO resour=
ces exposed (as it is with RPi right now), we should limit the operational =
speed to the initialization speed. And then my problem actually goes away. =
It also forces people to get the GPIOs exposed or they have to stick with a=
 slower HCI transport.
> >>>>>>=20
> >>>>>> We may also reset to initialization speed on module unload.
> >>>>>> This will allow multiple tests on the hardware, even if it does no=
t have GPIOs exposed.
> >>>>>=20
> >>>>> I prefer this solution instead of coding workarounds within the dev=
icetree.
> >>>>=20
> >>>> DT is actually for encoding workarounds for the hardware. If the GPI=
Os are not exposed, we are actually limited. However I am going to do that =
in the hci_bcm.c driver itself since it is a more wider problem. If the GPI=
O resources are not available, the device will actually not function. This =
is actually a valid assumption for all hardwired Bluetooth chips. They all =
have some GPIO or power control option. The only reason to not have GPIOs w=
ould be external development boards. So the RPi with the not exposed GPIOs =
is kinda broken hardware right now. That we got this far supporting Bluetoo=
th on it has to be considered pure luck :)
> >>>=20
> >>> only to make sure that we talking about the same, please take a look =
at my attempt for the RPi Zero W [1].
> >>>=20
> >>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i di=
dn't test the reload case yet.
> >>>=20
> >>> So after the implementation of the RPI firmware expander driver, we s=
till need this baudrate limitiation?
> >>>=20
> >>> Btw Baruch said that he will send a new version of his patch series s=
oon.
> >>>=20
> >>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a=
69f2e32d35827635b95cf966
> >>=20
> >> before you include "shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;=E2=
=80=9D we might need to figure out on how the BT_ON GPIO is working and wha=
t it is suppose to be doing. But otherwise the patch fro the Zero W looks r=
ight to me.
> >>=20
> >> Also keep in mind that the current 4.16-rc2 kernel will require the sh=
utdown-gpios and device-wakeup-gpios both to be available. We have not yet =
tested this when only shutdown-gpios is available. You might need to modify=
 bcm_get_resources and bcm_gpio_set_power to test this out.
> >=20
> > i think this contradicts to the binding documentation, which defines bo=
th as optional.
>=20
> the 4.15 kernel might be fine actually while the support for Apple hardwa=
re with Broadcom UART devices might have accidentally required this now. Ma=
ybe you just want to hack your kernel and see how it goes when just having =
the shutdown-gpios available.
>=20
> I am super curious if the firmware resets and falls back to the ROM state=
 or if something is actually kept.

since i don't have any schematics about the BT part, i simply retested my p=
atches against 4.15 on RPi Zero W.

modprobe -r hci_uart
modprobe hci_uart

works without any issues:

[  233.486208] Bluetooth: HCI UART driver ver 2.3
[  233.486258] Bluetooth: HCI UART protocol H4 registered
[  233.487189] hci_uart_bcm serial0-0: BCM irq: -22
[  233.488382] Bluetooth: HCI UART protocol Broadcom registered
[  233.641217] Bluetooth: hci0: BCM: chip id 94
[  233.642081] Bluetooth: hci0: BCM: features 0x2e
[  233.644283] Bluetooth: hci0: BCM43430A1
[  233.644321] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[  234.360569] Bluetooth: hci0: BCM (001.002.009) build 0325

After enabling bluetooth scanning i will see these error messages periodica=
lly:

[  815.939839] Bluetooth: hci0: last event is not cmd complete (0x0f)
[  831.302476] Bluetooth: hci0: last event is not cmd complete (0x0f)
[  847.303953] Bluetooth: hci0: last event is not cmd complete (0x0f)
[  863.305284] Bluetooth: hci0: last event is not cmd complete (0x0f)
[  879.306838] Bluetooth: hci0: last event is not cmd complete (0x0f)

Btw: Linus Wallej applied the GPIO expander driver

Stefan

>=20
> Regards
>=20
> Marcel
>