From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Eric Anholt To: Stefan Wahren , Marcel Holtmann Cc: Rob Herring , Lukas Wunner , Johan Hedberg , devicetree , Loic Poulain , Florian Fainelli , linux-rpi-kernel@lists.infradead.org, Mark Rutland , Phil Elwell , =?utf-8?B?RnLDqWTDqXJpYw==?= Danis , Linux Bluetooth mailing list , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave In-Reply-To: <2071508922.276811.1520426568577@email.1und1.de> 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> <2071508922.276811.1520426568577@email.1und1.de> Date: Wed, 07 Mar 2018 11:08:24 -0800 Message-ID: <87sh9bvh3r.fsf@anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Wahren writes: > Hi Marcel, > hi Loic, > >> Marcel Holtmann hat am 7. M=C3=A4rz 2018 um 13:12 = geschrieben: >>=20 >>=20 >> Hi Stefan, >>=20 >> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/= ttyAMA0). >> >>>>> This allows to automatically insert the bcm43438 to the bluetooth >> >>>>> subsystem instead of relying on patched userspace helpers (hciatta= ch). >> >>>>>=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/b= oot/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 { >> >>>>> pinctrl-names =3D "default"; >> >>>>> - pinctrl-0 =3D <&uart0_gpio14>; >> >>>>> + pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>; >> >>>>> + status =3D "okay"; >> >>>>> + >> >>>>> + bluetooth { >> >>>>> + compatible =3D "brcm,bcm43438-bt"; >> >>>>> + max-speed =3D <2000000>; >> >>>>> + shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>; >> >>>>> + }; >> >>>>> +}; >> >>>>=20 >> >>>> is the shutdown GPIO working as expected with this hardware. So eve= n 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 = UART? >> >>>=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 a= ccepted, 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 = file (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 t= he 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 dr= iver. But the timeout occurs also on driver reload. Reducing the baudrate t= o 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 reply come before the I2C command has been handled by the > GPIO expander, we are running out of sync. The mailbox command for setting GPIO state is synchronous in terms of sending the i2c command to the GPIO expander HW. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlqgOKgACgkQtdYpNtH8 nuhW/BAAhTztqF2dqtUznqHBnGcWKOAB5jcf5LOlL23Iv4xUBRRtm7u2Vy1Pg9Rf wl3A/R93Vsx06r6qx4DJsaLtp+akBeSc0+j9YBQiySTFB2lG6rYp8CQlfUr+IM0y 5UzP41+Bngx017pAsx7lwXF6h3gkek1ldlhrECQt/HjEehU5bjSBst47WQGswC7d 3CWSDzPQtOqRAp1N9iCNfJgopep+OprqDPVnWnhu92GfYsF52VUrGSpa8uZezBjp 5rB8SgZ5uhxmfpG7Ux28O+D1e4FViD6GOcTJrxydK+f+O4ad7rE4PyE68ATN4Az6 zW88bYzxHCgQSRbO+bXdyoJEyXsWu7h1rGi6eQNw4tr89MA+pwyQADqoTbY31JgX j9/AVwLecqdVyxOaHW9wJx5hvEChB8rJFuTfKNmcEA4zkdIFG+F6eJuGVkQuuxif D8dZHSGaaDDZ0l/Too+/Q+W2it1gonioQIzAzA9ANxGQsxIbLc4phXlsBpHA4jIt TivF/QaCyNc/8+f0KGOmrOvXMDLNUlu+KhqX2jIDzaL7KgrDNFbLfWRcPLcoASvs VOdCl+HCBqTmwON7Ru+XR2dChcg+ckrY2IFHXzrgbMBZd11ru5HRPc9zmdms62SD 4XfFNwflLtSjYvcUwtR8pJAbienbKFRudGGsHIhY1J+gVhiZH6g= =w778 -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric@anholt.net (Eric Anholt) Date: Wed, 07 Mar 2018 11:08:24 -0800 Subject: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave In-Reply-To: <2071508922.276811.1520426568577@email.1und1.de> 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> <2071508922.276811.1520426568577@email.1und1.de> Message-ID: <87sh9bvh3r.fsf@anholt.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Stefan Wahren writes: > Hi Marcel, > hi Loic, > >> Marcel Holtmann hat am 7. M?rz 2018 um 13:12 geschrieben: >> >> >> Hi Stefan, >> >> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0). >> >>>>> This allows to automatically insert the bcm43438 to the bluetooth >> >>>>> subsystem instead of relying on patched userspace helpers (hciattach). >> >>>>> >> >>>>> In order to keep a debug UART we need to switch to uart1. >> >>>>> >> >>>>> Signed-off-by: Stefan Wahren >> >>>>> --- >> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++- >> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-) >> >>>>> >> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/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 @@ >> >>>>> >> >>>>> &uart0 { >> >>>>> pinctrl-names = "default"; >> >>>>> - pinctrl-0 = <&uart0_gpio14>; >> >>>>> + pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>; >> >>>>> + status = "okay"; >> >>>>> + >> >>>>> + bluetooth { >> >>>>> + compatible = "brcm,bcm43438-bt"; >> >>>>> + max-speed = <2000000>; >> >>>>> + shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>; >> >>>>> + }; >> >>>>> +}; >> >>>> >> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine? >> >>> >> >>> Yes, unload and reload works fine. >> >>> >> >>>> Meaning we are getting back to the 115200 default baud rate on the UART? >> >>> >> >>> I assume that, because reload works as expected. >> >> >> >> awesome. That is good news. >> >> >> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, 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. >> > >> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output: >> > >> > [ 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) >> > >> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1]. >> > >> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here. >> >> 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 reply come before the I2C command has been handled by the > GPIO expander, we are running out of sync. The mailbox command for setting GPIO state is synchronous in terms of sending the i2c command to the GPIO expander HW. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave Date: Wed, 07 Mar 2018 11:08:24 -0800 Message-ID: <87sh9bvh3r.fsf@anholt.net> 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> <2071508922.276811.1520426568577@email.1und1.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1656647127498595809==" Return-path: In-Reply-To: <2071508922.276811.1520426568577@email.1und1.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Stefan Wahren , Marcel Holtmann Cc: Mark Rutland , devicetree , Florian Fainelli , Johan Hedberg , Lukas Wunner , Phil Elwell , Linux Bluetooth mailing list , Rob Herring , linux-rpi-kernel@lists.infradead.org, =?utf-8?B?RnLDqWTDqXJpYw==?= Danis , Loic Poulain , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org --===============1656647127498595809== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stefan Wahren writes: > Hi Marcel, > hi Loic, > >> Marcel Holtmann hat am 7. M=C3=A4rz 2018 um 13:12 = geschrieben: >>=20 >>=20 >> Hi Stefan, >>=20 >> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/= ttyAMA0). >> >>>>> This allows to automatically insert the bcm43438 to the bluetooth >> >>>>> subsystem instead of relying on patched userspace helpers (hciatta= ch). >> >>>>>=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/b= oot/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 { >> >>>>> pinctrl-names =3D "default"; >> >>>>> - pinctrl-0 =3D <&uart0_gpio14>; >> >>>>> + pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>; >> >>>>> + status =3D "okay"; >> >>>>> + >> >>>>> + bluetooth { >> >>>>> + compatible =3D "brcm,bcm43438-bt"; >> >>>>> + max-speed =3D <2000000>; >> >>>>> + shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>; >> >>>>> + }; >> >>>>> +}; >> >>>>=20 >> >>>> is the shutdown GPIO working as expected with this hardware. So eve= n 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 = UART? >> >>>=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 a= ccepted, 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 = file (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 t= he 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 dr= iver. But the timeout occurs also on driver reload. Reducing the baudrate t= o 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 reply come before the I2C command has been handled by the > GPIO expander, we are running out of sync. The mailbox command for setting GPIO state is synchronous in terms of sending the i2c command to the GPIO expander HW. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlqgOKgACgkQtdYpNtH8 nuhW/BAAhTztqF2dqtUznqHBnGcWKOAB5jcf5LOlL23Iv4xUBRRtm7u2Vy1Pg9Rf wl3A/R93Vsx06r6qx4DJsaLtp+akBeSc0+j9YBQiySTFB2lG6rYp8CQlfUr+IM0y 5UzP41+Bngx017pAsx7lwXF6h3gkek1ldlhrECQt/HjEehU5bjSBst47WQGswC7d 3CWSDzPQtOqRAp1N9iCNfJgopep+OprqDPVnWnhu92GfYsF52VUrGSpa8uZezBjp 5rB8SgZ5uhxmfpG7Ux28O+D1e4FViD6GOcTJrxydK+f+O4ad7rE4PyE68ATN4Az6 zW88bYzxHCgQSRbO+bXdyoJEyXsWu7h1rGi6eQNw4tr89MA+pwyQADqoTbY31JgX j9/AVwLecqdVyxOaHW9wJx5hvEChB8rJFuTfKNmcEA4zkdIFG+F6eJuGVkQuuxif D8dZHSGaaDDZ0l/Too+/Q+W2it1gonioQIzAzA9ANxGQsxIbLc4phXlsBpHA4jIt TivF/QaCyNc/8+f0KGOmrOvXMDLNUlu+KhqX2jIDzaL7KgrDNFbLfWRcPLcoASvs VOdCl+HCBqTmwON7Ru+XR2dChcg+ckrY2IFHXzrgbMBZd11ru5HRPc9zmdms62SD 4XfFNwflLtSjYvcUwtR8pJAbienbKFRudGGsHIhY1J+gVhiZH6g= =w778 -----END PGP SIGNATURE----- --=-=-=-- --===============1656647127498595809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============1656647127498595809==--