From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stephen Boyd <swboyd@chromium.org>,
Doug Anderson <dianders@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>,
Wesley Cheng <quic_wcheng@quicinc.com>,
Vinod Koul <vkoul@kernel.org>
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-phy@lists.infradead.org, quic_pkondeti@quicinc.com,
quic_ppratap@quicinc.com, quic_vpulyala@quicinc.com
Subject: Re: [v4 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy override params bindings
Date: Sat, 14 May 2022 21:41:42 +0200 [thread overview]
Message-ID: <f8d8be37-3e2f-c1fc-37d6-b1e0bfa875ce@linaro.org> (raw)
In-Reply-To: <972ac516-efac-54d6-febc-1b180ec36d4b@quicinc.com>
On 14/05/2022 08:24, Krishna Kurapati PSSNV wrote:
>
> On 5/12/2022 4:00 PM, Krzysztof Kozlowski wrote:
>> On 12/05/2022 07:57, Krishna Kurapati PSSNV wrote:
>>> On 5/11/2022 11:49 PM, Krzysztof Kozlowski wrote:
>>>> On 11/05/2022 17:26, Krishna Kurapati wrote:
>>>>> From: Sandeep Maheswaram <quic_c_sanm@quicinc.com>
>>>>>
>>>>> Add device tree bindings for SNPS phy tuning parameters.
>>>>>
>>>>> Signed-off-by: Sandeep Maheswaram <quic_c_sanm@quicinc.com>
>>>>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>>>>> ---
>>>>> .../bindings/phy/qcom,usb-snps-femto-v2.yaml | 87 ++++++++++++++++++++++
>>>>> 1 file changed, 87 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 1ce251d..70efffe 100644
>>>>> --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
>>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
>>>>> @@ -53,6 +53,93 @@ properties:
>>>>> vdda33-supply:
>>>>> description: phandle to the regulator 3.3V supply node.
>>>>>
>>>>> + qcom,hs-disconnect-bps:
>>>>> + $ref: /schemas/types.yaml#/definitions/int32
>>>>> + description:
>>>>> + This adjusts the voltage level for the threshold used to
>>>>> + detect a disconnect event at the host. Possible values are.
>>>>> + The values defined are in multiples of basis points (1bp = 0.01%).
>>>> This means there is some minimum and maximum (100%)?
>>> Hi Krzystof,
>>>
>>> Yes there are max and min for each parameter (not necessarily 0%/100%)
>>>
>>> As an example if we take squelch detector threshold, the register value
>>> vs actual percentage changer as per data book is as follows :
>>>
>>> % change in voltage | corresponding reg value
>>>
>>> -20.90% | 7
>>> -15.60% | 6
>>> -10.30% | 5
>>> -5.30% | 4
>>> 0% | 3
>>> 5.30% | 2
>>> 10.60% | 1
>>> 15.90% | 0
>>>
>>> Here the min and max are 15.9% to -20.9%
>>>
>>> The min and max differ for each parameter and might not be necessarily
>>> 0% and 100%
>> Then it seems possible to define minimum and maximum values - please add
>> them ("minimum: xxxx").
>>
>>
>> Best regards,
>> Krzysztof
>
> Hi Krzysztof,
>
> Sorry for the late reply, missed this mail.
>
> Currently, these values have a fixed maximum and minimum. But if these
> limits change in the
>
> future (say on a per target basis) , would it be appropriate to add them
> here in bindings file ?
Per "target" you mean compatible? Then yes, the same as customizing
number of interrupts, clocks etc.
>
> Also in the driver file for sc7280 target, we have added parameter
> mapping : (map b/w register value
>
> and bps passed from device tree). For squelch detector, it is as follows:
>
> +static struct override_param squelch_det_threshold_sc7280[] = {
> + OVERRIDE_PARAM(-2090, 7),
> + OVERRIDE_PARAM(-1560, 6),
> + OVERRIDE_PARAM(-1030, 5),
> + OVERRIDE_PARAM(-530, 4),
> + OVERRIDE_PARAM(0, 3),
> + OVERRIDE_PARAM(530, 2),
> + OVERRIDE_PARAM(1060, 1),
> + OVERRIDE_PARAM(1590, 0),
> +};
>
> And the code is written such that if we give a bps value in dt greater than max value in
> table, we would automatically choose max value. And if we provide bps value lesser than
> minimum value, we would choose the min value.
>
> So, would it be appropriate to add the min and max in dt-bindings when there is a
> slight chance of them changing in the future ?
The kernel behavior should not matter here, because the bindings are
about the hardware. Therefore if hardware comes with maximum/minimum
values, it would be better to document them here.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-05-14 19:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 15:26 [v4 0/3] Add QCOM SNPS PHY overriding params support Krishna Kurapati
2022-05-11 15:26 ` [v4 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy override params bindings Krishna Kurapati
2022-05-11 18:19 ` Krzysztof Kozlowski
2022-05-12 5:57 ` Krishna Kurapati PSSNV
2022-05-12 10:30 ` Krzysztof Kozlowski
2022-05-14 6:24 ` Krishna Kurapati PSSNV
2022-05-14 19:41 ` Krzysztof Kozlowski [this message]
2022-05-13 7:33 ` Krishna Kurapati PSSNV
2022-05-13 10:32 ` Krzysztof Kozlowski
2022-05-13 12:20 ` Krzysztof Kozlowski
2022-05-13 18:32 ` Krishna Kurapati PSSNV
2022-05-11 15:26 ` [v4 2/3] phy: qcom-snps: Add support for overriding phy tuning parameters Krishna Kurapati
2022-05-11 21:04 ` kernel test robot
2022-05-12 1:29 ` kernel test robot
2022-05-11 15:26 ` [v4 3/3] arm64: dts: qcom: sc7280: Update SNPS Phy params for SC7280 IDP device Krishna Kurapati
2022-05-11 18:16 ` [v4 0/3] Add QCOM SNPS PHY overriding params support Krzysztof Kozlowski
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=f8d8be37-3e2f-c1fc-37d6-b1e0bfa875ce@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--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_kriskura@quicinc.com \
--cc=quic_pkondeti@quicinc.com \
--cc=quic_ppratap@quicinc.com \
--cc=quic_vpulyala@quicinc.com \
--cc=quic_wcheng@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.org \
--cc=vkoul@kernel.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
all inboxes | Powered by JetHome®