Hi Larry and Ping-Ke,
On Tue, Nov 14, 2023 at 1:52 AM Ping-Ke Shih <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: Larry Finger <[email protected]> On Behalf Of Larry Finger
> > Sent: Saturday, November 11, 2023 4:26 AM
> > To: Martin Blumenstingl <[email protected]>
> > Cc: linux-wireless <[email protected]>
> > Subject: EFUSE in RTW8723DS
> >
> > Martin,
> >
> > The commit 9be20a822327 ("wifi: rtw88: rtw8723d: Implement RTL8723DS (SDIO)
> > efuse parsing") indicates that no additional information is extracted from the
> > EFUSE? Is that true, or did I misread the code?
>
> I think the commit is only to read MAC address that is programmed in different
> location from PCI interface, and no more information.
Ping-Ke is right: the eFuse is split into two sections:
1. common (RF calibration, EEPROM version, antenna information,
country code, ...) which is independent of the HCI (host controller
interface)
2. HCI specific bits (PCI vendor/device IDs, USB vendor/device IDs,
SDIO specifics)
#1 has already existed for a long time and I didn't have to touch it
since it's the same for the PCIe, USB and SDIO variant of a wireless
chip.
For #2 there are no (known to me) SDIO specific bits other than the
MAC address. That's why I only added the MAC address for SDIO. If
there's more it can still be added.
Note that the MAC address has different offsets depending on whether
the HCI is PCIe, USB or SDIO.
> >
> > One problem we are having is that some devices come with zero programming in the
> > EFUSE, and even with supplying a valid MAC address, the performance is poor.
>
> One or two years ago, people reported efuse of RTL8192DE (IIRC) isn't programmed
> in OpenWRT platform originally. That kind of product, calibration values are stored
> in external files instead, and chip is soldered on main board instead of a
> separated hardware module such M.2.
I have worked on this (also as part of getting devices supported in
OpenWrt :-)) for the ath9k driver.
Things have evolved (for the better) over time and now ath9k has
nvmem-cell support, see
Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
We can implement something similar for rtw88 if we have a board that
requires it and with someone who can help test things on the rtw88
side (don't forget: there will also be board specific .dts bits where
I could help, but someone has to be willing to do some work on this
end on their own).
> Maybe, we can read calibration values programmed in efuse as _default_ values
> from another module. This can't yield the best performance, but at least better
> than nothing.
I'm not an expert in this field but I *thought* that from a legal
standpoint it's mandatory to have the RF calibration data (to ensure
that the device is running within the country's regulatory rules and
never exceeds them).
Best regards,
Martin
On 11/20/23 13:55, Martin Blumenstingl wrote:
> Ping-Ke is right: the eFuse is split into two sections:
> 1. common (RF calibration, EEPROM version, antenna information,
> country code, ...) which is independent of the HCI (host controller
> interface)
> 2. HCI specific bits (PCI vendor/device IDs, USB vendor/device IDs,
> SDIO specifics)
>
> #1 has already existed for a long time and I didn't have to touch it
> since it's the same for the PCIe, USB and SDIO variant of a wireless
> chip.
>
> For #2 there are no (known to me) SDIO specific bits other than the
> MAC address. That's why I only added the MAC address for SDIO. If
> there's more it can still be added.
> Note that the MAC address has different offsets depending on whether
> the HCI is PCIe, USB or SDIO.
Martin,
As shown in
https://github.com/lwfinger/rtw88/issues/157#issuecomment-1820421821, driver
rtw88 shows a lot worse performance than the vendor driver for a chip with a
properly encoded EFUSE. Is this not a case of incorrect setting of the
calibration data?
Larry
Hi Larry,
apologies for my late reply.
On Tue, Nov 21, 2023 at 11:47 PM Larry Finger <[email protected]> wrote:
>
> On 11/20/23 13:55, Martin Blumenstingl wrote:
> > Ping-Ke is right: the eFuse is split into two sections:
> > 1. common (RF calibration, EEPROM version, antenna information,
> > country code, ...) which is independent of the HCI (host controller
> > interface)
> > 2. HCI specific bits (PCI vendor/device IDs, USB vendor/device IDs,
> > SDIO specifics)
> >
> > #1 has already existed for a long time and I didn't have to touch it
> > since it's the same for the PCIe, USB and SDIO variant of a wireless
> > chip.
> >
> > For #2 there are no (known to me) SDIO specific bits other than the
> > MAC address. That's why I only added the MAC address for SDIO. If
> > there's more it can still be added.
> > Note that the MAC address has different offsets depending on whether
> > the HCI is PCIe, USB or SDIO.
>
> Martin,
>
> As shown in
> https://github.com/lwfinger/rtw88/issues/157#issuecomment-1820421821, driver
> rtw88 shows a lot worse performance than the vendor driver for a chip with a
> properly encoded EFUSE. Is this not a case of incorrect setting of the
> calibration data?
My current assumption is that the worse performance (= throughput) is
related to the implementation in rtw88's SDIO code, not the
programming of the RF parameters.
I'm planning to look into this next week.
I'd appreciate any hints from Ping-Ke on what to check / how to check
(as long as I can do it with very basic equipment - in other words: I
don't have an RF analyzer) :-)
Best regards,
Martin
> -----Original Message-----
> From: Martin Blumenstingl <[email protected]>
> Sent: Saturday, December 23, 2023 6:40 PM
> To: Larry Finger <[email protected]>
> Cc: Ping-Ke Shih <[email protected]>; linux-wireless <[email protected]>
> Subject: Re: EFUSE in RTW8723DS
>
> Hi Larry,
>
> apologies for my late reply.
>
> On Tue, Nov 21, 2023 at 11:47 PM Larry Finger <[email protected]> wrote:
> >
> >
> > Martin,
> >
> > As shown in
> > https://github.com/lwfinger/rtw88/issues/157#issuecomment-1820421821, driver
> > rtw88 shows a lot worse performance than the vendor driver for a chip with a
> > properly encoded EFUSE. Is this not a case of incorrect setting of the
> > calibration data?
> My current assumption is that the worse performance (= throughput) is
> related to the implementation in rtw88's SDIO code, not the
> programming of the RF parameters.
> I'm planning to look into this next week.
> I'd appreciate any hints from Ping-Ke on what to check / how to check
> (as long as I can do it with very basic equipment - in other words: I
> don't have an RF analyzer) :-)
>
Sorry I don't have too much idea. Basically, I would like to use a sniffer to
capture packets and compare differences between rtw89 and vendor driver, and
then check PHY rate to bisect causes.
Ping-Ke