devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: martin.petersen@oracle.com, jejb@linux.ibm.com,
	andersson@kernel.org, vkoul@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, konrad.dybcio@somainline.org,
	robh+dt@kernel.org, quic_cang@quicinc.com,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH 14/15] scsi: ufs: ufs-qcom: Add support for finding HS gear on new UFS versions
Date: Mon, 31 Oct 2022 20:26:47 +0530	[thread overview]
Message-ID: <20221031145647.GC10515@thinkpad> (raw)
In-Reply-To: <cf8dcf53-f131-68f4-c6aa-d41e02ac6d5c@linaro.org>

On Sun, Oct 30, 2022 at 12:48:21AM +0300, Dmitry Baryshkov wrote:
> On 29/10/2022 17:16, Manivannan Sadhasivam wrote:
> > Starting from UFS controller v4, Qcom supports dual gear mode (i.e., the
> > controller/PHY can be configured to run in two gear speeds). But that
> > requires an agreement between the UFS controller and the UFS device.
> > This commit finds the max gear supported by both controller and device
> > then decides which one to use.
> > 
> > UFS controller's max gear can be read from the REG_UFS_PARAM0 register and
> > UFS device's max gear can be read from the "max-gear" devicetree property.
> > 
> > The UFS PHY also needs to be configured with the decided gear using the
> > phy_set_mode_ext() API.
> > 
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> >   drivers/ufs/host/ufs-qcom.c | 35 ++++++++++++++++++++++++++++++++---
> >   drivers/ufs/host/ufs-qcom.h |  4 ++++
> >   2 files changed, 36 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> > index f952cc76919f..268463e92d67 100644
> > --- a/drivers/ufs/host/ufs-qcom.c
> > +++ b/drivers/ufs/host/ufs-qcom.c
> > @@ -281,6 +281,9 @@ static int ufs_qcom_host_reset(struct ufs_hba *hba)
> >   static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba, u32 hs_gear)
> >   {
> >   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> > +	struct device *dev = hba->dev;
> > +	u32 max_gear, hcd_max_gear, reg;
> > +	int ret;
> >   	if (host->hw_ver.major == 0x1) {
> >   		/*
> > @@ -292,8 +295,33 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba, u32 hs_gear)
> >   		 */
> >   		if (hs_gear > UFS_HS_G2)
> >   			return UFS_HS_G2;
> > +	} else if (host->hw_ver.major > 0x3) {
> > +		/*
> > +		 * Starting from UFS controller v4, Qcom supports dual gear mode (i.e., the
> > +		 * controller/PHY can be configured to run in two gear speeds). But that
> > +		 * requires an agreement between the UFS controller and the device. Below
> > +		 * code tries to find the max gear of both and decides which gear to use.
> > +		 *
> > +		 * First get the max gear supported by the UFS device if available.
> > +		 * If the property is not defined in devicetree, then use the default gear.
> > +		 */
> > +		ret = of_property_read_u32(dev->of_node, "max-gear", &max_gear);
> > +		if (ret)
> > +			goto err_out;
> 
> Can we detect the UFS device's max gear somehow? If not, the 'max-gear'
> property name doesn't sound good. Maybe calling it 'device-gear' would be
> better.
> 

UFS device probing depends on PHY init sequence. So technically we cannot know
the max gear of the device without using an init sequence, but this information
is static and should be known to a board manufacturer. That's why I decided to
use this property. Another option is to use a fixed init sequence for probing
the device and do a re-init after knowing it's max gear but that is not
recommended.

We need "max" keyword because this property specifies the maximum gear at which
the device could operate and not necessarily the gear at which it operates.
Maybe, "max-device-gear" would make it clear.

Thanks,
Mani

> > +
> > +		/* Next get the max gear supported by the UFS controller */
> > +		reg = ufshcd_readl(hba, REG_UFS_PARAM0);
> > +		hcd_max_gear = UFS_QCOM_MAX_GEAR(reg);
> > +
> > +		/*
> > +		 * Now compare both the gears. If the max gear supported by the UFS device
> > +		 * is compatible with UFS controller, then use the UFS device's max gear
> > +		 * speed. Otherwise, use the UFS controller supported max gear speed.
> > +		 */
> > +		return (max_gear <= hcd_max_gear) ? max_gear : hcd_max_gear;
> 
> return max(max_gear, hcd_max_gear); ?
> 
> >   	}
> > +err_out:
> >   	/* Default is HS-G3 */
> >   	return UFS_HS_G3;
> >   }
> > @@ -303,7 +331,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> >   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> >   	struct phy *phy = host->generic_phy;
> >   	int ret;
> > -	bool is_rate_B = UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B;
> > +	u32 hs_gear;
> >   	/* Reset UFS Host Controller and PHY */
> >   	ret = ufs_qcom_host_reset(hba);
> > @@ -311,8 +339,9 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> >   		dev_warn(hba->dev, "%s: host reset returned %d\n",
> >   				  __func__, ret);
> > -	if (is_rate_B)
> > -		phy_set_mode(phy, PHY_MODE_UFS_HS_B);
> > +	/* UFS_HS_G2 is used here since that's the least gear supported by legacy Qcom platforms */
> > +	hs_gear = ufs_qcom_get_hs_gear(hba, UFS_HS_G2);
> > +	phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, hs_gear);
> >   	/* phy initialization - calibrate the phy */
> >   	ret = phy_init(phy);
> > diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
> > index 214ea50acab9..c93bc52ea848 100644
> > --- a/drivers/ufs/host/ufs-qcom.h
> > +++ b/drivers/ufs/host/ufs-qcom.h
> > @@ -89,6 +89,10 @@ enum {
> >   #define TMRLUT_HW_CGC_EN	BIT(6)
> >   #define OCSC_HW_CGC_EN		BIT(7)
> > +/* bit definitions for REG_UFS_PARAM0 */
> > +#define MAX_HS_GEAR_MASK	GENMASK(6, 4)
> > +#define UFS_QCOM_MAX_GEAR(x)	FIELD_GET(MAX_HS_GEAR_MASK, (x))
> > +
> >   /* bit definition for UFS_UFS_TEST_BUS_CTRL_n */
> >   #define TEST_BUS_SUB_SEL_MASK	GENMASK(4, 0)  /* All XXX_SEL fields are 5 bits wide */
> 
> -- 
> With best wishes
> Dmitry
> 

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

  reply	other threads:[~2022-10-31 14:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-29 14:16 [PATCH 00/15] ufs: qcom: Add HS-G4 support Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 01/15] phy: qcom-qmp-ufs: Move register settings to qmp_phy_cfg_tables struct Manivannan Sadhasivam
2022-10-29 21:50   ` Dmitry Baryshkov
2022-10-31 15:46     ` Manivannan Sadhasivam
2022-10-31 18:50       ` Dmitry Baryshkov
2022-11-01 14:41         ` Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 02/15] phy: qcom-qmp-ufs: Add support for configuring PHY in HS Series B mode Manivannan Sadhasivam
2022-10-29 21:51   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 03/15] phy: qcom-qmp-ufs: Add support for configuring PHY in HS G4 mode Manivannan Sadhasivam
2022-10-29 21:54   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 04/15] phy: qcom-qmp-ufs: Add HS G4 mode support to SM8250 SoC Manivannan Sadhasivam
2022-10-29 21:55   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 05/15] phy: qcom-qmp-ufs: Move HS Rate B register setting to tables_hs_b Manivannan Sadhasivam
2022-10-29 21:55   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 06/15] dt-bindings: ufs: Add "max-gear" property for UFS device Manivannan Sadhasivam
2022-10-31 21:35   ` Rob Herring
2022-10-29 14:16 ` [PATCH 07/15] arm64: dts: qcom: qrb5165-rb5: Add max-gear property to UFS node Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 08/15] scsi: ufs: ufs-qcom: Remove un-necessary goto statements Manivannan Sadhasivam
2022-10-29 21:56   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 09/15] scsi: ufs: ufs-qcom: Remove un-necessary WARN_ON() Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 10/15] scsi: ufs: ufs-qcom: Use bitfields where appropriate Manivannan Sadhasivam
2022-10-29 21:58   ` Dmitry Baryshkov
2022-10-31 14:50     ` Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 11/15] scsi: ufs: ufs-qcom: Use dev_err_probe() for printing probe error Manivannan Sadhasivam
2022-10-29 21:33   ` Dmitry Baryshkov
2022-10-29 14:16 ` [PATCH 12/15] scsi: ufs: ufs-qcom: Fix the Qcom register name for offset 0xD0 Manivannan Sadhasivam
2022-10-29 22:06   ` Dmitry Baryshkov
2022-10-31 14:50     ` Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 13/15] scsi: ufs: ufs-qcom: Factor out the logic finding the HS Gear Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 14/15] scsi: ufs: ufs-qcom: Add support for finding HS gear on new UFS versions Manivannan Sadhasivam
2022-10-29 21:48   ` Dmitry Baryshkov
2022-10-31 14:56     ` Manivannan Sadhasivam [this message]
2022-10-31 18:52       ` Dmitry Baryshkov
2022-11-02 20:05       ` Krzysztof Kozlowski
2022-11-03 12:18         ` Manivannan Sadhasivam
2022-10-31 15:39     ` Manivannan Sadhasivam
2022-10-29 14:16 ` [PATCH 15/15] MAINTAINERS: Add myself as the maintainer for Qcom UFS driver 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=20221031145647.GC10515@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=andersson@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=jejb@linux.ibm.com \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=quic_cang@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=vkoul@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).