Received-SPF: pass (google.com: domain of linux-wireless+bounces-6197-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Sender: Larry Finger <larry.finger@gmail.com>
Message-ID: <46745fe7-a43d-4f7c-b247-f0fde01ee63e@lwfinger.net>
Date: Thu, 11 Apr 2024 12:28:33 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] rtw88: Fix startup problems for SDIO wifi plus UART
 Bluetooth
To: Kalle Valo <kvalo@kernel.org>
Cc: Ping-Ke Shih <pkshih@realtek.com>, Larry Finger <Larry.Finger@gmail.com>,
 Johannes Berg <johannes@sipsolutions.net>,
 "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
References: <4umro86wvv84.MjDfYvt4P5uZryt8boBK8Q2@1EHFQ.trk.elasticemail.com>
 <5af71338f3904aac9d2c237637c851e7@realtek.com>
 <287e9d4e-316a-4579-961e-58e75abea534@lwfinger.net>
 <87o7agjs00.fsf@kernel.org>
Content-Language: en-US
From: Larry Finger <Larry.Finger@lwfinger.net>
In-Reply-To: <87o7agjs00.fsf@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 4/11/24 2:08 AM, Kalle Valo wrote:
> (dropping stable list from cc)
> 
> Larry Finger <Larry.Finger@lwfinger.net> writes:
> 
>> On 4/10/24 9:13 PM, Ping-Ke Shih wrote:
>>> Larry Finger <Larry.Finger@gmail.com> wrote:
>>>
>>>> As discussed in the links below, the SDIO part of RTW8821CS fails to
>>>> start correctly if such startup happens while the UART portion of
>>>> the chip is initializing.
>>> I checked with SDIO team internally, but they didn't meet this case,
>>> so we may
>>> take this workaround.
>>> SDIO team wonder if something other than BT cause this failure, and
>>> after
>>> system boots everything will be well. Could you boot the system without WiFi/BT
>>> drivers, but insmod drivers manually after booting?
>>
>> I sent the request to the user with the problem. I do not have any SDIO devices.
>>
>>>
>>>> ---
>>>>    drivers/net/wireless/realtek/rtw88/sdio.c | 28 +++++++++++++++++++++++
>>>>    1 file changed, 28 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
>>>> index 0cae5746f540..eec0ad85be72 100644
>>>> --- a/drivers/net/wireless/realtek/rtw88/sdio.c
>>>> +++ b/drivers/net/wireless/realtek/rtw88/sdio.c
>>>> @@ -1325,6 +1325,34 @@ int rtw_sdio_probe(struct sdio_func *sdio_func,
>>> [...]
>>>
>>>> +       mdelay(500);
>>> Will it better to use sleep function?
>>
>> My thoughts were that a sleep function would tie up a CPU, whereas the
>> delay would not.
> 
> It's actually the opposite, msleep() allows other processes to run.
> 
> "In general, use of mdelay is discouraged and code should be refactored
> to allow for the use of msleep."
> 
> https://docs.kernel.org/timers/timers-howto.html

Kalle and Ping-ke,

Sorry that I got that wrong. I have become just another confused old man. :)

The OP at GitHub has tested kernels where he blacklisted the BT drivers. The 
wifi failed every time (3 tries with a delay and 3 times without). When he built 
a kernel with BT built-in rather than as a module, it worked (again 3 tries). 
There definitely is an interaction between the BT initialization and the wifi 
setup. If the BT part is not started and has not completed the UART 
initialization, SDIO wifi does not initialize correctly.

When it fails, unloading the wifi driver and reloading it restores wifi.

I originally wondered if there was a power problem when both were simultaneously 
started, but I see that is not the case. To reiterate, the BT must start first 
and complete UART initialization before the wifi starts initializing. It seems 
to me that a suitable msleep() at the start of the SDIO probe routine seems to 
be a viable workaround even though it is not aesthetically pleasing. A sleep of 
150 ms is too short, but 500 seems to work reliably.

Perhaps the SDIO experts at Realtek may be able to offer a more satisfying 
explanation. The OP at GitHub and I will try to answer any questions they might 
have. Note that I do not have the hardware, but my contact at GitHub is 
knowledgeable, and seems eager to help.

Larry