On 10/2/23 09:02, Luca Weiss wrote:
On Fri Sep 29, 2023 at 3:12 PM CEST, Konrad Dybcio wrote:
On 29.09.2023 11:52, Luca Weiss wrote:
Enable the UFS phy and controller so that we can access the internal
storage of the phone.
At the same time we need to bump the minimum voltage used for UFS VCC,
otherwise it doesn't initialize properly. The new range is taken from
the vcc-voltage-level property downstream.
See also the following link for more information about the VCCQ/VCCQ2:
https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/1590a3739e7dc29d2597307881553236d492f188/fp5/yupik-idp-pm7250b.dtsi#207
Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
---
I'm not 100% convinced about the regulator range change. For sure with
the original voltage range the UFS fails to initialize, but looking at
downstream kernel during runtime (debugfs) we see the VCC voltage
switches between 2.4V (idle?) and 2.952V (active?). But even with this
change in mainline the regulator would always stay at 2.504V which is
for sure lower than the downstream operating voltage of 2.952V. Behavior
wise I don't see a difference between ~2.5V and ~2.9V.
Should I just constrain the regulator here to min=max=2.952V? Or just
say it's okay as-is?
Depends on: https://lore.kernel.org/linux-arm-msm/20230927081858.15961-1-quic_nitirawa@xxxxxxxxxxx/
---
There's a little funny hack inside the driver
#if defined(CONFIG_SCSI_UFSHCD_QTI)
if (vreg->low_voltage_sup && !vreg->low_voltage_active && on)
min_uV = vreg->max_uV;
#endif
so, when the ufs is in use, it's pinned to vmax
Hi Konrad,
Are you implying I *should* or *should not* pin the voltage range to
2.952V-2.952V for mainline?
Neither, voltage scaling should be implemented :P
But for now, pinning it to 2.952 const is the right temporary
solution, as having working UFS is generally better than one
that can only idle in a stable manner :D
Konrad
