Hi Stefan, >>>>>>>>>>>>> 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 should be done until we get access to the GPIOs. >>>>>>>>>>> So I am convinced when we run on hardware that has no GPIO resources 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> I prefer this solution instead of coding workarounds within the devicetree. >>>>>>>> >>>>>>>> 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 have some GPIO or power control option. The only reason to not have GPIOs would 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 :) >>>>>>> >>>>>>> only to make sure that we talking about the same, please take a look at my attempt for the RPi Zero W [1]. >>>>>>> >>>>>>> Using the BT_ON signal as shutdown-gpio is not enough? I'm sorry i didn't test the reload case yet. >>>>>>> >>>>>>> So after the implementation of the RPI firmware expander driver, we still need this baudrate limitiation? >>>>>>> >>>>>>> Btw Baruch said that he will send a new version of his patch series soon. >>>>>>> >>>>>>> [1] - https://github.com/lategoodbye/rpi-zero/commit/e3085c093e56364a69f2e32d35827635b95cf966 >>>>>> >>>>>> before you include "shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;” we might need to figure out on how the BT_ON GPIO is working and what it is suppose to be doing. But otherwise the patch fro the Zero W looks right to me. >>>>>> >>>>>> Also keep in mind that the current 4.16-rc2 kernel will require the shutdown-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. >>>>> >>>>> i think this contradicts to the binding documentation, which defines both as optional. >>>> >>>> the 4.15 kernel might be fine actually while the support for Apple hardware with Broadcom UART devices might have accidentally required this now. Maybe you just want to hack your kernel and see how it goes when just having the shutdown-gpios available. >>>> >>>> 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 patches 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 periodically: >>> >>> [ 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) >> >> I really need to hook up the error messages into the btmon output since then we can trace where these are coming from. Anyway, can you btmon -w trace.log from before loading the module and this error showing up. > > I attached the log. According to dmesg this error happend only once during the trace. I will add bt_dev_err tracing to be include in btmon and that way we can figure out where that error happens. Or do you have a trace.log and dmesg -T where we can correlate it based on time. >>> Btw: Linus Wallej applied the GPIO expander driver >> >> That is awesome. Do you see any difference now if you hook up the GPIO in DT. Mind you to change the resources part to allow using only the shutdown GPIO and not having the device-wakeup GPIO. > > The RPi Zero W doesn't have a GPIO expander and the RPi 3 also uses the BT_ON line (via GPIO expander). So i don't expect any difference between them. So on the Zero W the BT_ON GPIO is exposed without the expander? And the 3 needs the expander? Is that how they are designed? I have Zero W here, but no toolchain available for it. >> Also let me guess, 4.15 is fine, but 4.16-rc1 or later fails because of the Apple changes. > > Didn't tried it yet. If you have a chance, please do. I think it needs a patch for 4.16-rc1 to make it work again. Otherwise I am happy that we finally can get the RPi working without btattach. Next step is to also read out and set the PCM configuration. 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
