All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Eric Chanudet <echanude@redhat.com>
Cc: Andrew Halaney <ahalaney@redhat.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-arm-msm@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Re: Re: [PATCH] scsi: ufs: qcom: avoid re-init quirk when gears match
Date: Tue, 23 Jan 2024 20:06:15 +0530	[thread overview]
Message-ID: <20240123143615.GD19029@thinkpad> (raw)
In-Reply-To: <graeyylgohsukni35djpbxibnz5ya7laqvsydharkzcktv2iwz@knbu5uq5fa4x>

On Fri, Jan 19, 2024 at 04:33:10PM -0500, Eric Chanudet wrote:
> On Fri, Jan 19, 2024 at 02:33:32PM -0600, Andrew Halaney wrote:
> > On Fri, Jan 19, 2024 at 02:07:15PM -0600, Andrew Halaney wrote:
> > > On Fri, Jan 19, 2024 at 01:55:47PM -0500, Eric Chanudet wrote:
> > > > On sa8775p-ride, probing the hba will go through the
> > > > UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH path although the power info
> > > > are same during the second init.
> > > > 
> > > > If the host is at least v4, ufs_qcom_get_hs_gear() picked the highest
> > > > supported gear when setting the host_params. After the negotiation, if
> > > > the host and device are on the same gear, it is the highest gear
> > > > supported between the two. Skip the re-init to save some time.
> > > > 
> > > > Signed-off-by: Eric Chanudet <echanude@redhat.com>
> > > > ---
> > > > 
> > > > "trace_event=ufs:ufshcd_init" reports the time spent where the re-init
> > > > quirk is performed. On sa8775p-ride:
> > > > Baseline:
> > > >   0.355879: ufshcd_init: 1d84000.ufs: took 103377 usecs, dev_state: UFS_ACTIVE_PWR_MODE, link_state: UIC_LINK_ACTIVE_STATE, err 0
> > > > With this patch:
> > > >   0.297676: ufshcd_init: 1d84000.ufs: took 43553 usecs, dev_state: UFS_ACTIVE_PWR_MODE, link_state: UIC_LINK_ACTIVE_STATE, err 0
> > > > 
> > > >  drivers/ufs/host/ufs-qcom.c | 6 +++++-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> > > > index 39eef470f8fa..f9f161340e78 100644
> > > > --- a/drivers/ufs/host/ufs-qcom.c
> > > > +++ b/drivers/ufs/host/ufs-qcom.c
> > > > @@ -738,8 +738,12 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
> > > >  		 * the second init can program the optimal PHY settings. This allows one to start
> > > >  		 * the first init with either the minimum or the maximum support gear.
> > > >  		 */
> > > > -		if (hba->ufshcd_state == UFSHCD_STATE_RESET)
> > > > +		if (hba->ufshcd_state == UFSHCD_STATE_RESET) {
> > > > +			if (host->hw_ver.major >= 0x4 &&
> > > 
> > > Is this check really necessary?
> 
> I *think* so.
> 
> For example, if hw_ver < 4, ufs_qcom_set_phy_gear() has a comment saying
> "power up the PHY using minimum supported gear (UFS_HS_G2). Switching to
> max gear will be performed during reinit if supported."
> 
> > > 
> > > The initial phy_gear state is something like this (my phrasing of
> > > ufs_qcom_set_phy_gear()):
> > > 
> > >     if hw_ver < 4:
> > >         # Comments about powering up with minimum gear (with no
> > >         # reasoning in the comment afaict), and mentions switching
> > >         # to higher gear in reinit quirk. This is opposite of the later
> > >         # versions which start at the max and scale down
> > >         phy_gear = UFS_HS_G2
> 
> IIUC, the device would not be able to negotiate a gear higher than the
> minimum set for the phy_gear on initialization.
> 
> ufshcd_init_host_params() and ufs_qcom_get_hs_gear() both set the
> controller <v4 host_params to G3. So if the device is HS capable, the
> re-init would set G3, instead of the G2 selected by
> ufs_qcom_set_phy_gear().
> 

REINIT quirk is applicable for controllers starting from v4 only, because legacy
controllers don't need separate PHY init sequences. So you can get rid of that
check.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

  reply	other threads:[~2024-01-23 14:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 18:55 [PATCH] scsi: ufs: qcom: avoid re-init quirk when gears match Eric Chanudet
2024-01-19 20:07 ` Andrew Halaney
2024-01-19 20:33   ` Andrew Halaney
2024-01-19 21:33     ` Eric Chanudet
2024-01-23 14:36       ` Manivannan Sadhasivam [this message]
2024-01-23 15:18         ` Eric Chanudet
2024-01-23 15:11 ` Manivannan Sadhasivam

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=20240123143615.GD19029@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=ahalaney@redhat.com \
    --cc=andersson@kernel.org \
    --cc=echanude@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.