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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
