Re: [PATCH v3 0/2] phy: qcom: usb-hs: MSM8x60 vendor ULPI init

[Vinod Koul <vkoul@kernel.org>]

On 16-06-26, 15:26, Herman van Hazendonk wrote:
> v3 (this round):
>  - Re-introduce a much smaller DT binding patch following Konrad's
>    "do we have values for MTP/QRD" question and Dmitry's
>    "qcom,hsdrvslope (or similarly named) property in DT" suggestion.
>  - Survey of every MSM8x60-class downstream tree I could reach --
>    Qualcomm reference (SURF/FFA/Fluid/Dragon/Fusion via
>    board-msm8x60.c on android.googlesource.com), Samsung Galaxy S2
>    family (Q1 / Celox / Dali / generic 8x60 MTP), Sony MSM8660
>    (sony-kernel-msm8660), HTC MSM8660 ports
>    (shooter / holiday / pyramid / doubleshot / shooter_u / ruby) and
>    HP TouchPad -- shows that pre-emphasis, CDR auto-reset and SE1
>    gating values are *identical* across every reference board.
>    Only the 4-bit HS driver slope in reg 0x32 [3:0] varies.
>  - Patch 1/2 adds a single qcom,hs-drv-slope DT property (u32,
>    range 0..15) gated to the qcom,usb-hs-phy-msm8660 compatible.
>  - Patch 2/2 hardcodes the three platform-wide writes in the driver
>    behind the same compatible match, consumes qcom,hs-drv-slope for
>    the board-specific bits, and leaves the silicon default in place
>    when the property is absent -- which matches Qualcomm's own MTP,
>    Samsung and Sony reference behaviour.
>  - The bit-level meaning we *do* have comes from Code Aurora's
>    downstream arch/arm/mach-msm/include/mach/msm_hsusb_hw.h, which
>    Samsung and HP both shipped byte-for-byte identical.
>  - Per Dmitry's request, both commit messages call out explicitly
>    that there is no public Qualcomm documentation describing how the
>    4-bit slope value maps to an actual slew rate / V/ns / %.  The
>    field is an opaque hardware control; boards must copy the value
>    from their vendor / downstream kernel as a measured-per-layout
>    knob, not a derived one.
> 
> v2:
>  - Dropped the original qcom,vendor-init-seq DT property entirely
>    and folded all the vendor-register programming into the driver
>    behind the qcom,usb-hs-phy-msm8660 compatible.
>  - HS driver slope was hardcoded in v2.  v3 promotes that one
>    varying value to a DT property as Dmitry requested.
> 
> Companion TouchPad DTS work (flipping the PHY compatible from
> "qcom,usb-hs-phy-apq8064" to "qcom,usb-hs-phy-msm8660" and adding
> qcom,hs-drv-slope = <5>) will be sent separately with the rest of
> the apq8060-tenderloin DT series.
> 
> On-device validation (HP TouchPad / APQ8060):
>  - Booted with v3 + the upcoming DTS hookup.  PHY driver bound,
>    msm_hsusb HS link came up at high-speed.  No regression vs the v2
>    hardcoded build.
> 
> Build / schema verification:
>  - dt_binding_check DT_SCHEMA_FILES=.../qcom,usb-hs-phy.yaml: clean.
>  - dtbs_check on qcom-apq8060-dragonboard.dtb and
>    qcom-msm8960-cdp.dtb (the two existing in-tree usb-hs-phy
>    consumers): clean.
>  - drivers/phy/qualcomm/phy-qcom-usb-hs.o builds clean.
>  - checkpatch.pl --strict: no warnings on either patch.

Hey, this fails to apply for me, can you please rebase on phy/next and
send

-- 
~Vinod