| Message ID | 20221031180217.32512-7-manivannan.sadhasivam@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | ufs: qcom: Add HS-G4 support | expand |
On Thu, Nov 03, 2022 at 11:23:17AM -0400, Krzysztof Kozlowski wrote: > 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. > Since I'm not able to get a link to the previous discussion, I'm gonna implement the reinit support and post the next iteration. Let's see how it turns up. Thanks, Mani > > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml index 47a4e9e1a775..5dcd14909ad5 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml +++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml @@ -73,6 +73,11 @@ properties: description: Specifies max. load that can be drawn from VCCQ2 supply. + max-device-gear: + description: + Specifies max. gear the UFS device supports. + enum: [1, 2, 3, 4, 5] + dependencies: freq-table-hz: [ 'clocks' ]
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. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> --- Documentation/devicetree/bindings/ufs/ufs-common.yaml | 5 +++++ 1 file changed, 5 insertions(+)