From: Tony Chuang <yhchuang@realtek.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "kvalo@codeaurora.org" <kvalo@codeaurora.org>,
Pkshih <pkshih@realtek.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"briannorris@chromium.org" <briannorris@chromium.org>,
Kevin Yang <kevin_yang@realtek.com>
Subject: RE: [PATCH 26/40] rtw88: 8723d: add IQ calibration
Date: Mon, 4 May 2020 09:45:48 +0000 [thread overview]
Message-ID: <feb792d067fc4319a2a1c294ac3bfc6f@realtek.com> (raw)
In-Reply-To: <20200430150206.3bw7lp7wslgeuaqx@linutronix.de>
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:
> On 2020-04-17 15:46:39 [+0800], yhchuang@realtek.com wrote:
> > diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> b/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> > index 94784c7f0743..b66bd969e007 100644
> > --- a/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> > +++ b/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> …
> > +struct iqk_backup_regs {
> > + u32 adda[IQK_ADDA_REG_NUM];
> > + u8 mac8[IQK_MAC8_REG_NUM];
> > + u32 mac32[IQK_MAC32_REG_NUM];
> > + u32 bb[IQK_BB_REG_NUM];
> > +
> > + u32 lte_path;
> > + u32 lte_gnt;
> > +
> > + u8 btg_sel;
> > + u32 bb_sel_btg;
> > +
> > + u8 igia;
> > + u8 igib;
>
> The struct has 128 bytes. Putting btg_sel after bb_sel_btg will result
> in 124 bytes. How likely is it that it will grow? I'm asking because it
> is allocated on stack.
We need to backup a lot of the register values for doing IQK.
I think it's inevitable, just about where should we put them.
And as there's only 8723D is using SW IQK, this struct will only be
used by 8723D, so add them into rtwdev is not suitable.
Another way is that we can kmalloc() and then kfree() it after
IQK is done.
>
> > +};
> > +
> > +static void rtw8723d_iqk_backup_regs(struct rtw_dev *rtwdev,
> > + struct iqk_backup_regs *backup)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < IQK_ADDA_REG_NUM; i++)
> > + backup->adda[i] = rtw_read32(rtwdev, iqk_adda_regs[i]);
> > +
> > + for (i = 0; i < IQK_MAC8_REG_NUM; i++)
> > + backup->mac8[i] = rtw_read8(rtwdev, iqk_mac8_regs[i]);
> > + for (i = 0; i < IQK_MAC32_REG_NUM; i++)
> > + backup->mac32[i] = rtw_read32(rtwdev, iqk_mac32_regs[i]);
> > +
> > + for (i = 0; i < IQK_BB_REG_NUM; i++)
> > + backup->bb[i] = rtw_read32(rtwdev, iqk_bb_regs[i]);
> > +
> > + backup->igia = (u8)rtw_read32_mask(rtwdev, REG_OFDM0_XAAGC1,
> MASKBYTE0);
> > + backup->igib = (u8)rtw_read32_mask(rtwdev, REG_OFDM0_XBAGC1,
> MASKBYTE0);
>
> igi[ab] is alreay u8, no need for cast.
It's because rtw_read32_mask() returns u32, but because we
mask with one byte only.
>
> > +
> > + backup->bb_sel_btg = rtw_read32(rtwdev, REG_BB_SEL_BTG);
> > +}
> …
>
> > +static u8 rtw8723d_iqk_rx_path(struct rtw_dev *rtwdev,
> > + const struct rtw_8723d_iqk_cfg *iqk_cfg,
> > + const struct iqk_backup_regs *backup)
> > +{
> > + u32 tx_x, tx_y;
> > + u8 result = 0x00;
>
> You could avoid the explicit init of `result' (maybe even use `ret' for
> less key strokes and avoiding the confusion with the `result' array used
> by the other functions here) and then
The result should be inited to zero here, because the value
of it is or-ed by the IQK status, such as:
result |= rtw8723d_iqk_check_tx_failed(rtwdev, iqk_cfg);
And yes, the name is a little confused to be the same.
Should use different name for them.
>
> …
> > + rtw8723d_iqk_one_shot(rtwdev, false, iqk_cfg);
> > + result |= rtw8723d_iqk_check_tx_failed(rtwdev, iqk_cfg);
>
> not or the returned value here. Since you don't collect it from multiple
> functions I don't see the reason for it.
It actually does collect them from two functions, they are the
same, but are done twice, hence using |= here.
>
> > + if (!result)
> > + goto restore;
> …
> > + rtw8723d_iqk_one_shot(rtwdev, false, iqk_cfg);
> > + result |= rtw8723d_iqk_check_rx_failed(rtwdev, iqk_cfg);
>
> Same here.
>
> > +restore:
> > + rtw8723d_iqk_txrx_path_post(rtwdev, iqk_cfg, backup);
> > +
> > + return result;
> > +}
> > +
> …
> > +
> > +static void rtw8723d_phy_calibration(struct rtw_dev *rtwdev)
> > +{
> > + struct rtw_dm_info *dm_info = &rtwdev->dm_info;
> > + s32 result[IQK_ROUND_SIZE][IQK_NR];
> > + struct iqk_backup_regs backup;
>
> I don't know how deep you are in the call chain, but `result' takes 128
> bytes and `backup' as well (this could be 124).
> I'm not saying that this is bad, just that you keep an eye on it since
> those two take 256 bytes.
I can try to fix it, to see if we can reduce that.
>
> > + u8 i, j;
> > + u8 final_candidate = IQK_ROUND_INVALID;
> > + bool good;
> > +
> > + rtw_dbg(rtwdev, RTW_DBG_RFK, "[IQK] Start!!!\n");
> > +
> > + memset(result, 0, sizeof(result));
>
> Sebastian
>
Yen-Hsuan
next prev parent reply other threads:[~2020-05-04 9:46 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 7:46 [PATCH 00/40] rtw88: add support for 802.11n RTL8723DE devices yhchuang
2020-04-17 7:46 ` [PATCH 01/40] rtw88: 8723d: Add basic chip capabilities yhchuang
2020-04-17 7:46 ` [PATCH 02/40] rtw88: 8723d: add beamform wrapper functions yhchuang
2020-04-17 7:46 ` [PATCH 03/40] rtw88: 8723d: Add power sequence yhchuang
2020-04-17 7:46 ` [PATCH 04/40] rtw88: 8723d: Add RF read/write ops yhchuang
2020-04-17 7:46 ` [PATCH 05/40] rtw88: 8723d: Add mac/bb/rf/agc/power_limit tables yhchuang
2020-04-17 7:46 ` [PATCH 06/40] rtw88: 8723d: Add cfg_ldo25 to control LDO25 yhchuang
2020-04-17 7:46 ` [PATCH 07/40] rtw88: 8723d: Add new chip op efuse_grant() to control efuse access yhchuang
2020-04-17 7:46 ` [PATCH 08/40] rtw88: 8723d: Add read_efuse to recognize efuse info from map yhchuang
2020-04-17 7:46 ` [PATCH 09/40] rtw88: add legacy firmware download for 8723D devices yhchuang
2020-04-17 7:46 ` [PATCH 10/40] rtw88: no need to send additional information to legacy firmware yhchuang
2020-04-17 7:46 ` [PATCH 11/40] rtw88: 8723d: Add mac power-on/-off function yhchuang
2020-04-17 7:46 ` [PATCH 12/40] rtw88: decompose while(1) loop of power sequence polling command yhchuang
2020-04-17 7:46 ` [PATCH 13/40] rtw88: 8723d: 11N chips don't support H2C queue yhchuang
2020-04-17 7:46 ` [PATCH 14/40] rtw88: 8723d: implement set_tx_power_index ops yhchuang
2020-04-17 7:46 ` [PATCH 15/40] rtw88: 8723d: Organize chip TX/RX FIFO yhchuang
2020-04-17 7:46 ` [PATCH 16/40] rtw88: 8723d: initialize mac/bb/rf basic functions yhchuang
2020-04-17 7:46 ` [PATCH 17/40] rtw88: 8723d: Add DIG parameter yhchuang
2020-04-17 7:46 ` [PATCH 18/40] rtw88: 8723d: Add query_rx_desc yhchuang
2020-04-17 7:46 ` [PATCH 19/40] rtw88: 8723d: Add set_channel yhchuang
2020-04-17 7:46 ` [PATCH 20/40] rtw88: handle C2H_CCX_TX_RPT to know if packet TX'ed successfully yhchuang
2020-04-17 7:46 ` [PATCH 21/40] rtw88: 8723d: 11N chips don't support LDPC yhchuang
2020-04-17 7:46 ` [PATCH 22/40] rtw88: 8723d: Add chip_ops::false_alarm_statistics yhchuang
2020-04-17 7:46 ` [PATCH 23/40] rtw88: 8723d: Set IG register for CCK rate yhchuang
2020-04-17 7:46 ` [PATCH 24/40] rtw88: 8723d: add interface configurations table yhchuang
2020-04-17 7:46 ` [PATCH 25/40] rtw88: 8723d: Add LC calibration yhchuang
2020-04-30 13:57 ` Sebastian Andrzej Siewior
2020-05-04 8:40 ` Tony Chuang
2020-04-17 7:46 ` [PATCH 26/40] rtw88: 8723d: add IQ calibration yhchuang
2020-04-30 15:02 ` Sebastian Andrzej Siewior
2020-05-04 9:45 ` Tony Chuang [this message]
2020-05-05 11:42 ` Sebastian Andrzej Siewior
2020-04-17 7:46 ` [PATCH 27/40] rtw88: 8723d: Add power tracking yhchuang
2020-04-17 7:46 ` [PATCH 28/40] rtw88: 8723d: Add shutdown callback to disable BT USB suspend yhchuang
2020-05-05 14:14 ` Sebastian Andrzej Siewior
2020-05-06 2:35 ` Tony Chuang
2020-05-06 20:01 ` Sebastian Andrzej Siewior
2020-05-07 4:26 ` Tony Chuang
2020-05-10 21:54 ` Sebastian Andrzej Siewior
2020-05-11 6:43 ` Pkshih
2020-04-17 7:46 ` [PATCH 29/40] rtw88: 8723d: implement flush queue yhchuang
2020-04-17 7:46 ` [PATCH 30/40] rtw88: 8723d: set ltecoex register address in chip_info yhchuang
2020-04-17 7:46 ` [PATCH 31/40] rtw88: 8723d: Add coex support yhchuang
2020-04-17 7:46 ` [PATCH 32/40] rtw88: fill zeros to words 0x06 and 0x07 of security cam entry yhchuang
2020-04-17 7:46 ` [PATCH 33/40] rtw88: 8723d: Add 8723DE to Kconfig and Makefile yhchuang
2020-04-17 7:46 ` [PATCH 34/40] rtw88: extract: export symbols used in chip functionalities yhchuang
2020-04-17 7:46 ` [PATCH 35/40] rtw88: extract: export symbols about pci interface yhchuang
2020-04-17 7:46 ` [PATCH 36/40] rtw88: extract: make 8822c an individual kernel module yhchuang
2020-04-17 7:46 ` [PATCH 37/40] rtw88: extract: make 8822b " yhchuang
2020-04-17 7:46 ` [PATCH 38/40] rtw88: extract: make 8723d " yhchuang
2020-04-17 7:46 ` [PATCH 39/40] rtw88: extract: remove the unused after extracting yhchuang
2020-04-17 7:46 ` [PATCH 40/40] rtw88: rename rtw88.ko/rtwpci.ko to rtw88_core.ko/rtw88_pci.ko yhchuang
2020-04-17 8:19 ` [PATCH 00/40] rtw88: add support for 802.11n RTL8723DE devices Kalle Valo
2020-04-17 8:26 ` Kalle Valo
2020-04-17 9:03 ` Tony Chuang
2020-04-17 14:47 ` Stefan Schmidt
2020-04-21 8:23 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=feb792d067fc4319a2a1c294ac3bfc6f@realtek.com \
--to=yhchuang@realtek.com \
--cc=bigeasy@linutronix.de \
--cc=briannorris@chromium.org \
--cc=kevin_yang@realtek.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.