From: Can Guo <can.guo@oss.qualcomm.com>
To: "Peter Wang (王信友)" <peter.wang@mediatek.com>,
"beanhuo@micron.com" <beanhuo@micron.com>,
"mani@kernel.org" <mani@kernel.org>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"quic_nguyenb@quicinc.com" <quic_nguyenb@quicinc.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 04/12] scsi: ufs: core: Add support for TX Equalization
Date: Tue, 17 Mar 2026 15:22:28 +0800 [thread overview]
Message-ID: <fa2a97fd-e17d-4314-b5a7-011b6b16a622@oss.qualcomm.com> (raw)
In-Reply-To: <42587e16218f1c51dbcbe6bb1639a843e10bcd80.camel@mediatek.com>
Hi Peter,
On 3/17/2026 2:49 PM, Peter Wang (王信友) wrote:
>
> On Sun, 2026-03-08 at 08:14 -0700, Can Guo wrote:
> > +static bool use_txeq_presets = true;
>
> Hi Can,
>
> The default should scan all, not only presets.
> Or, how could make sure the best FOM is in the presets?
Here is the consideration:
1. Scanning all 64 PreShoot/DeEmphasis combinations cost (much) more time
a. This could impact bootup KPI
b. During TX EQTR, IOs are paused, when one conducts a re-training,
the IOs could
be paused for too long.
2. As per our study in the past few months, the optimal/best combination
is most
likely within the 8 presets, which is true for both Host TX lanes
and Device TX lanes.
3. Even if sometime the optimal settings which fall out of the 8
presets, they are very
close to optimal one found within the 8 presets.
So, scanning the 8 presets only is more cost-efficient.
>
> > +ufshcd_tx_eqtr_result_examine(struct ufshcd_tx_eq_params
> > *old_params,
> > + struct ufshcd_tx_eq_params *new_params)
> > +{
> > + int lane;
> > +
> > + if (!old_params->is_valid)
> > + return;
>
> Is is_valid always false, causing a return here?
It can be valid if we are here (again) because one conducts a re-training.
>
>
> >
> > + /* Step 3 - Apply TX EQTR settings */
> > + ret = ufshcd_apply_tx_eqtr_settings(hba,
> > pwr_mode, &h_iter, &d_iter);
> > + if (ret) {
> > + dev_err(hba->dev, "Failed to apply TX
> > EQTR settings: %d\n",
> > + ret);
>
> Can deemphasis and preshoot be printed as well?
Sure.
>
>
> > + ret = ufshcd_vops_tx_eqtr_notify(hba, POST_CHANGE, pwr_mode);
> > + if (ret)
> > + goto out;
> > +
> > +out:
> >
>
> The if check can be removed.
Good catch.
>
>
>
> > + * @is_new: Flag to indicate whether re-newed since previous
> > iteration
>
> is_new is confusing to me. Please consider using "need_renew" or
> "update_required", which are clearer.
I will move to 'is_updated'.
>
>
> > +struct ufshcd_tx_eq_params {
> > + u32 tx_lanes;
> > + u32 rx_lanes;
> > +
> > + struct ufshcd_tx_eq_settings host[PA_MAXDATALANES];
> > + struct ufshcd_tx_eq_settings device[PA_MAXDATALANES];
> > +
> > + u32
> > host_eqtr_record[PA_MAXDATALANES][TX_HS_NUM_PRESHOOT][TX_HS_NUM_DEEMP
> > HASIS];
> > + u32
> > device_eqtr_record[PA_MAXDATALANES][TX_HS_NUM_PRESHOOT][TX_HS_NUM_DEE
> > MPHASIS];
> >
>
> Do these two records only store the FOM and are not used otherwise?
They are used by debugfs entries to print out the TX EQTR history.
>
> > +
> > + ktime_t last_eqtr_ts;
> > + int num_eqtr_records;
> > +
> > + u32 saved_adapt_eqtr;
> > +
> > + bool is_valid;
> > + bool is_applied;
> > +};
>
> The size of the struct ufshcd_tx_eq_params is 2.2K.
> It seems that some fields could use u8 instead of u32.
>
>
> > + struct ufshcd_tx_eq_params tx_eq_params[UFS_HS_GEAR_MAX - 1];
>
> This uses up to 12KB of memory. Is it really necessary to occupy
> so much memory? Can we use dynamic memory allocation instead?
> Especially since G1/G2/G3 are not used, and G4/G5 are optional.
> Only G6 is actually needed, so we shouldn't waste so much memory.
> After all, memory is expensive nowadays.
1. Even we use dynamic memory, it is still the same amount of memory.
2. G1/G2/G3 supports also TX Equalization settings, my next series will
provide
changes to allow one to give TX Equalization settings from DTS and/or
persistent memory.
3. G4/G5 supports TX Equalization as well as TX Equalization training as per
spec, we should support them like G6 equally to enable better link
quality.
>
>
> > +#define PA_PEERRXHSG6ADAPTINITIALL0L3 0x15DF
> > +#define PA_PEERRXHSG6ADAPTREFRESHL0L1L2L3 0x15DE
> >
>
> These two lines should be swapped to match the correct order.
Will do.
Thanks,
Can Guo.
>
> Thanks
> Peter
>
>
> ************* MEDIATEK Confidentiality Notice
> ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
>
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
next prev parent reply other threads:[~2026-03-17 7:22 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 15:13 [PATCH v3 00/12] scsi: ufs: Add TX Equalization support for UFS 5.0 Can Guo
2026-03-08 15:13 ` [PATCH v3 01/12] scsi: ufs: core: Introduce a new ufshcd vops negotiate_pwr_mode() Can Guo
2026-03-13 22:09 ` Bart Van Assche
2026-03-14 7:21 ` Can Guo
2026-03-08 15:13 ` [PATCH v3 02/12] scsi: ufs: core: Pass force_pmc to ufshcd_config_pwr_mode() as a parameter Can Guo
2026-03-08 15:14 ` [PATCH v3 03/12] scsi: ufs: core: Add UFS_HS_G6 and UFS_HS_GEAR_MAX to enum ufs_hs_gear_tag Can Guo
2026-03-08 15:14 ` [PATCH v3 04/12] scsi: ufs: core: Add support for TX Equalization Can Guo
2026-03-13 22:19 ` Bart Van Assche
2026-03-14 8:19 ` Can Guo
2026-03-14 9:33 ` Can Guo
2026-03-16 16:55 ` Bart Van Assche
2026-03-17 7:04 ` Can Guo
2026-03-17 6:49 ` Peter Wang (王信友)
2026-03-17 7:22 ` Can Guo [this message]
2026-03-17 7:35 ` Can Guo
2026-03-17 13:10 ` Peter Wang (王信友)
2026-03-19 5:49 ` Can Guo
2026-03-19 12:42 ` Peter Wang (王信友)
2026-03-21 2:30 ` Can Guo
2026-03-17 13:08 ` Peter Wang (王信友)
2026-03-19 5:42 ` Can Guo
2026-03-08 15:14 ` [PATCH v3 05/12] scsi: ufs: core: Add debugfs entries for TX Equalization params Can Guo
2026-03-13 22:21 ` Bart Van Assche
2026-03-08 15:14 ` [PATCH v3 06/12] scsi: ufs: core: Add helpers to pause and resume command processing Can Guo
2026-03-13 22:26 ` Bart Van Assche
2026-03-14 10:38 ` Can Guo
2026-03-16 17:12 ` Bart Van Assche
2026-03-16 18:07 ` Bart Van Assche
2026-03-08 15:14 ` [PATCH v3 07/12] scsi: ufs: core: Add support to refresh TX Equalization via debugfs Can Guo
2026-03-13 22:30 ` Bart Van Assche
2026-03-14 10:45 ` Can Guo
2026-03-16 17:14 ` Bart Van Assche
2026-03-17 13:05 ` Peter Wang (王信友)
2026-03-19 5:36 ` Can Guo
2026-03-08 15:14 ` [PATCH v3 08/12] scsi: ufs: ufs-qcom: Fixup PAM-4 TX L0_L1_L2_L3 adaptation pattern length Can Guo
2026-03-08 15:14 ` [PATCH v3 09/12] scsi: ufs: ufs-qcom: Implement vops tx_eqtr_notify() Can Guo
2026-03-08 15:14 ` [PATCH v3 10/12] scsi: ufs: ufs-qcom: Implement vops get_rx_fom() Can Guo
2026-03-08 15:14 ` [PATCH v3 11/12] scsi: ufs: ufs-qcom: Implement vops apply_tx_eqtr_settings() Can Guo
2026-03-08 15:14 ` [PATCH v3 12/12] scsi: ufs: ufs-qcom: Enable TX Equalization Can Guo
2026-03-13 21:56 ` [PATCH v3 00/12] scsi: ufs: Add TX Equalization support for UFS 5.0 Bart Van Assche
2026-03-14 10:48 ` Can Guo
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=fa2a97fd-e17d-4314-b5a7-011b6b16a622@oss.qualcomm.com \
--to=can.guo@oss.qualcomm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=adrian.hunter@intel.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mani@kernel.org \
--cc=martin.petersen@oracle.com \
--cc=peter.wang@mediatek.com \
--cc=quic_nguyenb@quicinc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox