lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29d12e26-b3c8-dbf6-de1f-5c6ae4a5a705@linaro.org>
Date:   Thu, 1 Dec 2022 02:21:58 +0200
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Kuogee Hsieh <quic_khsieh@...cinc.com>,
        dri-devel@...ts.freedesktop.org, robdclark@...il.com,
        sean@...rly.run, swboyd@...omium.org, dianders@...omium.org,
        vkoul@...nel.org, daniel@...ll.ch, airlied@...ux.ie,
        agross@...nel.org, bjorn.andersson@...aro.org
Cc:     quic_abhinavk@...cinc.com, quic_sbillaka@...cinc.com,
        freedreno@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/4] arm64: dts: qcom: add data-lanes and
 link-freuencies into dp_out endpoint

On 01/12/2022 02:07, Dmitry Baryshkov wrote:
> On 01/12/2022 01:51, Kuogee Hsieh wrote:
>> Move data-lanes property from mdss_dp node to dp_out endpoint. Also
>> add link-frequencies property into dp_out endpoint as well. The last
>> frequency specified at link-frequencies will be the max link rate
>> supported by DP.
>>
>> Changes in v5:
>> -- revert changes at sc7180.dtsi and sc7280.dtsi
>> -- add &dp_out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
>>
>> Changes in v6:
>> -- add data-lanes and link-frequencies to yaml
>>
>> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
>> ---
>>   .../devicetree/bindings/display/msm/dp-controller.yaml  | 17 
>> +++++++++++++++++
> 
> Separate patch. Also you didn't check the get_maintainers output, so 
> required parties were not included into the distribution.
> 
> Also as you'd check the get_maintainers output, please fix other email 
> addresses too.
> 
>>   arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi            |  6 +++++-
>>   arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi          |  6 +++++-
>>   3 files changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> index 94bc6e1..af70343 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> @@ -90,6 +90,20 @@ properties:
>>           $ref: /schemas/graph.yaml#/properties/port
>>           description: Output endpoint of the controller
>> +        properties:
>> +          endpoint:
>> +            $ref: /schemas/media/video-interfaces.yaml#
>> +
>> +          properties:
>> +            link-frequencies: true
>> +            data-lanes: true
> 
> No. Use $ref for both of them.
> 
>> +
>> +          required:
>> +            - link-frequencies
>> +            - data-lanes
> 
> No, they are not required.
> 
>> +
>> +          additionalProperties: false
>> +
> 
> deprecation of old data-lanes property?
> 
>>   required:
>>     - compatible
>>     - reg
>> @@ -158,6 +172,9 @@ examples:
>>                   reg = <1>;
>>                   endpoint {
>>                       remote-endpoint = <&typec>;
>> +                    data-lanes = <1 2>;
>> +                    link-frequencies = /bits/ 64 <160000000 270000000

s/1600/1620

>> +                                                  540000000 810000000>;
> 
> I guess the number of zeroes is wrong here. This is 160 MHz ... 810 Mhz, 
> rather than 1.6 GHz ... 8.1 GHz

Ok, I was wrong here. The old code definitely defaults to 570 
mega-something. Now I'd really like to read your description for the 
link-frequencies property, because the phy_configure_opts_dp::link_rate 
is clearly specified in Mb/s and it takes a fixed set of values from 
1.62 Gb/s up to 8.1 Gb/s.

I think the drm_dp_bw_code_to_link_rate() function is incorrect by 
itself, as it multiplies with 27000 (27 Mbps) rather than 270000 (0.27 
Gbps) as required by the standard. So first, we should fix the function, 
then all the rates would become logical.


> 
>>                   };
>>               };
>>           };
>> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi 
>> b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> index 754d2d6..39f0844 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
>> @@ -812,7 +812,11 @@ hp_i2c: &i2c9 {
>>       status = "okay";
>>       pinctrl-names = "default";
>>       pinctrl-0 = <&dp_hot_plug_det>;
>> -    data-lanes = <0 1>;
>> +};
>> +
>> +&dp_out {
>> +    data-lanes = <0  1>;
>> +    link-frequencies = /bits/ 64 <160000000 270000000 540000000>;
> 
> Same comment here.
> 
>>   };
>>   &pm6150_adc {
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi 
>> b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>> index 93e39fc..b7c343d 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
>> @@ -440,7 +440,11 @@ ap_i2c_tpm: &i2c14 {
>>       status = "okay";
>>       pinctrl-names = "default";
>>       pinctrl-0 = <&dp_hot_plug_det>;
>> -    data-lanes = <0 1>;
>> +};
>> +
>> +&dp_out {
>> +    data-lanes = <0  1>;
>> +    link-frequencies = /bits/ 64 <160000000 270000000 540000000 
>> 810000000>;
> 
> And here.
> 
>>   };
>>   &mdss_mdp {
> 

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ