| Message ID | 20221031180217.32512-7-manivannan.sadhasivam@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | ufs: qcom: Add HS-G4 support | expand |
On Mon, Oct 31, 2022 at 11:32:08PM +0530, 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. > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> > --- > Documentation/devicetree/bindings/ufs/ufs-common.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > 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: Needs a type $ref > + description: > + Specifies max. gear the UFS device supports. > + enum: [1, 2, 3, 4, 5] > + > dependencies: > freq-table-hz: [ 'clocks' ] > > -- > 2.25.1 > >
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? The last sentence also suggests that you statically encode gear to avoid runtime negotiation. Best regards, Krzysztof
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)
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
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(+)