Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: [RFC] RTW88 firmware download issues - improvement, but not
 perfect
From:   Sean Mollet <sean@malmoset.com>
In-Reply-To: <8d629c6ac46444d6b5920566ae2c7e52@realtek.com>
Date:   Mon, 17 Jul 2023 13:39:39 -0500
Cc:     Larry Finger <Larry.Finger@lwfinger.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADEE3321-9472-4035-B86F-A9817438C493@malmoset.com>
References: <feadf58594b14c67bcf981dde6a60077@realtek.com>
 <ACAD9039-DD62-477E-BBCF-B8053822E042@malmoset.com>
 <8d629c6ac46444d6b5920566ae2c7e52@realtek.com>
To:     Ping-Ke Shih <pkshih@realtek.com>
Precedence: bulk

I added a check of those two registers and rebooted 20 units 10 times. =
Failure rate was consistent and the traces were all like this:

[   30.227933] rtx_88 failed in download_firmware_validate
               Support information:
[   30.228392] rtx_88 0/50 0x1C4: 0, 0x10FC: 0
[   30.244149] rtx_88 1/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.251142] rtx_88 2/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.258269] rtx_88 3/50 0x1C4: fe000000, 0x10FC: 800350f5
[   30.244149] rtx_88 1/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.251142] rtx_88 2/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.258269] rtx_88 3/50 0x1C4: fe000000, 0x10FC: 800350f5
[   30.265399] rtx_88 4/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.272388] rtx_88 5/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.279387] rtx_88 6/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.286387] rtx_88 7/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.293392] rtx_88 8/50 0x1C4: fe000000, 0x10FC: 800350f5
[   30.300386] rtx_88 9/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.307387] rtx_88 10/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.314518] rtx_88 11/50 0x1C4: fe000000, 0x10FC: 800350a5
[   30.321654] rtx_88 12/50 0x1C4: fe000000, 0x10FC: 800350a6
[   30.329913] rtx_88 13/50 0x1C4: fe000000, 0x10FC: 800350f6
[   30.338722] rtx_88 14/50 0x1C4: fe000000, 0x10FC: 800350a6

The pattern and addresses continue and are the same on any device that =
fails. Going on your statement that 0x10FC is a PC like register, it =
looks like it=E2=80=99s caught in an infinite loop.


Sean


> On Jul 17, 2023, at 3:52 AM, Ping-Ke Shih <pkshih@realtek.com> wrote:
>=20
>=20
>=20
>> -----Original Message-----
>> From: Sean Mollet <sean@malmoset.com>
>> Sent: Monday, July 17, 2023 10:24 AM
>> To: Ping-Ke Shih <pkshih@realtek.com>
>> Cc: Larry Finger <Larry.Finger@lwfinger.net>; =
linux-wireless@vger.kernel.org
>> Subject: [RFC] RTW88 firmware download issues - improvement, but not =
perfect
>>=20
>> On Jul 16, 2023, at 9:05 PM, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>=20
>>>=20
>>>=20
>>>>> @@ -794,15 +794,15 @@ static int __rtw_download_firmware(struct =
rtw_dev *rtwdev,
>>>>>=20
>>>>>        wlan_cpu_enable(rtwdev, true);
>>>>>=20
>>>>> -       if (!ltecoex_reg_write(rtwdev, 0x38, ltecoex_bckp)) {
>>>>> -               ret =3D -EBUSY;
>>>>> -               goto dlfw_fail;
>>>>> -       }
>>>>> -
>>>>>        ret =3D download_firmware_validate(rtwdev);
>>>>>        if (ret)
>>>>>                goto dlfw_fail;
>>>>>=20
>>>>> +       if (!ltecoex_reg_write(rtwdev, 0x38, ltecoex_bckp)) {
>>>>> +               ret =3D -EBUSY;
>>>>> +               goto dlfw_fail;
>>>>> +       }
>>>>> +
>>>=20
>>> This looks reason to restore 0x38 after validating firmware. Do you =
have a result
>>> how this change can improve?
>>>=20
>>=20
>> Using a Pi 4 CM as host, this reduces failures from 1 in 5 to 1 in =
20.
>>=20
>> I don=E2=80=99t know why, but it makes a measurable difference.
>=20
> I will check this with my colleague to see if we can apply this =
change.=20
>=20
>>=20
>>>>>        /* reset desc and index */
>>>>>        rtw_hci_setup(rtwdev);
>>>>>=20
>>>>> diff --git a/util.c b/util.c
>>>>> index ff3c269..fbd6599 100644
>>>>> --- a/util.c
>>>>> +++ b/util.c
>>>>> @@ -10,11 +10,11 @@ bool check_hw_ready(struct rtw_dev *rtwdev, =
u32 addr, u32 mask, u32 target)
>>>>> {
>>>>>        u32 cnt;
>>>>>=20
>>>>> -       for (cnt =3D 0; cnt < 1000; cnt++) {
>>>>> +       for (cnt =3D 0; cnt < 5000; cnt++) {
>>>>>                if (rtw_read32_mask(rtwdev, addr, mask) =3D=3D =
target)
>>>>>                        return true;
>>>>>=20
>>>>> -               udelay(10);
>>>>> +               udelay(50);
>>>=20
>>> I look into the latest vendor driver, it shows that cnt becomes =
10,000 and delay
>>> is 50us as your change.
>> Interesting. Is it possible that the real problem is simply not =
waiting long enough?
>>=20
>> Can you share some details of what the chip is doing and how long it =
should take?
>>=20
>=20
> It seems like I misread the code, the latest version is 5,000 as you =
mentioned.=20
>=20
> If failed to polling ready, please read and print out 0x1C4 and 0x10fc =
20 times
> with 1ms or more delay. These store firmware PC-like address, so we =
can check
> if firmware is running or getting stuck.=20
>=20
> Ping-Ke
>=20