Return-Path: Date: Wed, 7 Mar 2018 13:42:48 +0100 (CET) From: Stefan Wahren To: Marcel Holtmann Cc: Rob Herring , Lukas Wunner , Eric Anholt , Johan Hedberg , devicetree , Loic Poulain , Florian Fainelli , linux-rpi-kernel@lists.infradead.org, Mark Rutland , Phil Elwell , =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Danis?= , Linux Bluetooth mailing list , linux-arm-kernel@lists.infradead.org Message-ID: <2071508922.276811.1520426568577@email.1und1.de> In-Reply-To: <03B9ACBE-3ACA-40C4-9DA2-6A57D1AD96E0@holtmann.org> References: <1519567855-26105-1-git-send-email-stefan.wahren@i2se.com> <1519567855-26105-4-git-send-email-stefan.wahren@i2se.com> <84F7E645-59B4-4618-8C91-A5CD654E16A6@holtmann.org> <648118289.71086.1519593373795@email.1und1.de> <9D6209F2-5389-4F4E-844D-6A8683044F88@holtmann.org> <438185389.274708.1520422108782@email.1und1.de> <03B9ACBE-3ACA-40C4-9DA2-6A57D1AD96E0@holtmann.org> Subject: Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 List-ID: Hi Marcel, hi Loic, > Marcel Holtmann hat am 7. M=C3=A4rz 2018 um 13:12 g= eschrieben: >=20 >=20 > Hi Stefan, >=20 > >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/t= tyAMA0). > >>>>> This allows to automatically insert the bcm43438 to the bluetooth > >>>>> subsystem instead of relying on patched userspace helpers (hciattac= h). > >>>>>=20 > >>>>> In order to keep a debug UART we need to switch to uart1. > >>>>>=20 > >>>>> Signed-off-by: Stefan Wahren > >>>>> --- > >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++- > >>>>> 1 file changed, 13 insertions(+), 1 deletion(-) > >>>>>=20 > >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/bo= ot/dts/bcm2835-rpi-zero-w.dts > >>>>> index cf53436..b7f79f1 100644 > >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts > >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts > >>>>> @@ -131,6 +131,18 @@ > >>>>>=20 > >>>>> &uart0 { > >>>>> =09pinctrl-names =3D "default"; > >>>>> -=09pinctrl-0 =3D <&uart0_gpio14>; > >>>>> +=09pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>; > >>>>> +=09status =3D "okay"; > >>>>> + > >>>>> +=09bluetooth { > >>>>> +=09=09compatible =3D "brcm,bcm43438-bt"; > >>>>> +=09=09max-speed =3D <2000000>; > >>>>> +=09=09shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>; > >>>>> +=09}; > >>>>> +}; > >>>>=20 > >>>> is the shutdown GPIO working as expected with this hardware. So even= module unload and reload works fine? > >>>=20 > >>> Yes, unload and reload works fine.=20 > >>>=20 > >>>> Meaning we are getting back to the 115200 default baud rate on the U= ART? > >>>=20 > >>> I assume that, because reload works as expected.=20 > >>=20 > >> awesome. That is good news. > >>=20 > >> Since you said that the GPIO expander driver for the RPi 3 has been ac= cepted, did you test it there as well? If so, then it would be good to get = a patch that also provides shutdown-gpios for RPi 3. > >=20 > > after applying Loic's patch and the necessary patch for the RPi 3 dts f= ile (see below), i will get this output: > >=20 > > [ 4.873246] Bluetooth: HCI UART driver ver 2.3 > > [ 4.873260] Bluetooth: HCI UART protocol H4 registered > > [ 4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered > > [ 4.873751] Bluetooth: HCI UART protocol Broadcom registered > > [ 4.877279] uart-pl011 3f201000.serial: no DMA platform data > > [ 6.952382] Bluetooth: hci0: command 0xfc18 tx timeout > > [ 15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-= 110) > > [ 15.192312] Bluetooth: hci0: Failed to set baudrate > > [ 15.316415] Bluetooth: hci0: BCM: chip id 94 > > [ 15.318567] Bluetooth: hci0: BCM: features 0x2e > > [ 15.341538] Bluetooth: hci0: BCM43430A1 > > [ 15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000 > > [ 19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360 > > [ 274.713732] Bluetooth: hci0: command 0x0c14 tx timeout > > [ 274.714085] Bluetooth: hci0: Frame reassembly failed (-84) > > [ 317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f) > >=20 > > I don't see these errors on RPi Zero W. Maybe the reason for this is th= e lack of hardware flowcontrol on RPi 3. Or some of the downstream patches = on BlueZ must be adapted for the kernel [1]. > >=20 > > Btw the bcm43438 is detected even after unloading and reloading the dri= ver. But the timeout occurs also on driver reload. Reducing the baudrate to= 115200 doesn't help here. >=20 > maybe it needs some time after switching the hardware on. Have you tried = to sleep for a bit at the end of bcm_gpio_set_power? I will try, but this could also be an "issue" of the gpio expander driver. = AFAIK the expander is connected via I2C to the GPU. In case the mailbox rep= ly come before the I2C command has been handled by the GPIO expander, we ar= e running out of sync. >=20 > Can you also dump where the Frame reassembly fails. Or correlate that wit= h the btmon trace of which packets make its through. The 0x0c14 is Read Loc= al Name and maybe we actually have bit errors here. >=20 > In theory we could also run this hardware in 3-wire protocol mode. I just= do not know how to get that one started, but maybe that would be an option= if there is some sort of packet loss. However maybe this is really just so= me timing issue for the hardware to settle its baud rate. However I assume = that the firmware loading itself succeeds here. According to the link from my last email, the RPi 3 is using 3-wire protoco= l mode. Maybe we should detect the presence of "uart-has-rtscts" in the mas= ter node? In absence we better use 3-wire. Stefan >=20 > Regards >=20 > Marcel >=20 >=20 > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel