Linux SCSI subsystem development
 help / color / mirror / Atom feed
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!


  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