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] [day] [month] [year] [list]
Message-ID: <70d8a4f073abf7a038c9830ec6586709@codeaurora.org>
Date:   Wed, 12 Aug 2020 12:30:23 -0700
From:   Tanmay Shah <tanmay@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-arm-msm@...r.kernel.org, robdclark@...il.com,
        airlied@...ux.ie, linux-kernel@...r.kernel.org,
        abhinavk@...eaurora.org, khsieh@...eaurora.org,
        seanpaul@...omium.org, aravindh@...eaurora.org,
        freedreno@...ts.freedesktop.org,
        dri-devel <dri-devel-bounces@...ts.freedesktop.org>
Subject: Re: [PATCH v5] arm64: dts: qcom: sc7180: Add Display Port dt node

On 2020-08-11 12:30, Stephen Boyd wrote:
> Quoting Tanmay Shah (2020-08-10 19:15:53)
>> @@ -2440,6 +2447,71 @@ dsi_phy: dsi-phy@...4400 {
>> 
>>                                 status = "disabled";
>>                         };
>> +
>> +                       msm_dp: displayport-controller@...0000 {
>> +                               status = "disabled";
>> +                               compatible = "qcom,sc7180-dp";
>> +
>> +                               reg = <0 0x0ae90000 0 0x1400>;
>> +
>> +                               interrupt-parent = <&mdss>;
>> +                               interrupts = <12 IRQ_TYPE_NONE>;
> 
> Please drop the flags. It's not required per the binding. It should 
> just
> be a single number, i.e. <12>.
> 

Sure. I will change DP-bindings accordingly as well.

>> +
>> +                               clocks = <&dispcc 
>> DISP_CC_MDSS_AHB_CLK>,
>> +                                        <&dispcc
> DISP_CC_MDSS_DP_AUX_CLK>,
>> +                                        <&dispcc
> DISP_CC_MDSS_DP_LINK_CLK>,
>> +                                        <&dispcc
> DISP_CC_MDSS_DP_LINK_INTF_CLK>,
>> +                                        <&dispcc
> DISP_CC_MDSS_DP_PIXEL_CLK>;
>> +                               clock-names = "core_iface", 
>> "core_aux",
> "ctrl_link",
>> +                                             "ctrl_link_iface",
> "stream_pixel";
>> +                               #clock-cells = <1>;
>> +                               assigned-clocks = <&dispcc
> DISP_CC_MDSS_DP_LINK_CLK_SRC>,
>> +                                                 <&dispcc
> DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
>> +                               assigned-clock-parents = <&msm_dp 0>,
> <&msm_dp 1>;
>> +
>> +                               operating-points-v2 = <&dp_opp_table>;
>> +                               power-domains = <&rpmhpd SC7180_CX>;
> 
> Can you send another patch to add the hpd pinctrl binding for the hpd
> function? It would be useful to have that in the SoC level in case any
> board wants to use the hpd pin on this SoC without having to implement
> it themselves. It could be assigned here too as the pinctrl but I'm not
> sure if that is correct. Probably better to just have it in the SoC 
> file
> and then let boards pick to use it.
> 

We have tlmm node in sc7180.dtsi. We can define pinctrl definition for 
"dp_hot" funtionality there.

>> +
>> +                               ports {
>> +                                       #address-cells = <1>;
>> +                                       #size-cells = <0>;
>> +                                       port@0 {
>> +                                               reg = <0>;
>> +                                               dp_in: endpoint {
>> +                                                       
>> remote-endpoint
> = <&dpu_intf0_out>;
>> +                                               };
>> +                                       };
>> +
>> +                                       port@1 {
>> +                                               reg = <1>;
>> +                                               dp_out: endpoint { };
>> +                                       };
>> +                               };
>> +
>> +                               dp_opp_table: dp-opp-table {
> 
> Can this be called opp-table? I don't see the need to make it more
> specific given that it doesn't share the namespace at this level with
> anything else that is an opp table.
> 

DSI and MDP's OPP table names were posted here:
https://lore.kernel.org/dri-devel/1594292674-15632-4-git-send-email-rnayak@codeaurora.org/

So, It makes sense to keep naming conventions similar to dsi and mdp's 
opp table.

>> +                                       compatible =
> "operating-points-v2";
>> +
>> +                                       opp-160000000 {
>> +                                               opp-hz = /bits/ 64
> <160000000>;
>> +                                               required-opps =
> <&rpmhpd_opp_low_svs>;
>> +                                       };
>> +
>> +                                       opp-270000000 {
>> +                                               opp-hz = /bits/ 64
> <270000000>;
>> +                                               required-opps =
> <&rpmhpd_opp_svs>;
>> +                                       };
>> +
>> +                                       opp-540000000 {
>> +                                               opp-hz = /bits/ 64
> <540000000>;
>> +                                               required-opps =
> <&rpmhpd_opp_svs_l1>;
>> +                                       };
>> +
>> +                                       opp-810000000 {
>> +                                               opp-hz = /bits/ 64
> <810000000>;
>> +                                               required-opps =
> <&rpmhpd_opp_nom>;
>> +                                       };
>> +                               };
>> +                       };
>>                 };
>> 
>>                 dispcc: clock-controller@...0000 {
>> @@ -2449,8 +2521,8 @@ dispcc: clock-controller@...0000 {
>>                                  <&gcc GCC_DISP_GPLL0_CLK_SRC>,
>>                                  <&dsi_phy 0>,
>>                                  <&dsi_phy 1>,
>> -                                <0>,
>> -                                <0>;
>> +                                <&msm_dp 0>,
>> +                                <&msm_dp 1>;
> 
> This bit will have to change when the DP phy is split off into the qmp
> driver.
> 

Yes. It will be <&dp_phy 0> and <&dp_phy 1> assuming dp_phy is DP PHY 
dts node name.

>>                         clock-names = "bi_tcxo",
>>                                       "gcc_disp_gpll0_clk_src",
>>                                       "dsi0_phy_pll_out_byteclk",
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ