| Message ID | 1550134743-17443-1-git-send-email-yhchuang@realtek.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | rtw88: major fixes for 8822c to have stable functionalities | expand |
> From: Yan-Hsuan Chuang <yhchuang@realtek.com> > > Note this patch set is based on patch set "rtw88: mac80211 driver for > Realtek 802.11ac wireless network chips". For reference: > https://patchwork.kernel.org/cover/10811967/ > https://lkml.kernel.org/linux-wireless/1550131671-2601-1-git-send-email-yhch > uang@realtek.com/ > > These patches are mean to make sure 8822c chip to operate normal for most > of the basic functionalities, such as power on, switch channel, scan, > connection establish and connection monitor. > > As the original patch set was sent 3 months ago, progress has been made > by Realtek during the past months. Now we have tested on more chips and > released tables and parameters for them. Also the chips are all > programed with efuse map released for 8822c. > > Most of the changes are about BB and RF, both control the tx/rx path. > PHY parameters/seq and efuse info make sure the hardware is powered on > correctly. And channel setting updates help driver to switch to target > channel accurately. Then trx mode setting and DACK will make hardware to > have stable performance to tx/rx to connect to AP. > > Here tx power control is also required to transmit with a precise power. > Otherwise if the power is too high or too low, the peer might not be able > to receive the signal. > > Finally, we need to report correct tx status for mac80211's connection > monitor system, this requires firmware's C2H of tx status report. After > this, users can use 8822c chips for more stable wireless communication. > > > v2 > > This v2 is sent for that https://patchwork.kernel.org/cover/10811967/ > has many modifications and the original patch set would not apply. > Also with a few changes in this one. Listed below > > - report ACK for tx frames not have IEEE80211_TX_CTL_REQ_TX_STATUS, > otherwise they will be marked as "drop" > - add more rf register write protection for patch "rtw88: add a delay > after writing a rf register" > Hi Kalle, Can I ask that when will this patch set probably be applied into your tree? Thanks! Yan-Hsuan
Tony Chuang <yhchuang@realtek.com> writes: >> From: Yan-Hsuan Chuang <yhchuang@realtek.com> >> >> Note this patch set is based on patch set "rtw88: mac80211 driver for >> Realtek 802.11ac wireless network chips". For reference: >> https://patchwork.kernel.org/cover/10811967/ >> https://lkml.kernel.org/linux-wireless/1550131671-2601-1-git-send-email-yhch >> uang@realtek.com/ >> >> These patches are mean to make sure 8822c chip to operate normal for most >> of the basic functionalities, such as power on, switch channel, scan, >> connection establish and connection monitor. >> >> As the original patch set was sent 3 months ago, progress has been made >> by Realtek during the past months. Now we have tested on more chips and >> released tables and parameters for them. Also the chips are all >> programed with efuse map released for 8822c. >> >> Most of the changes are about BB and RF, both control the tx/rx path. >> PHY parameters/seq and efuse info make sure the hardware is powered on >> correctly. And channel setting updates help driver to switch to target >> channel accurately. Then trx mode setting and DACK will make hardware to >> have stable performance to tx/rx to connect to AP. >> >> Here tx power control is also required to transmit with a precise power. >> Otherwise if the power is too high or too low, the peer might not be able >> to receive the signal. >> >> Finally, we need to report correct tx status for mac80211's connection >> monitor system, this requires firmware's C2H of tx status report. After >> this, users can use 8822c chips for more stable wireless communication. >> >> >> v2 >> >> This v2 is sent for that https://patchwork.kernel.org/cover/10811967/ >> has many modifications and the original patch set would not apply. >> Also with a few changes in this one. Listed below >> >> - report ACK for tx frames not have IEEE80211_TX_CTL_REQ_TX_STATUS, >> otherwise they will be marked as "drop" >> - add more rf register write protection for patch "rtw88: add a delay >> after writing a rf register" >> > > Can I ask that when will this patch set probably be applied into your tree? Once everyone are happy about the driver, at least it needs a review from Johannes and me but reviews from others is more than welcome. I also saw that Brian gave good comments but not sure if he thinks the driver is ready for upstream? An ideal schedule is to apply the driver just after the -rc1 is release, so within two weeks time. That way we have maximum time to fix any problems which might arise. Did Stanislaw already review this driver? I don't see any mentioning of that in the cover letter[1]. For now freeze please the developement on the driver to make the review easier. So don't do any changes unless asked by Johannes or me. You can of course do development on a separate branch and submit fixes after the driver is accepted upstream. The cover letter mentions nothing about what features are supported, that's the first thing I would like to see when I start reviewing a driver. Also a list of missing features, problematic areas and major bugs would be very helpful to understand the state of the driver. I don't see any mention about firmware availability in the cover letter, please add that. Also in another thread I saw something about this driver conflicting with a staging driver, is that true? That should be solved before the driver is accepted as I don't think two drivers should race for the same hardware and the driver is randomly chosen. And in v6 please fold the fixes from this patchset to the original patchset[1] adding the driver (using the one patch per file format). That way there's one set of patches to review. I have now applied both patchsets to the pending patch for build testing and easier review: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/log/?h=pending [1] https://patchwork.kernel.org/cover/10811967/
> From: Kalle Valo [mailto:kvalo@codeaurora.org] > > Also in another thread I saw something about this driver conflicting > with a staging driver, is that true? That should be solved before the > driver is accepted as I don't think two drivers should race for the same > hardware and the driver is randomly chosen. > I think this could be fixed by removing the staging driver via wireless-drivers-next as you said before. Can you help me coordinate this with Greg? Or should I send the patch that removes the staging driver to you. Thanks > > -- > Kalle Valo Yan-Hsuan
On Fri, Mar 08, 2019 at 12:39:51PM +0200, Kalle Valo wrote: > Once everyone are happy about the driver, at least it needs a review > from Johannes and me but reviews from others is more than welcome. I > also saw that Brian gave good comments but not sure if he thinks the > driver is ready for upstream? > > An ideal schedule is to apply the driver just after the -rc1 is release, > so within two weeks time. That way we have maximum time to fix any > problems which might arise. > > Did Stanislaw already review this driver? I don't see any mentioning of > that in the cover letter[1]. I haven't done that for v3 and later, but v2 of rtw88 was more or less ok for me (did not see anything wrong that could not be fixed after inclusion). Anyway, happy to do the review if it helps to merge the driver. Stanislaw
On Fri, Mar 08, 2019 at 12:38:48PM +0000, Tony Chuang wrote: > > From: Kalle Valo [mailto:kvalo@codeaurora.org] > > > > Also in another thread I saw something about this driver conflicting > > with a staging driver, is that true? That should be solved before the > > driver is accepted as I don't think two drivers should race for the same > > hardware and the driver is randomly chosen. > > > > I think this could be fixed by removing the staging driver via > wireless-drivers-next as you said before. Can you help me coordinate > this with Greg? Or should I send the patch that removes the staging > driver to you. Please post the removal as additional patch of rtw88 set and cc Greg, it should be ok to remove the staging rtlwifi driver via wireless-drivers-next. FWIW whatever issues rtw88 maight have, it's 1000x better to have it included in the linux kernel than staging/rtlwifi. Stanislaw
On Fri, Mar 8, 2019 at 2:40 AM Kalle Valo <kvalo@codeaurora.org> wrote: > Once everyone are happy about the driver, at least it needs a review > from Johannes and me but reviews from others is more than welcome. I > also saw that Brian gave good comments but not sure if he thinks the > driver is ready for upstream? I still have it on my plate to take another look-and-test at this, but I don't think that should stop you or Johannes from looking. At some point, if there aren't major structural or conceptual issues, it makes sense to merge and iterate. I'll try to get to it within the next week if not sooner. Regards, Brian
From: Yan-Hsuan Chuang <yhchuang@realtek.com> Note this patch set is based on patch set "rtw88: mac80211 driver for Realtek 802.11ac wireless network chips". For reference: https://patchwork.kernel.org/cover/10811967/ https://lkml.kernel.org/linux-wireless/1550131671-2601-1-git-send-email-yhchuang@realtek.com/ These patches are mean to make sure 8822c chip to operate normal for most of the basic functionalities, such as power on, switch channel, scan, connection establish and connection monitor. As the original patch set was sent 3 months ago, progress has been made by Realtek during the past months. Now we have tested on more chips and released tables and parameters for them. Also the chips are all programed with efuse map released for 8822c. Most of the changes are about BB and RF, both control the tx/rx path. PHY parameters/seq and efuse info make sure the hardware is powered on correctly. And channel setting updates help driver to switch to target channel accurately. Then trx mode setting and DACK will make hardware to have stable performance to tx/rx to connect to AP. Here tx power control is also required to transmit with a precise power. Otherwise if the power is too high or too low, the peer might not be able to receive the signal. Finally, we need to report correct tx status for mac80211's connection monitor system, this requires firmware's C2H of tx status report. After this, users can use 8822c chips for more stable wireless communication. v2 This v2 is sent for that https://patchwork.kernel.org/cover/10811967/ has many modifications and the original patch set would not apply. Also with a few changes in this one. Listed below - report ACK for tx frames not have IEEE80211_TX_CTL_REQ_TX_STATUS, otherwise they will be marked as "drop" - add more rf register write protection for patch "rtw88: add a delay after writing a rf register" Chien-Hsun Liao (3): rtw88: add a delay after writing a rf register rtw88: 8822c: update channel setting rtw88: 8822c: update trx mode setting Tzu-En Huang (2): rtw88: add 8822c tx power index table parsing support rtw88: add 8822c tx agc support Yan-Hsuan Chuang (19): rtw88: report correct tx status if mac80211 requested one rtw88: add get_c2h_from_skb for extracting c2h commands rtw88: can not support vif beacon filter actually rtw88: fix incorrect bit definition for RF mode rtw88: 8822c: correct crystal setting rtw88: 8822c: update efuse table as released rtw88: 8822c: update pwr_seq to v12 rtw88: 8822c: update phy parameter to v27 rtw88: add module param to switch lps supportability rtw88: extract utility functions into util.c rtw88: 8822c: add support for DACK rtw88: 8822c: fix RSC setting rtw88: 8822c: set ack timeout rtw88: 8822c: do not reset MAC Rx before sending CCK packet rtw88: 8822c: parse packet by sigb length rtw88: do not count dummy tail into rx counter rtw88: set OFDM ctx to receive ack after cts2self rtw88: fix slot time value rtw88: 8822b: turn rtw_write32s_mask into macro drivers/net/wireless/realtek/rtw88/Makefile | 1 + drivers/net/wireless/realtek/rtw88/fw.c | 19 +- drivers/net/wireless/realtek/rtw88/fw.h | 16 + drivers/net/wireless/realtek/rtw88/mac.c | 53 +- drivers/net/wireless/realtek/rtw88/mac80211.c | 1 - drivers/net/wireless/realtek/rtw88/main.c | 19 +- drivers/net/wireless/realtek/rtw88/main.h | 68 +- drivers/net/wireless/realtek/rtw88/pci.c | 15 +- drivers/net/wireless/realtek/rtw88/pci.h | 1 + drivers/net/wireless/realtek/rtw88/phy.c | 199 +- drivers/net/wireless/realtek/rtw88/phy.h | 9 + drivers/net/wireless/realtek/rtw88/reg.h | 13 +- drivers/net/wireless/realtek/rtw88/rtw8822b.c | 59 +- drivers/net/wireless/realtek/rtw88/rtw8822b.h | 15 + drivers/net/wireless/realtek/rtw88/rtw8822c.c | 939 +- drivers/net/wireless/realtek/rtw88/rtw8822c.h | 75 +- .../net/wireless/realtek/rtw88/rtw8822c_table.c | 11047 ++++++++++++++++--- .../net/wireless/realtek/rtw88/rtw8822c_table.h | 1 + drivers/net/wireless/realtek/rtw88/tx.c | 94 + drivers/net/wireless/realtek/rtw88/tx.h | 8 + drivers/net/wireless/realtek/rtw88/util.c | 72 + drivers/net/wireless/realtek/rtw88/util.h | 34 + 22 files changed, 10688 insertions(+), 2070 deletions(-) create mode 100644 drivers/net/wireless/realtek/rtw88/util.c create mode 100644 drivers/net/wireless/realtek/rtw88/util.h