Thread (29 messages) 29 messages, 5 authors, 2022-11-22

Re: [PATCH v2 06/15] dt-bindings: ufs: Add "max-device-gear" property for UFS device

From: Manivannan Sadhasivam <hidden>
Date: 2022-11-22 16:23:18
Also in: linux-arm-msm, linux-devicetree, linux-scsi, lkml

On Thu, Nov 03, 2022 at 11:23:17AM -0400, Krzysztof Kozlowski wrote:
On 03/11/2022 08:28, Manivannan Sadhasivam wrote:
quoted
On Wed, Nov 02, 2022 at 03:09:50PM -0400, Krzysztof Kozlowski wrote:
quoted
On 31/10/2022 14:02, Manivannan Sadhasivam wrote:
quoted
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.
quoted
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.
quoted
quoted
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
-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help