Search Linux Wireless

RE: [RFC] RTW88 firmware download issues - improvement, but not perfect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Sean Mollet <sean@xxxxxxxxxxxx>
> Sent: Monday, July 17, 2023 10:24 AM
> To: Ping-Ke Shih <pkshih@xxxxxxxxxxx>
> Cc: Larry Finger <Larry.Finger@xxxxxxxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx
> Subject: [RFC] RTW88 firmware download issues - improvement, but not perfect
> 
> On Jul 16, 2023, at 9:05 PM, Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >
> > 
> >
> >>> @@ -794,15 +794,15 @@ static int __rtw_download_firmware(struct rtw_dev *rtwdev,
> >>>
> >>>         wlan_cpu_enable(rtwdev, true);
> >>>
> >>> -       if (!ltecoex_reg_write(rtwdev, 0x38, ltecoex_bckp)) {
> >>> -               ret = -EBUSY;
> >>> -               goto dlfw_fail;
> >>> -       }
> >>> -
> >>>         ret = download_firmware_validate(rtwdev);
> >>>         if (ret)
> >>>                 goto dlfw_fail;
> >>>
> >>> +       if (!ltecoex_reg_write(rtwdev, 0x38, ltecoex_bckp)) {
> >>> +               ret = -EBUSY;
> >>> +               goto dlfw_fail;
> >>> +       }
> >>> +
> >
> > This looks reason to restore 0x38 after validating firmware. Do you have a result
> > how this change can improve?
> >
> 
> Using a Pi 4 CM as host, this reduces failures from 1 in 5 to 1 in 20.
> 
> I don’t know why, but it makes a measurable difference.

I will check this with my colleague to see if we can apply this change. 

> 
> >>>         /* reset desc and index */
> >>>         rtw_hci_setup(rtwdev);
> >>>
> >>> 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;
> >>>
> >>> -       for (cnt = 0; cnt < 1000; cnt++) {
> >>> +       for (cnt = 0; cnt < 5000; cnt++) {
> >>>                 if (rtw_read32_mask(rtwdev, addr, mask) == target)
> >>>                         return true;
> >>>
> >>> -               udelay(10);
> >>> +               udelay(50);
> >
> > 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?
> 
> Can you share some details of what the chip is doing and how long it should take?
> 

It seems like I misread the code, the latest version is 5,000 as you mentioned. 

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. 

Ping-Ke





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux