From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@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 11:23:17 -0400 [thread overview]
Message-ID: <a170e4e8-fc9d-9be1-35ba-733f24cb93e8@linaro.org> (raw)
In-Reply-To: <20221103122850.GD8434@thinkpad>
On 03/11/2022 08:28, Manivannan Sadhasivam wrote:
> 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)
Yes and look at MMC - no need to define "max mode" supported by eMMC.
You define the modes supported by controller but the memory capabilities
are being autodetected and negotiated.
>
> 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.
It should be then referenced somewhere as it might be a reason to accept
the property.
>
>> 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.
Not really if it is auto-detectable. Just because things are static is
not the sole reason to put them into DT. The reason is - they are not
detectable by OS/firmware thus we must have them in DT to be able to
know it.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-11-03 15:23 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
2022-11-03 15:23 ` Krzysztof Kozlowski [this message]
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=a170e4e8-fc9d-9be1-35ba-733f24cb93e8@linaro.org \
--to=krzysztof.kozlowski@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=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=manivannan.sadhasivam@linaro.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).