[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f18a74a5-330e-402a-93ca-5552faf00e7e@sifive.com>
Date: Wed, 29 May 2024 14:30:31 -0500
From: Samuel Holland <samuel.holland@...ive.com>
To: Andreas Schwab <schwab@...ux-m68k.org>,
Emil Renner Berthing <emil.renner.berthing@...onical.com>
Cc: devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, Emil Renner Berthing <kernel@...il.dk>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Paul Walmsley
<paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>
Subject: Re: [PATCH v1 0/2] riscv: dts: starfive: Enable Bluetooth on JH7100
boards
Hi Andreas,
On 2024-05-29 10:53 AM, Andreas Schwab wrote:
> On Mai 29 2024, Emil Renner Berthing wrote:
>
>> Oddly it doesn't work on my Starlight board either. I was thinking the firmware
>> might set up pinconf differently, but comparing
>>
>> /sys/kernel/debug/pinctrl/11910000.pinctrl-pinctrl-starfive/pinconf-pins
>>
>> on the two boards shows no differences. I've also not been able to spot any
>> differences in how the AP6236 module is connected in the schematics for the two
>> boards, so not really sure how to proceed.
>
> I see no difference between Starlight and Visionfive boards, both fail
> the same way.
>
> I also see that sometimes the firmware greeting from brcmfmac occurs
> _after_ the timeout error from hci0:
>
> # journalctl -b -2 | grep -e brcmf_c_preinit_dcmds -e hci0:
> May 16 12:01:54 beaglev kernel: Bluetooth: hci0: command 0x1001 tx timeout
> May 16 12:01:54 beaglev kernel: Bluetooth: hci0: BCM: Reading local version info failed (-110)
> May 16 12:01:54 beaglev kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Mar 30 2021 01:12:21 version 7.45.98.118 (7d96287 CY) FWID 01-32059766
>
> Is this perhaps a race with the firmware loading?
brcmfmac is the WiFi driver. The WiFi and Bluetooth parts of the module are
functionally independent -- different drivers, different firmware, different DT
nodes. So the brcmfmac line is not relevant to debugging Bluetooth issues.
If the Bluetooth part has some dependency (pinconf, reset pin, clock, regulator,
etc.), then such dependency must be declared specifically for the Bluetooth in
the DT. Those seem to be correct, so maybe the issue is the maximum UART
frequency, if the signal integrity is marginal. Have you tried reducing that?
Regards,
Samuel
Powered by blists - more mailing lists