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@ae94400 {
status = "disabled";
};
+
+ msm_dp: displayport-controller@ae90000 {
+ 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@xxxxxxxxxxxxxx/
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@af00000 {
@@ -2449,8 +2521,8 @@ dispcc: clock-controller@af00000 {
<&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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
