[PATCH v2 1/3] dt-bindings: net: bluetooth: Add broadcom-bluetooth
Stefan Wahren
stefan.wahren at i2se.com
Sun Aug 27 03:40:30 PDT 2017
Hi Marcel,
> Marcel Holtmann <marcel at holtmann.org> hat am 27. August 2017 um 12:23 geschrieben:
>
>
> Hi Stefan,
>
> >>>>> Thanks a lot for working on that, I've made a similar attempt a few
> >>>>> weeks ago but didn't manage to get it to work.
> >>>>>
> >>>>> The way it's hooked in our boards is a bit more complex though, even
> >>>>> if it could be because we're using a different part.
> >>>>>
> >>>>> In order to get it running we need:
> >>>>> - two clocks, called in the broadcom datasheets lpo and tcxo.
> >>>>> - three GPIOs, device wakeup, host wakeup and a shutdown GPIO (which
> >>>>> might be the BT_ON you were discussing about)
> >>>>> - two regulators called vbat and reg-en for us (I guess they're
> >>>>> meant to power the chip, and its registers >>
> >>>>> Do you know if you're also using those? Or could it be that it's just
> >>>>> hardwired to some non-gatable crystal / regulator on the RPI?
> >>>
> >>> Not on Pi3, but the three gpios and the clock are pretty common for
> >>> Broadcom bt controller (cf v4 of dt-bindings patch).
> >>
> >> once we get the GPIO expander driver upstream, I think we also need this for RPI 3 and Zero W. Right now we can just not do anything about this.
> >
> > AFAIK the Zero W doesn't have this GPIO expander. Would it be easier for you?
>
> I don’t understand the question. In general you want the BT_ON and wakeup GPIOs to be available so that you can have good power savings. If they are not there, then it is always powered. It works of course as shown with RPI 3 where the boot loader enables the GPIOs. Which means it is like the current support that we have in net-next.
the question was related to the point that all SoC GPIOs should be directly connected to the 43438. So using Zero W for development could be easier, because you don't need the GPIO expander driver. But generally i agree that it should work with RPI 3.
>
> On the other hand, the hci_bcm.c support for RPI 3 is essentially a support for all Broadcom devices using DT. It should be extended to support all sorts of boards. And once ACPI becomes serdev support, we can unify ACPI, platform and DT devices into a single code path.
>
> Regards
>
> Marcel
>
More information about the linux-rpi-kernel
mailing list