RE: [PATCH 2/3] arm64: dts: qcom: sa8155: Add gear and rate limit properties to UFS

["Alim Akhtar" <alim.akhtar@samsung.com>]

> -----Original Message-----
> From: Nitin Rawat <quic_nitirawa@quicinc.com>
> Sent: Tuesday, August 12, 2025 3:16 AM
> To: 'Manivannan Sadhasivam' <mani@kernel.org>; Alim Akhtar
> <alim.akhtar@samsung.com>
> Cc: 'Konrad Dybcio' <konrad.dybcio@oss.qualcomm.com>; 'Krzysztof
> Kozlowski' <krzk@kernel.org>; 'Ram Kumar Dwivedi'
> <quic_rdwivedi@quicinc.com>; avri.altman@wdc.com;
> bvanassche@acm.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; andersson@kernel.org; konradybcio@kernel.org;
> James.Bottomley@hansenpartnership.com; martin.petersen@oracle.com;
> agross@kernel.org; linux-arm-msm@vger.kernel.org; linux-
> scsi@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3] arm64: dts: qcom: sa8155: Add gear and rate limit
> properties to UFS
> 
> 
> 
> On 8/9/2025 4:43 PM, 'Manivannan Sadhasivam' wrote:
> > On Sat, Aug 09, 2025 at 06:30:29AM GMT, Alim Akhtar wrote:
> >
> > [...]
> >
> >>>>>>>>>> I understand that this is a static configuration, where it is
> >>>>>>>>>> already known
> >>>>>>>>> that board is broken for higher Gear.
> >>>>>>>>>> Can this be achieved by limiting the clock? If not, can we
> >>>>>>>>>> add a board
> >>>>>>>>> specific _quirk_ and let the _quirk_ to be enabled from vendor
> >>>>>>>>> specific hooks?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> How can we limit the clock without limiting the gears? When we
> >>>>>>>>> limit the gear/mode, both clock and power are implicitly
> >>> limited.
> >>>>>>>>>
> >>>>>>>> Possibly someone need to check with designer of the SoC if that
> >>>>>>>> is possible
> >>>>>>> or not.
> >>>>>>>
> >>>>>>> It's not just clock. We need to consider reducing regulator,
> >>>>>>> interconnect votes also. But as I said above, limiting the
> >>>>>>> gear/mode will take care of all these parameters.
> >>>>>>>
> >>>>>>>> Did we already tried _quirk_? If not, why not?
> >>>>>>>> If the board is so poorly designed and can't take care of the
> >>>>>>>> channel loses or heat dissipation etc, Then I assumed the gear
> >>>>>>>> negotiation between host and device should fail for the higher
> >>>>>>>> gear and driver can have
> >>>>>>> a re-try logic to re-init / re-try "power mode change" at the
> >>>>>>> lower gear. Is that not possible / feasible?
> >>>>>>>>
> >>>>>>>
> >>>>>>> I don't see why we need to add extra logic in the UFS driver if
> >>>>>>> we can extract that information from DT.
> >>>>>>>
> >>>>>> You didn’t answer my question entirely, I am still not able to
> >>>>>> visualised how come Linkup is happening in higher gear and then
> >>>>>> Suddenly
> >>>>> it is failing and we need to reduce the gear to solve that?
> >>>>>
> >>>>> Oh well, this is the source of confusion here. I didn't (also the
> >>>>> patch) claim that the link up will happen with higher speed. It
> >>>>> will most likely fail if it couldn't operate at the higher speed
> >>>>> and that's why we need to limit it to lower gear/mode *before*
> >>>>> bringing the
> >>> link up.
> >>>>>
> >>>> Right, that's why a re-try logic to negotiate a __working__ power
> >>>> mode
> >>> change can help, instead of introducing new binding for this case.
> >>>
> >>> Retry logic is already in place in the ufshcd core, but with this
> >>> kind of signal integrity issue, we cannot guarantee that it will
> >>> gracefully fail and then we could retry. The link up *may* succeed,
> >>> then it could blow up later also (when doing heavy I/O operations
> >>> etc...). So with this non-deterministic behavior, we cannot rely on this
> logic.
> >>>
> >> I would image in that case , PHY tuning / programming is not proper.
> >
> > I don't have the insight into the PHY tuning to avoid this issue.
> > Maybe Nitin or Ram can comment here. But PHY tuning is mostly SoC
> specific in the PHY driver.
> > We don't have board level tuning sequence AFIAK.
> 
> Hi Alim and Mani,
> 
> Here's my take:
> 
> There can be multiple reasons for limiting the gear/rate on a customer board
> beyond PHY tuning issues:
> 
> 1. Board-level signal integrity concerns 2. Channel or reference clock
> configuration issues 3. Customer board layout not meeting layout design
> guidelines
> 
> This becomes especially critical in automotive platforms like the SA8155, as
> mentioned by Ram. In such safety-critical applications, customer prioritize
> reliability over peak performance, and hence customers are generally
> comfortable operating at lower gears if stability is ensured.
> 
Sorry for delay in reply (lost this email in my inbox), Thanks Nitin for detailed explanations 
Looks like board has too many issues for "safety-critical applications"
Anyway, looks like there is consensus to have this property in, as adopted by PCIe and other subsystem.