From: Pavan Kondeti <quic_pkondeti@quicinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: Sandeep Maheswaram <quic_c_sanm@quicinc.com>,
Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Kishon Vijay Abraham I <kishon@ti.com>,
"Vinod Koul" <vkoul@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Wesley Cheng <wcheng@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>,
Doug Anderson <dianders@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>,
<devicetree@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-phy@lists.infradead.org>,
<linux-usb@vger.kernel.org>, <quic_pkondeti@quicinc.com>,
<quic_ppratap@quicinc.com>, <quic_kriskura@quicinc.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy override params bindings
Date: Mon, 14 Mar 2022 08:59:52 +0530 [thread overview]
Message-ID: <20220314032952.GA27561@hu-pkondeti-hyd.qualcomm.com> (raw)
In-Reply-To: <b793195b-1d3d-63b2-19d2-72ae2aec8c0f@canonical.com>
Hi Krzysztof,
On Thu, Mar 03, 2022 at 04:59:22PM +0100, Krzysztof Kozlowski wrote:
> On 03/03/2022 07:13, Sandeep Maheswaram wrote:
> > Add device tree bindings for SNPS phy tuning parameters.
> >
> > Signed-off-by: Sandeep Maheswaram <quic_c_sanm@quicinc.com>
> > ---
> > .../bindings/phy/qcom,usb-snps-femto-v2.yaml | 125 +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> > index 0dfe691..227c097 100644
> > --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> > +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> > @@ -50,6 +50,131 @@ properties:
> > vdda33-supply:
> > description: phandle to the regulator 3.3V supply node.
> >
> > + qcom,hs-disconnect:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This adjusts the voltage level for the threshold used to
> > + detect a disconnect event at the host. Possible values are.
>
> ':', instead of full stop.
>
> > + 7 -> +21.56%
> > + 6 -> +17.43%
> > + 5 -> +13.32%
> > + 4 -> +9.73%
> > + 3 -> +6.3
> > + 2 -> +3.17%
> > + 1 -> 0, Design default%
>
> Use "default:" instead. Here and in other places.
>
> > + 0 -> -2.72%
>
> In current form this should be an enum... but actually current form is
> wrong. You should not store register values in DT. What if next version
> of hardware has a different meaning of these values?
>
> Instead, you should store here meaningful values, not register values.
>
Thanks for the feedback.
The values in % really makes the tuning easy. People look at the eye diagram
and decided whether to increase/decrease the margin. The absolute values
may not be that useful. All we need is an "adjustment" here. The databook
it self does not give any absolute values.
I agree to the "enum" suggestion which we have been following for the
qusb2 driver already.
The values have not changed in the last 5 years for this hardware block, so
defining enums for the % values would be really helpful.
>
> > +
> > + qcom,squelch-detector:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This adjusts the voltage level for the threshold used to
> > + detect valid high-speed data. Possible values are
> > + 7-> -20.90%
> > + 6-> -15.60%
> > + 5-> -10.30%
> > + 4-> -5.30%
> > + 3-> 0, Design default%
> > + 2-> +5.30%
> > + 1-> +10.60%
> > + 0-> +15.90%
> > +
> > + qcom,hs-amplitude:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This adjusts the high-speed DC level voltage.
> > + Possible values are
> > + 15-> +26.70%
> > + 14-> +24.30%
> > + 13-> +22.20%
> > + 12-> +20.00%
> > + 11-> +17.80%
> > + 10-> +15.60%
> > + 9-> +13.30%
> > + 8-> +11.10%
> > + 7-> +8.90%
> > + 6-> +6.50%
> > + 5-> +4.40%
> > + 4-> +2.30%
> > + 3-> 0, Design default%
> > + 2-> -2.20%
> > + 1-> -4.40%
> > + 0-> -6.60%
> > +
> > + qcom,pre-emphasis-duration:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + This signal controls the duration for which the
> > + HS pre-emphasis current is sourced onto DP<#> or DM<#>.
> > + The HS Transmitter pre-emphasis duration is defined in terms of
> > + unit amounts. One unit of pre-emphasis duration is approximately
> > + 650 ps and is defined as 1X pre-emphasis duration.
> > + Possible values are
> > + 1-> 1x, short pre-emphasis current duration
> > + 0-> 2x, long pre-emphasis current duration
>
> I could understand encoding of percentages in way of register value, but
> a boolean flag is too much.
>
Agreed. This needs to be encoded in % as well (100% or 200%).
Thanks,
Pavan
next prev parent reply other threads:[~2022-03-14 3:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 6:13 [PATCH v2 0/3] Add QCOM SNPS PHY overriding params support Sandeep Maheswaram
2022-03-03 6:13 ` [PATCH v2 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy override params bindings Sandeep Maheswaram
2022-03-03 15:59 ` Krzysztof Kozlowski
2022-03-03 22:23 ` Stephen Boyd
2022-03-14 3:29 ` Pavan Kondeti [this message]
2022-03-14 7:39 ` Krzysztof Kozlowski
2022-03-14 8:16 ` Pavan Kondeti
2022-03-14 8:36 ` Krzysztof Kozlowski
2022-03-14 9:40 ` Pavan Kondeti
2022-03-14 10:08 ` Krzysztof Kozlowski
2022-03-14 10:30 ` Pavan Kondeti
2022-03-14 10:41 ` Krzysztof Kozlowski
2022-03-14 11:13 ` Pavan Kondeti
2022-03-14 11:21 ` Krzysztof Kozlowski
2022-03-03 6:13 ` [PATCH v2 2/3] phy: qcom-snps: Add support for overriding phy tuning parameters Sandeep Maheswaram
2022-04-13 9:42 ` Vinod Koul
2022-04-13 9:53 ` Pavan Kondeti
2022-03-03 6:13 ` [PATCH v2 3/3] arm64: dts: qcom: sc7280: Update SNPS Phy params for SC7280 IDP device Sandeep Maheswaram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220314032952.GA27561@hu-pkondeti-hyd.qualcomm.com \
--to=quic_pkondeti@quicinc.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@ti.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=mka@chromium.org \
--cc=quic_c_sanm@quicinc.com \
--cc=quic_kriskura@quicinc.com \
--cc=quic_ppratap@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.org \
--cc=vkoul@kernel.org \
--cc=wcheng@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox