linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@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, dmitry.baryshkov@linaro.org,
	ahalaney@redhat.com
Subject: Re: [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear" property for UFS device
Date: Thu, 3 Nov 2022 17:58:50 +0530	[thread overview]
Message-ID: <20221103122850.GD8434@thinkpad> (raw)
In-Reply-To: <1fe8fd96-7770-0bda-c970-aa38d030ff3b@linaro.org>

On Wed, Nov 02, 2022 at 03:09:50PM -0400, Krzysztof Kozlowski wrote:
> On 31/10/2022 14:02, Manivannan Sadhasivam wrote:
> > The maximum gear supported by the UFS device can be specified using the
> > "max-device-gear" property. This allows the UFS controller to configure the
> > TX/RX gear before starting communication with the UFS device.
> 
> This is confusing. The UFS PHY provides gear capability, so what is the
> "device" here? The attached memory? How could it report something else
> than phy?
> 

This is the norm with any storage protocol, right? Both host and device
(memory) can support different speeds and the OEM can choose to put any
combinations (even though it might not be very efficient).

For instance,

PHY (G4) -> Device (G3)

From the host perspective we know what the PHY can support but that's not the
same with the device until probing it. And probing requires using a minimum
supported gear. For sure we can use something like G2/G3 and reinit later but
as I learnt, that approach was rejected by the community when submitted
by Qualcomm earlier.

> The last sentence also suggests that you statically encode gear to avoid
> runtime negotiation.
> 

Yes, the OEM should know what the max gear speed they want to run, so getting
this info from DT makes sense.

Thanks,
Mani

> Best regards,
> Krzysztof
> 

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

  reply	other threads:[~2022-11-03 12:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31 18:02 [PATCH v2 00/15] ufs: qcom: Add HS-G4 support Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 01/15] phy: qcom-qmp-ufs: Move register settings to qmp_phy_cfg_tables struct Manivannan Sadhasivam
2022-11-11  6:57   ` Vinod Koul
2022-10-31 18:02 ` [PATCH v2 02/15] phy: qcom-qmp-ufs: Add support for configuring PHY in HS Series B mode Manivannan Sadhasivam
2022-11-11  7:01   ` Vinod Koul
2022-11-22 16:21     ` Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 03/15] phy: qcom-qmp-ufs: Add support for configuring PHY in HS G4 mode Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 04/15] phy: qcom-qmp-ufs: Add HS G4 mode support to SM8250 SoC Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 05/15] phy: qcom-qmp-ufs: Move HS Rate B register setting to tables_hs_b Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear" property for UFS device Manivannan Sadhasivam
2022-11-02 16:29   ` Rob Herring
2022-11-02 19:09   ` Krzysztof Kozlowski
2022-11-03 12:28     ` Manivannan Sadhasivam [this message]
2022-11-03 15:23       ` Krzysztof Kozlowski
2022-11-22 16:22         ` Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 07/15] arm64: dts: qcom: qrb5165-rb5: Add max-device-gear property to UFS node Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 08/15] scsi: ufs: ufs-qcom: Remove un-necessary goto statements Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 09/15] scsi: ufs: ufs-qcom: Remove un-necessary WARN_ON() Manivannan Sadhasivam
2022-10-31 20:01   ` Andrew Halaney
2022-10-31 18:02 ` [PATCH v2 10/15] scsi: ufs: ufs-qcom: Use bitfields where appropriate Manivannan Sadhasivam
2022-10-31 18:02 ` [PATCH v2 11/15] scsi: ufs: ufs-qcom: Use dev_err_probe() for printing probe error Manivannan Sadhasivam
2022-10-31 20:05   ` Andrew Halaney
2022-10-31 18:02 ` [PATCH v2 12/15] scsi: ufs: ufs-qcom: Fix the Qcom register name for offset 0xD0 Manivannan Sadhasivam
2022-11-01 15:12   ` Andrew Halaney
2022-10-31 18:02 ` [PATCH v2 13/15] scsi: ufs: ufs-qcom: Factor out the logic finding the HS Gear Manivannan Sadhasivam
2022-10-31 20:31   ` Andrew Halaney
2022-10-31 18:02 ` [PATCH v2 14/15] scsi: ufs: ufs-qcom: Add support for finding HS gear on new UFS versions Manivannan Sadhasivam
2022-10-31 20:52   ` Andrew Halaney
2022-10-31 18:02 ` [PATCH v2 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=20221103122850.GD8434@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=ahalaney@redhat.com \
    --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=krzysztof.kozlowski@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).