Received-SPF: pass (google.com: domain of linux-wireless+bounces-1263-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <f3505110-b76b-4152-8375-37fa3184d3c1@lwfinger.net>
 <748b045e7aaa43eb9a7fb83ad924614f@realtek.com> <CAFBinCD=iLbyfWWTqQjLQ5CiqOn08r4UaVqyKHve8AoW_xeFEw@mail.gmail.com>
 <84dc9e8b-0850-4724-a55b-582c994d042f@lwfinger.net>
In-Reply-To: <84dc9e8b-0850-4724-a55b-582c994d042f@lwfinger.net>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Sat, 23 Dec 2023 11:40:01 +0100
Message-ID: <CAFBinCDD9kY-HLQXy=Ksi1QnLcOVpS0Vrnn6ksCZmTbf0MukSA@mail.gmail.com>
Subject: Re: EFUSE in RTW8723DS
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>, linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

apologies for my late reply.

On Tue, Nov 21, 2023 at 11:47=E2=80=AFPM Larry Finger <Larry.Finger@lwfinge=
r.net> 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, dri=
ver
> rtw88 shows a lot worse performance than the vendor driver for a chip wit=
h a
> properly encoded EFUSE. Is this not a case of incorrect setting of the
> calibration data?
My current assumption is that the worse performance (=3D 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