2024-01-12 19:50:24

by Bitterblue Smith

[permalink] [raw]
Subject: wifi: rtlwifi: Speed up firmware loading for USB

Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
(and 11 seconds for RTL8192DU). That's because the firmware is uploaded
one byte at a time.

Also, after plugging the device, the firmware gets uploaded three times
before a connection to the AP is established.

Maybe this is fine for most users, but when testing changes to the
driver it's really annoying to wait so long.

Speed up the firmware upload by writing chunks of 64 bytes at a time.
This way it takes about 110 ms for RTL8192CU (and about 210 ms for
RTL8192DU).

PCI devices could upload it in chunks of 4 bytes, but I don't have any
to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
rather than as dwords") decided otherwise anyway.

Signed-off-by: Bitterblue Smith <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/efuse.c | 65 +++++++++++++++++--
drivers/net/wireless/realtek/rtlwifi/efuse.h | 4 +-
.../wireless/realtek/rtlwifi/rtl8192cu/sw.c | 6 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 9 +++
drivers/net/wireless/realtek/rtlwifi/wifi.h | 8 +++
5 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index 2e945554ed6d..870a276299f5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -1287,18 +1287,73 @@ int rtl_get_hwinfo(struct ieee80211_hw *hw, struct rtl_priv *rtlpriv,
}
EXPORT_SYMBOL_GPL(rtl_get_hwinfo);

-void rtl_fw_block_write(struct ieee80211_hw *hw, const u8 *buffer, u32 size)
+static void _rtl_fw_block_write_usb(struct ieee80211_hw *hw, u8 *buffer, u32 size)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ u32 blockcount, blockcount8, blockcount4;
+ u32 remain8 = 0, remain4 = 0, remain = 0;
+ const u32 blocksize = 64;
+ const u32 blocksize8 = 8;
+ const u32 blocksize4 = 4;
+ u32 i, offset;
+
+ blockcount = size / blocksize;
+ remain8 = size % blocksize;
+ for (i = 0; i < blockcount; i++) {
+ offset = i * blocksize;
+ rtl_write_chunk(rtlpriv,
+ START_ADDRESS + offset,
+ blocksize, buffer + offset);
+ }
+
+ if (remain8) {
+ offset = blockcount * blocksize;
+ blockcount8 = remain8 / blocksize8;
+ remain4 = remain8 % blocksize8;
+
+ for (i = 0; i < blockcount8; i++)
+ rtl_write_chunk(rtlpriv,
+ START_ADDRESS + offset + i * blocksize8,
+ blocksize8,
+ buffer + offset + i * blocksize8);
+ }
+
+ if (remain4) {
+ offset += blockcount8 * blocksize8;
+ blockcount4 = remain4 / blocksize4;
+ remain = remain8 % blocksize4;
+
+ for (i = 0; i < blockcount4; i++)
+ rtl_write_dword(rtlpriv,
+ START_ADDRESS + offset + i * blocksize4,
+ cpu_to_le32(*(u32 *)(buffer + offset + i)));
+ }
+
+ if (remain) {
+ offset += blockcount4 * blocksize4;
+
+ for (i = 0; i < remain; i++)
+ rtl_write_byte(rtlpriv, START_ADDRESS + offset + i,
+ *(buffer + offset + i));
+ }
+}
+
+void rtl_fw_block_write(struct ieee80211_hw *hw, u8 *buffer, u32 size)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
- u8 *pu4byteptr = (u8 *)buffer;
u32 i;

- for (i = 0; i < size; i++)
- rtl_write_byte(rtlpriv, (START_ADDRESS + i), *(pu4byteptr + i));
+ if (rtlpriv->rtlhal.interface == INTF_PCI) {
+ for (i = 0; i < size; i++)
+ rtl_write_byte(rtlpriv, (START_ADDRESS + i),
+ *(buffer + i));
+ } else if (rtlpriv->rtlhal.interface == INTF_USB) {
+ _rtl_fw_block_write_usb(hw, buffer, size);
+ }
}
EXPORT_SYMBOL_GPL(rtl_fw_block_write);

-void rtl_fw_page_write(struct ieee80211_hw *hw, u32 page, const u8 *buffer,
+void rtl_fw_page_write(struct ieee80211_hw *hw, u32 page, u8 *buffer,
u32 size)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.h b/drivers/net/wireless/realtek/rtlwifi/efuse.h
index 1ec59f439382..4821625ad1e5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.h
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.h
@@ -91,8 +91,8 @@ void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate);
int rtl_get_hwinfo(struct ieee80211_hw *hw, struct rtl_priv *rtlpriv,
int max_size, u8 *hwinfo, int *params);
void rtl_fill_dummy(u8 *pfwbuf, u32 *pfwlen);
-void rtl_fw_page_write(struct ieee80211_hw *hw, u32 page, const u8 *buffer,
+void rtl_fw_page_write(struct ieee80211_hw *hw, u32 page, u8 *buffer,
u32 size);
-void rtl_fw_block_write(struct ieee80211_hw *hw, const u8 *buffer, u32 size);
+void rtl_fw_block_write(struct ieee80211_hw *hw, u8 *buffer, u32 size);
void rtl_efuse_ops_init(struct ieee80211_hw *hw);
#endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 20b4aac69642..9f4cf09090d6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -40,7 +40,7 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
rtlpriv->dm.thermalvalue = 0;

/* for firmware buf */
- rtlpriv->rtlhal.pfirmware = vzalloc(0x4000);
+ rtlpriv->rtlhal.pfirmware = kmalloc(0x4000, GFP_KERNEL);
if (!rtlpriv->rtlhal.pfirmware) {
pr_err("Can't alloc buffer for fw\n");
return 1;
@@ -61,7 +61,7 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
fw_name, rtlpriv->io.dev,
GFP_KERNEL, hw, rtl_fw_cb);
if (err) {
- vfree(rtlpriv->rtlhal.pfirmware);
+ kfree(rtlpriv->rtlhal.pfirmware);
rtlpriv->rtlhal.pfirmware = NULL;
}
return err;
@@ -72,7 +72,7 @@ static void rtl92cu_deinit_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);

if (rtlpriv->rtlhal.pfirmware) {
- vfree(rtlpriv->rtlhal.pfirmware);
+ kfree(rtlpriv->rtlhal.pfirmware);
rtlpriv->rtlhal.pfirmware = NULL;
}
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 07a7e6fa46af..1fc480fe18ad 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -125,6 +125,14 @@ static void _usb_write32_sync(struct rtl_priv *rtlpriv, u32 addr, u32 val)
_usb_write_sync(rtlpriv, addr, val, 4);
}

+static void _usb_write_chunk_sync(struct rtl_priv *rtlpriv, u32 addr,
+ u32 length, u8 *data)
+{
+ struct usb_device *udev = to_usb_device(rtlpriv->io.dev);
+
+ _usbctrl_vendorreq_sync(udev, REALTEK_USB_VENQT_WRITE, addr, data, length);
+}
+
static void _rtl_usb_io_handler_init(struct device *dev,
struct ieee80211_hw *hw)
{
@@ -135,6 +143,7 @@ static void _rtl_usb_io_handler_init(struct device *dev,
rtlpriv->io.write8 = _usb_write8_sync;
rtlpriv->io.write16 = _usb_write16_sync;
rtlpriv->io.write32 = _usb_write32_sync;
+ rtlpriv->io.write_chunk = _usb_write_chunk_sync;
rtlpriv->io.read8 = _usb_read8_sync;
rtlpriv->io.read16 = _usb_read16_sync;
rtlpriv->io.read32 = _usb_read32_sync;
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 53af324f3807..3821f6e31447 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1450,6 +1450,8 @@ struct rtl_io {
void (*write8)(struct rtl_priv *rtlpriv, u32 addr, u8 val);
void (*write16)(struct rtl_priv *rtlpriv, u32 addr, u16 val);
void (*write32)(struct rtl_priv *rtlpriv, u32 addr, u32 val);
+ void (*write_chunk)(struct rtl_priv *rtlpriv, u32 addr, u32 length,
+ u8 *data);

u8 (*read8)(struct rtl_priv *rtlpriv, u32 addr);
u16 (*read16)(struct rtl_priv *rtlpriv, u32 addr);
@@ -2962,6 +2964,12 @@ static inline void rtl_write_dword(struct rtl_priv *rtlpriv,
rtlpriv->io.read32(rtlpriv, addr);
}

+static inline void rtl_write_chunk(struct rtl_priv *rtlpriv,
+ u32 addr, u32 length, u8 *data)
+{
+ rtlpriv->io.write_chunk(rtlpriv, addr, length, data);
+}
+
static inline u32 rtl_get_bbreg(struct ieee80211_hw *hw,
u32 regaddr, u32 bitmask)
{
--
2.43.0


2024-01-13 06:35:57

by Kalle Valo

[permalink] [raw]
Subject: Re: wifi: rtlwifi: Speed up firmware loading for USB

Bitterblue Smith <[email protected]> writes:

> Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
> (and 11 seconds for RTL8192DU). That's because the firmware is uploaded
> one byte at a time.
>
> Also, after plugging the device, the firmware gets uploaded three times
> before a connection to the AP is established.
>
> Maybe this is fine for most users, but when testing changes to the
> driver it's really annoying to wait so long.
>
> Speed up the firmware upload by writing chunks of 64 bytes at a time.
> This way it takes about 110 ms for RTL8192CU (and about 210 ms for
> RTL8192DU).
>
> PCI devices could upload it in chunks of 4 bytes, but I don't have any
> to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
> rather than as dwords") decided otherwise anyway.
>
> Signed-off-by: Bitterblue Smith <[email protected]>

There's another version so I assume I can drop this one:

https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2024-01-13 12:08:59

by Bitterblue Smith

[permalink] [raw]
Subject: Re: wifi: rtlwifi: Speed up firmware loading for USB

On 13/01/2024 08:35, Kalle Valo wrote:
> Bitterblue Smith <[email protected]> writes:
>
>> Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
>> (and 11 seconds for RTL8192DU). That's because the firmware is uploaded
>> one byte at a time.
>>
>> Also, after plugging the device, the firmware gets uploaded three times
>> before a connection to the AP is established.
>>
>> Maybe this is fine for most users, but when testing changes to the
>> driver it's really annoying to wait so long.
>>
>> Speed up the firmware upload by writing chunks of 64 bytes at a time.
>> This way it takes about 110 ms for RTL8192CU (and about 210 ms for
>> RTL8192DU).
>>
>> PCI devices could upload it in chunks of 4 bytes, but I don't have any
>> to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
>> rather than as dwords") decided otherwise anyway.
>>
>> Signed-off-by: Bitterblue Smith <[email protected]>
>
> There's another version so I assume I can drop this one:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>

Yes, you can drop this one. Sorry about that. I forgot to write
"[PATCH]" in the subject. I thought you wouldn't even notice this
one because of that.

2024-01-13 12:52:30

by Kalle Valo

[permalink] [raw]
Subject: Re: wifi: rtlwifi: Speed up firmware loading for USB

Bitterblue Smith <[email protected]> writes:

> On 13/01/2024 08:35, Kalle Valo wrote:
>
>> Bitterblue Smith <[email protected]> writes:
>>
>>> Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
>>> (and 11 seconds for RTL8192DU). That's because the firmware is uploaded
>>> one byte at a time.
>>>
>>> Also, after plugging the device, the firmware gets uploaded three times
>>> before a connection to the AP is established.
>>>
>>> Maybe this is fine for most users, but when testing changes to the
>>> driver it's really annoying to wait so long.
>>>
>>> Speed up the firmware upload by writing chunks of 64 bytes at a time.
>>> This way it takes about 110 ms for RTL8192CU (and about 210 ms for
>>> RTL8192DU).
>>>
>>> PCI devices could upload it in chunks of 4 bytes, but I don't have any
>>> to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
>>> rather than as dwords") decided otherwise anyway.
>>>
>>> Signed-off-by: Bitterblue Smith <[email protected]>
>>
>> There's another version so I assume I can drop this one:
>>
>> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>>
>
> Yes, you can drop this one. Sorry about that. I forgot to write
> "[PATCH]" in the subject. I thought you wouldn't even notice this
> one because of that.

I think patchwork assumes that any mail with a diff is a patch, like
this one:

https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/

So "[PATCH]" is more like a visual clue. BTW usually it's a good idea to
mark the next mail as v2 and explain in changelog what happened/changed,
that way everyone are on the same page. But no big deal, just trying to
make this smooth for everyone :)

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2024-01-13 22:55:36

by Bitterblue Smith

[permalink] [raw]
Subject: Re: wifi: rtlwifi: Speed up firmware loading for USB

On 13/01/2024 14:52, Kalle Valo wrote:
> Bitterblue Smith <[email protected]> writes:
>
>> On 13/01/2024 08:35, Kalle Valo wrote:
>>
>>> Bitterblue Smith <[email protected]> writes:
>>>
>>>> Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
>>>> (and 11 seconds for RTL8192DU). That's because the firmware is uploaded
>>>> one byte at a time.
>>>>
>>>> Also, after plugging the device, the firmware gets uploaded three times
>>>> before a connection to the AP is established.
>>>>
>>>> Maybe this is fine for most users, but when testing changes to the
>>>> driver it's really annoying to wait so long.
>>>>
>>>> Speed up the firmware upload by writing chunks of 64 bytes at a time.
>>>> This way it takes about 110 ms for RTL8192CU (and about 210 ms for
>>>> RTL8192DU).
>>>>
>>>> PCI devices could upload it in chunks of 4 bytes, but I don't have any
>>>> to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes
>>>> rather than as dwords") decided otherwise anyway.
>>>>
>>>> Signed-off-by: Bitterblue Smith <[email protected]>
>>>
>>> There's another version so I assume I can drop this one:
>>>
>>> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>>>
>>
>> Yes, you can drop this one. Sorry about that. I forgot to write
>> "[PATCH]" in the subject. I thought you wouldn't even notice this
>> one because of that.
>
> I think patchwork assumes that any mail with a diff is a patch, like
> this one:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>
> So "[PATCH]" is more like a visual clue. BTW usually it's a good idea to
> mark the next mail as v2 and explain in changelog what happened/changed,
> that way everyone are on the same page. But no big deal, just trying to
> make this smooth for everyone :)
>

Ahh, got it. I will remember to do that if something like this happens again.