| Message ID | 1570375708-26965-2-git-send-email-wahrenst@gmx.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: Add minimal Raspberry Pi 4 support | expand |
Hi Marcel, hi Johan, Am 06.10.19 um 17:28 schrieb Stefan Wahren: > The RPi 4 uses the hardware handshake lines for CYW43455, but the chip > doesn't react to HCI requests during DT probe. The reason is the inproper > handling of the RTS line during startup. According to the startup > signaling sequence in the CYW43455 datasheet, the hosts RTS line must > be driven after BT_REG_ON and BT_HOST_WAKE. > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net> > --- > drivers/bluetooth/hci_bcm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c > index 7646636..0f73f6a 100644 > --- a/drivers/bluetooth/hci_bcm.c > +++ b/drivers/bluetooth/hci_bcm.c > @@ -445,9 +445,11 @@ static int bcm_open(struct hci_uart *hu) > > out: > if (bcm->dev) { > + hci_uart_set_flow_control(hu, true); > hu->init_speed = bcm->dev->init_speed; > hu->oper_speed = bcm->dev->oper_speed; > err = bcm_gpio_set_power(bcm->dev, true); > + hci_uart_set_flow_control(hu, false); > if (err) > goto err_unset_hu; > } > -- > 2.7.4 would be nice to get some feedback about this. Regards Stefan
Hi Stefan, > The RPi 4 uses the hardware handshake lines for CYW43455, but the chip > doesn't react to HCI requests during DT probe. The reason is the inproper > handling of the RTS line during startup. According to the startup > signaling sequence in the CYW43455 datasheet, the hosts RTS line must > be driven after BT_REG_ON and BT_HOST_WAKE. > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net> > --- > drivers/bluetooth/hci_bcm.c | 2 ++ > 1 file changed, 2 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Hello, On Sun, Oct 20, 2019 at 11:17:28PM +0200, Stefan Wahren wrote: > Hi Marcel, > hi Johan, > > Am 06.10.19 um 17:28 schrieb Stefan Wahren: > > The RPi 4 uses the hardware handshake lines for CYW43455, but the chip > > doesn't react to HCI requests during DT probe. The reason is the inproper > > handling of the RTS line during startup. According to the startup > > signaling sequence in the CYW43455 datasheet, the hosts RTS line must > > be driven after BT_REG_ON and BT_HOST_WAKE. > > > > Signed-off-by: Stefan Wahren <wahrenst@gmx.net> > > --- > > drivers/bluetooth/hci_bcm.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c > > index 7646636..0f73f6a 100644 > > --- a/drivers/bluetooth/hci_bcm.c > > +++ b/drivers/bluetooth/hci_bcm.c > > @@ -445,9 +445,11 @@ static int bcm_open(struct hci_uart *hu) > > > > out: > > if (bcm->dev) { > > + hci_uart_set_flow_control(hu, true); > > hu->init_speed = bcm->dev->init_speed; > > hu->oper_speed = bcm->dev->oper_speed; > > err = bcm_gpio_set_power(bcm->dev, true); > > + hci_uart_set_flow_control(hu, false); > > if (err) > > goto err_unset_hu; > > } > > -- > > 2.7.4 > > would be nice to get some feedback about this. I started seeing failures on Orange Pi 3 in 5.5-rc: [ 3.839134] Bluetooth: hci0: command 0xfc18 tx timeout [ 11.999136] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 12.004613] Bluetooth: hci0: Failed to set baudrate [ 12.123187] Bluetooth: hci0: BCM: chip id 130 [ 12.128398] Bluetooth: hci0: BCM: features 0x0f [ 12.154686] Bluetooth: hci0: BCM4345C5 [ 12.157165] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000 [ 15.343684] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0038 Switch to higher baudrate works again after reverting this patch. That board also uses RTS/CTS signalling. I guess the patch needs re-thinking/maybe other chips may not need this? I don't have access to datasheets. regards, o. > Regards > Stefan > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Ondrej, Am 16.12.19 um 14:25 schrieb Ondřej Jirman: > Hello, > > On Sun, Oct 20, 2019 at 11:17:28PM +0200, Stefan Wahren wrote: >> Hi Marcel, >> hi Johan, >> >> Am 06.10.19 um 17:28 schrieb Stefan Wahren: >>> The RPi 4 uses the hardware handshake lines for CYW43455, but the chip >>> doesn't react to HCI requests during DT probe. The reason is the inproper >>> handling of the RTS line during startup. According to the startup >>> signaling sequence in the CYW43455 datasheet, the hosts RTS line must >>> be driven after BT_REG_ON and BT_HOST_WAKE. >>> >>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> >>> --- >>> drivers/bluetooth/hci_bcm.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c >>> index 7646636..0f73f6a 100644 >>> --- a/drivers/bluetooth/hci_bcm.c >>> +++ b/drivers/bluetooth/hci_bcm.c >>> @@ -445,9 +445,11 @@ static int bcm_open(struct hci_uart *hu) >>> >>> out: >>> if (bcm->dev) { >>> + hci_uart_set_flow_control(hu, true); >>> hu->init_speed = bcm->dev->init_speed; >>> hu->oper_speed = bcm->dev->oper_speed; >>> err = bcm_gpio_set_power(bcm->dev, true); >>> + hci_uart_set_flow_control(hu, false); >>> if (err) >>> goto err_unset_hu; >>> } >>> -- >>> 2.7.4 >> would be nice to get some feedback about this. > I started seeing failures on Orange Pi 3 in 5.5-rc: > > [ 3.839134] Bluetooth: hci0: command 0xfc18 tx timeout > [ 11.999136] Bluetooth: hci0: BCM: failed to write update baudrate (-110) > [ 12.004613] Bluetooth: hci0: Failed to set baudrate > [ 12.123187] Bluetooth: hci0: BCM: chip id 130 > [ 12.128398] Bluetooth: hci0: BCM: features 0x0f > [ 12.154686] Bluetooth: hci0: BCM4345C5 > [ 12.157165] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000 > [ 15.343684] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0038 > > Switch to higher baudrate works again after reverting this patch. sorry, i don't have access to a Orange Pi 3. I looked at a AP6256 datasheet [1], but i couldn't find any helpful information about flow control during power up. Are you able to analyze this issue more further before we revert this patch? I would like to know if this is some kind of timing issue, since in patch "bluetooth: hci_bcm: Give more time to come out of reset" you introduced a huge power on delay. Meanwhile i will play with modifications of original patch on the Raspberry Pi 4 and come back to you. Thanks Stefan [1] - http://www.sparklan.com/p2-products-detail.php?PKey=4984FVukjcpylzifQiM-TGFE-IKXD--BCwf4P15KfrU&AP6256
Hello Stefan, On Mon, Dec 16, 2019 at 07:28:04PM +0100, Stefan Wahren wrote: > Hi Ondrej, > > sorry, i don't have access to a Orange Pi 3. > > I looked at a AP6256 datasheet [1], but i couldn't find any helpful > information about flow control during power up. > > Are you able to analyze this issue more further before we revert this patch? I'd like to, but I'll not be able to attach logic probe to the AP6256 module. It's too fine pitch for soldering. I may try setting CTS/RTS to gpio/input mode and grab the capture of the GPIO port states in time to see what's happening during probe of bt_bcm module. I don't really understand what effect your patch is supposed to have on the CTS/RTS lines during power up from the commit description. Can you please explain it more concretely? I'll be able to get to playing with this after the holidays. > I would like to know if this is some kind of timing issue, since in > patch "bluetooth: hci_bcm: Give more time to come out of reset" you > introduced a huge power on delay. I wouldn't mind if we could get rid of that. > Meanwhile i will play with modifications of original patch on the > Raspberry Pi 4 and come back to you. thank you, o. > Thanks > Stefan > > [1] - > http://www.sparklan.com/p2-products-detail.php?PKey=4984FVukjcpylzifQiM-TGFE-IKXD--BCwf4P15KfrU&AP6256 >
Hello Ondrej, Am 16.12.19 um 20:42 schrieb Ondřej Jirman: > Hello Stefan, > > On Mon, Dec 16, 2019 at 07:28:04PM +0100, Stefan Wahren wrote: >> Hi Ondrej, >> >> sorry, i don't have access to a Orange Pi 3. >> >> I looked at a AP6256 datasheet [1], but i couldn't find any helpful >> information about flow control during power up. >> >> Are you able to analyze this issue more further before we revert this patch? > I'd like to, but I'll not be able to attach logic probe to the AP6256 > module. It's too fine pitch for soldering. this the same issue, i had with the Raspberry Pi 4 :-( > I may try setting CTS/RTS to gpio/input mode and grab the capture of > the GPIO port states in time to see what's happening during probe > of bt_bcm module. > > I don't really understand what effect your patch is supposed to have > on the CTS/RTS lines during power up from the commit description. > Can you please explain it more concretely? I hope a picture explain more than thousand words. Please look at figure 7 at page 22 of the datasheet [2]. The patch tries to achieve the proper timing of BT_UART_CTS_N. > > I'll be able to get to playing with this after the holidays. Okay Stefan [2] - https://www.verical.com/datasheet/cypress-semiconductor-combo-wireless-module-cyw43455xkubgt-5770595.pdf
Hi Ondrej, Am 16.12.19 um 19:28 schrieb Stefan Wahren: > Hi Ondrej, > > Am 16.12.19 um 14:25 schrieb Ondřej Jirman: >> >> Meanwhile i will play with modifications of original patch on the >> Raspberry Pi 4 and come back to you. could you please test this patch [2] on top of current bluetooth-next? This is the solution in case we don't find the cause of this issue. I don't prefer this one, because this is next stuff and we need to revert the offending patch for Linux 5.5. [2] - https://gist.github.com/lategoodbye/3d39e4b07d401f07fa9f9c2f11e1f17d > > Thanks > Stefan > > [1] - > http://www.sparklan.com/p2-products-detail.php?PKey=4984FVukjcpylzifQiM-TGFE-IKXD--BCwf4P15KfrU&AP6256 >
Hi Stefan, On Tue, Dec 17, 2019 at 01:59:26PM +0100, Stefan Wahren wrote: > Hi Ondrej, > > Am 16.12.19 um 19:28 schrieb Stefan Wahren: > > Hi Ondrej, > > > > Am 16.12.19 um 14:25 schrieb Ondřej Jirman: > >> > >> Meanwhile i will play with modifications of original patch on the > >> Raspberry Pi 4 and come back to you. > > could you please test this patch [2] on top of current bluetooth-next? > > This is the solution in case we don't find the cause of this issue. I > don't prefer this one, because this is next stuff and we need to revert > the offending patch for Linux 5.5. > > [2] - https://gist.github.com/lategoodbye/3d39e4b07d401f07fa9f9c2f11e1f17d That looks equivalent to the revert and it will obviously avoid the issue, because Orange Pi 3 has a different bluetooth device compatible. regards, o. > > > > Thanks > > Stefan > > > > [1] - > > http://www.sparklan.com/p2-products-detail.php?PKey=4984FVukjcpylzifQiM-TGFE-IKXD--BCwf4P15KfrU&AP6256 > >
Hi Stefan, >>> Meanwhile i will play with modifications of original patch on the >>> Raspberry Pi 4 and come back to you. > > could you please test this patch [2] on top of current bluetooth-next? > > This is the solution in case we don't find the cause of this issue. I > don't prefer this one, because this is next stuff and we need to revert > the offending patch for Linux 5.5. > > [2] - https://gist.github.com/lategoodbye/3d39e4b07d401f07fa9f9c2f11e1f17d that patch looks fine to me. Just submit it and we will see how it works out. Regards Marcel
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index 7646636..0f73f6a 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -445,9 +445,11 @@ static int bcm_open(struct hci_uart *hu) out: if (bcm->dev) { + hci_uart_set_flow_control(hu, true); hu->init_speed = bcm->dev->init_speed; hu->oper_speed = bcm->dev->oper_speed; err = bcm_gpio_set_power(bcm->dev, true); + hci_uart_set_flow_control(hu, false); if (err) goto err_unset_hu; }
The RPi 4 uses the hardware handshake lines for CYW43455, but the chip doesn't react to HCI requests during DT probe. The reason is the inproper handling of the RTS line during startup. According to the startup signaling sequence in the CYW43455 datasheet, the hosts RTS line must be driven after BT_REG_ON and BT_HOST_WAKE. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> --- drivers/bluetooth/hci_bcm.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.7.4