[PATCH 1/2] dt-bindings: phy: qcom,usb-hs-phy: add qcom,vendor-init-seq
Dmitry Baryshkov
dmitry.baryshkov at oss.qualcomm.com
Thu Jun 11 17:25:31 PDT 2026
On Thu, Jun 11, 2026 at 12:39:45PM +0200, Konrad Dybcio wrote:
> On 6/4/26 1:02 AM, Dmitry Baryshkov wrote:
> > On Wed, Jun 03, 2026 at 06:09:18PM +0200, me at herrie.org wrote:
> >> On 2026-06-03 15:57, Dmitry Baryshkov wrote:
> >>> On Wed, Jun 03, 2026 at 07:48:08AM +0200, Herman van Hazendonk wrote:
> >>>> Add an optional "qcom,vendor-init-seq" property carrying raw ULPI
> >>>> (address, value) pairs that are written after PHY reset.
> >>>>
> >>>> Unlike the existing "qcom,init-seq" property, the address field is
> >>>> NOT offset by ULPI_EXT_VENDOR_SPECIFIC, so the new property can
> >>>> reach the standard ULPI vendor register range (0x30-0x3f). MSM8x60-
> >>>> class hardware needs this range to programme pre-emphasis, HS driver
> >>>> slope and CDR auto-reset bits the legacy msm_otg driver used to set
> >>>> via platform data.
> >>>
> >>> Are those register writes specific to the device or to the whole
> >>> platform? In the latter case please extend the driver to write them.
> >>
> >> Looking at every MSM8x60 reference kernel I could find (Qualcomm's own
> >> msm8x60 board, HP TouchPad / APQ8060, and some HTC/Saumsung MSM8660
> >> devices), the writes split into two groups:
> >>
> >> Platform-level (same across all MSM8x60 hardware):
> >> - reg 0x36 bits 1+2: CDR auto-reset disabled, SE1 gating disabled
> >> - reg 0x32 bits [5:4]: pre-emphasis at 20%
> >>
> >> Board-specific:
> >> - reg 0x32 bits [3:0]: HS driver slope — HP TouchPad uses 5, HTC
> >> devices use 1. This clearly depends on board layout (trace length,
> >> connector loading, etc.).
> >>
> >> So the platform-level writes should move unconditionally into the driver
> >> behind a match-data flag for the MSM8x60-class compatible, and only the
> >> HS driver slope value belongs in DT.
> >
> > Looks like it. Please hardcode the value for your platform in the driver
> > (with the comment), meanwhile we can try looking up the actual values.
>
> Do we have the values for a MTP/QRD (or whatever they used to be called
> back then..), like we would usually put in there?
As far as I can understand msm-3.0 and msm-3.4 most of the boards were
writing 0 here (although it might have been unexpected). None of the
board files set the hsdrvslope value (which means 0).
Please correct me if I'm wrong. I see that for tenderloin kernels change
that to 0x5, but I can't find a sensible commit message.
I could not find the documentation for vendor ULPI registers for those
chips, so I don't think we can identify, how to make sense of those
values. In such a case and having different board-specific values, we
don't have a better option than having a qcom,hsdrvslope (or similarly
named) property in DT.
--
With best wishes
Dmitry
More information about the linux-phy
mailing list