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:38 ge=
schrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>>>> One option is of course to keep the max-speed in the DT at 115200=
 Mbps. It would work, but seriously slow down the transport. Maybe this sho=
uld be done until we get access to the GPIOs.
> >>>>> So I am convinced when we run on hardware that has no GPIO resource=
s exposed (as it is with RPi right now), we should limit the operational sp=
eed 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 s=
lower 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 not =
have GPIOs exposed.
> >>>=20
> >>> I prefer this solution instead of coding workarounds within the devic=
etree.
> >>=20
> >> DT is actually for encoding workarounds for the hardware. If the GPIOs=
 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 GPIO =
resources are not available, the device will actually not function. This is=
 actually a valid assumption for all hardwired Bluetooth chips. They all ha=
ve some GPIO or power control option. The only reason to not have GPIOs wou=
ld be external development boards. So the RPi with the not exposed GPIOs is=
 kinda broken hardware right now. That we got this far supporting Bluetooth=
 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 didn=
't test the reload case yet.
> >=20
> > So after the implementation of the RPI firmware expander driver, we sti=
ll need this baudrate limitiation?
> >=20
> > Btw Baruch said that he will send a new version of his patch series soo=
n.
> >=20
> > [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69=
f2e32d35827635b95cf966
>=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 what i=
t is suppose to be doing. But otherwise the patch fro the Zero W looks righ=
t to me.
>=20
> Also keep in mind that the current 4.16-rc2 kernel will require the shutd=
own-gpios and device-wakeup-gpios both to be available. We have not yet tes=
ted this when only shutdown-gpios is available. You might need to modify bc=
m_get_resources and bcm_gpio_set_power to test this out.

i think this contradicts to the binding documentation, which defines both a=
s optional.

Stefan

>=20
> Regards
>=20
> Marcel
>