diff mbox series

[RFC,v2,4/5] ARM: dts: qcom: msm8974: add HDMI nodes

Message ID 20191007014509.25180-5-masneyb@onstation.org (mailing list archive)
State New, archived
Headers show
Series drm/msm: external HDMI support for Nexus 5 phone | expand

Commit Message

Brian Masney Oct. 7, 2019, 1:45 a.m. UTC 
Add HDMI tx and phy nodes to support an external display that can be
connected over the SlimPort. This is based on work from Jonathan Marek.

Signed-off-by: Brian Masney <masneyb@onstation.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes since v1:
- Add hdmi_pll to hdmi-phy node
- add power-domain to hdmi-phy per binding specification
- Remove FIXME comment regarding the hpd-gdsc-supply. I saw a recent
  post on linux-arm-msm that this is present for running the upstream
  MSM display driver on the downstream kernel.

 arch/arm/boot/dts/qcom-msm8974.dtsi | 78 +++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)

Comments

Stephen Boyd Oct. 9, 2019, 2:21 a.m. UTC | #1 
Quoting Brian Masney (2019-10-06 18:45:08)
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 7fc23e422cc5..af02eace14e2 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -1335,6 +1342,77 @@
>                                 clocks = <&mmcc MDSS_AHB_CLK>;
>                                 clock-names = "iface";
>                         };
> +
> +                       hdmi: hdmi-tx@fd922100 {
> +                               status = "disabled";
> +
> +                               compatible = "qcom,hdmi-tx-8974";
> +                               reg = <0xfd922100 0x35c>,
> +                                     <0xfc4b8000 0x60f0>;
> +                               reg-names = "core_physical",
> +                                           "qfprom_physical";

Is this the qfprom "uncorrected" physical address? If so, why can't this
node use an nvmem to read whatever it needs out of the qfprom?

> +
> +                               interrupt-parent = <&mdss>;
> +                               interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
> +
> +                               power-domains = <&mmcc MDSS_GDSC>;
> +
Brian Masney Oct. 9, 2019, 6:05 a.m. UTC | #2 
On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> Quoting Brian Masney (2019-10-06 18:45:08)
> > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > index 7fc23e422cc5..af02eace14e2 100644
> > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > @@ -1335,6 +1342,77 @@
> >                                 clocks = <&mmcc MDSS_AHB_CLK>;
> >                                 clock-names = "iface";
> >                         };
> > +
> > +                       hdmi: hdmi-tx@fd922100 {
> > +                               status = "disabled";
> > +
> > +                               compatible = "qcom,hdmi-tx-8974";
> > +                               reg = <0xfd922100 0x35c>,
> > +                                     <0xfc4b8000 0x60f0>;
> > +                               reg-names = "core_physical",
> > +                                           "qfprom_physical";
> 
> Is this the qfprom "uncorrected" physical address? If so, why can't this
> node use an nvmem to read whatever it needs out of the qfprom?

The MSM HDMI code is configured to look for this reg-name here:

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L582

There is a qcom,qfprom configured for this board in DTS, however its at
a different address range, so maybe there are multiple qfproms?

https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/qcom-msm8974.dtsi#L424

msm8996.dtsi has the same style of configuration:

https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L956
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L1736

Brian
Stephen Boyd Oct. 9, 2019, 3:39 p.m. UTC | #3 
Quoting Brian Masney (2019-10-08 23:05:20)
> On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > Quoting Brian Masney (2019-10-06 18:45:08)
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > index 7fc23e422cc5..af02eace14e2 100644
> > > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > @@ -1335,6 +1342,77 @@
> > >                                 clocks = <&mmcc MDSS_AHB_CLK>;
> > >                                 clock-names = "iface";
> > >                         };
> > > +
> > > +                       hdmi: hdmi-tx@fd922100 {
> > > +                               status = "disabled";
> > > +
> > > +                               compatible = "qcom,hdmi-tx-8974";
> > > +                               reg = <0xfd922100 0x35c>,
> > > +                                     <0xfc4b8000 0x60f0>;
> > > +                               reg-names = "core_physical",
> > > +                                           "qfprom_physical";
> > 
> > Is this the qfprom "uncorrected" physical address? If so, why can't this
> > node use an nvmem to read whatever it needs out of the qfprom?
> 
> The MSM HDMI code is configured to look for this reg-name here:
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L582
> 
> There is a qcom,qfprom configured for this board in DTS, however its at
> a different address range, so maybe there are multiple qfproms?
> 
> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/qcom-msm8974.dtsi#L424
> 
> msm8996.dtsi has the same style of configuration:
> 
> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L956
> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L1736
> 

There's only one qfprom and there's the address space that's
"uncorrected" which is not supposed to be used and there's the space
that is "corrected" and is supposed to be used. It looks like this is
poking the uncorrected space and it should probably stop doing that and
use the nvmem provider instead. Maybe someone with docs for this chip
and 8996 can help confirm this.
Stephen Boyd Oct. 9, 2019, 3:39 p.m. UTC | #4 
Quoting Brian Masney (2019-10-08 23:05:20)
> On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > Quoting Brian Masney (2019-10-06 18:45:08)
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > index 7fc23e422cc5..af02eace14e2 100644
> > > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > @@ -1335,6 +1342,77 @@
> > >                                 clocks = <&mmcc MDSS_AHB_CLK>;
> > >                                 clock-names = "iface";
> > >                         };
> > > +
> > > +                       hdmi: hdmi-tx@fd922100 {
> > > +                               status = "disabled";
> > > +
> > > +                               compatible = "qcom,hdmi-tx-8974";
> > > +                               reg = <0xfd922100 0x35c>,
> > > +                                     <0xfc4b8000 0x60f0>;
> > > +                               reg-names = "core_physical",
> > > +                                           "qfprom_physical";
> > 
> > Is this the qfprom "uncorrected" physical address? If so, why can't this
> > node use an nvmem to read whatever it needs out of the qfprom?
> 
> The MSM HDMI code is configured to look for this reg-name here:
> 
> https://secure-web.cisco.com/1e-Pyq4y_qpcGPhA2iOmixFUEBB10LpnazjXpsdDziVrgUMLUBz3tMGXh-PNfXMZnisUId0QBxThjIKAG0_TMzn4UYbhYF4jUDCm4KAzXkV3dAMLXLEAWbrEEE0HIysJVXNn4OY6I-VD8H6CLb3jzyQC2o07KUYuETHUrULIS59un1x-WaYgBTK9RJHPQEv-1vBqTjDoohTeHbmyZlpRsl2Uv4VkW6e1U_PohoSlpXcfmvSR82VhEbsmlveG9v2lUxZaHhh5IRDLa8gP4j79r31Ki52H7zRsQaoctWUdszUObgAKIw6hA2bryE1oP2DvEywBSN4jBW2-YtnuAjyLRljH63H1--8glNXE3e1FEujfnzkYOwbJkyyTBTbopeeLdDPBBl4_Pr4dukD5reBGrVK1VJiZOM0HO2StARsXlAA6bD0qyiWEIV2lijdUDqSQLOCQlRrABqJjoCmVvjuQx9g/https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Fmsm%2Fhdmi%2Fhdmi.c#L582
> 
> There is a qcom,qfprom configured for this board in DTS, however its at
> a different address range, so maybe there are multiple qfproms?
> 
> https://secure-web.cisco.com/1sdOdWdlFZtzWXH_aUBemIiQ_7XxD_RWN5i0x_BCvISXae_1OXOC6KTSnVpknKNxWzIsR-gM9xVzoIMEpl2_qAx5qoS606iQmnLSIawQdIKjitqDH-S9KtHfDh7EqFuTBZ4BHmqn41jzInFZlyERO6H9PETROXwArYGwXdDkj5FEU4jHstJ9MgzPX4Dh7AezfRJtorZhbSSSO7NZv6JRZYrrlFKuFzFql_sVnBkk-yAwpuMljSWnQpMPztkdZSHKVOifbVdEGtxlE3MrYcdC5rDefEFsDImq694xNLPHwTh0zNBGUp0WDmmJFfW9x5h3yFv8U-VFHIkFNxw1IYHcdL3_vN3YFCwNfl70D-gbGbLqaHnxkeYcT-v4RmGvlAFBFJghjoR-ZvJkry0SdEU4pTtrglYB8ABQTO8pWkTZxbPFGF2avroQT_RJGO-BO9ZLNPw2k3UFBeJMiX-zCHCNu8w/https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm%2Fboot%2Fdts%2Fqcom-msm8974.dtsi#L424
> 
> msm8996.dtsi has the same style of configuration:
> 
> https://secure-web.cisco.com/1rJa-0EPy0JlP-77k9dsB-DH2ZCq14Si9lknMNgsjQ1mU9AwMRl-fj_8DtwWfDAvntMcoFwbCHPQJNuwpC_KMHLcdm4FZ0RnRUtfz88pGXEjWTWienXj9Fl9TM0KoV4HkX0RA2sLF76j3KeyBIwZnG6VHLIPrLTpfAdhFSNZ8MmzdgZMypbVSO3IEPpA7zNP3qEQgyqE27tuAhH8y6QnexVkFPCjMcfHXi-vrbHNksoux0XR69MifJ4WmNUAkFtomCx_lJrx_op43jhFzOocBi8_enFUQYk_8w1qdGRx3GMasff9wNskI-437xlPDmEkikHiwGB8pOvvnE9E8mWJ_sgQxEVikyuLwGDD6KBINl-Tit6NNjkHDkS4YQP-FdZjAoOSzRXP7gOFeIhgCAdbka4VM_VCaqXhzcgWfCypMMh33r9tyK7STs3Pw0IICGZuYPbgt0P2Nrnd1R__OAmOhPQ/https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2Fqcom%2Fmsm8996.dtsi#L956
> https://secure-web.cisco.com/1rJa-0EPy0JlP-77k9dsB-DH2ZCq14Si9lknMNgsjQ1mU9AwMRl-fj_8DtwWfDAvntMcoFwbCHPQJNuwpC_KMHLcdm4FZ0RnRUtfz88pGXEjWTWienXj9Fl9TM0KoV4HkX0RA2sLF76j3KeyBIwZnG6VHLIPrLTpfAdhFSNZ8MmzdgZMypbVSO3IEPpA7zNP3qEQgyqE27tuAhH8y6QnexVkFPCjMcfHXi-vrbHNksoux0XR69MifJ4WmNUAkFtomCx_lJrx_op43jhFzOocBi8_enFUQYk_8w1qdGRx3GMasff9wNskI-437xlPDmEkikHiwGB8pOvvnE9E8mWJ_sgQxEVikyuLwGDD6KBINl-Tit6NNjkHDkS4YQP-FdZjAoOSzRXP7gOFeIhgCAdbka4VM_VCaqXhzcgWfCypMMh33r9tyK7STs3Pw0IICGZuYPbgt0P2Nrnd1R__OAmOhPQ/https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2Fqcom%2Fmsm8996.dtsi#L1736
> 

There's only one qfprom and there's the address space that's
"uncorrected" which is not supposed to be used and there's the space
that is "corrected" and is supposed to be used. It looks like this is
poking the uncorrected space and it should probably stop doing that and
use the nvmem provider instead. Maybe someone with docs for this chip
and 8996 can help confirm this.
Brian Masney Oct. 9, 2019, 4:51 p.m. UTC | #5 
On Wed, Oct 09, 2019 at 08:39:26AM -0700, Stephen Boyd wrote:
> Quoting Brian Masney (2019-10-08 23:05:20)
> > On Tue, Oct 08, 2019 at 07:21:30PM -0700, Stephen Boyd wrote:
> > > Quoting Brian Masney (2019-10-06 18:45:08)
> > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > index 7fc23e422cc5..af02eace14e2 100644
> > > > --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > > @@ -1335,6 +1342,77 @@
> > > >                                 clocks = <&mmcc MDSS_AHB_CLK>;
> > > >                                 clock-names = "iface";
> > > >                         };
> > > > +
> > > > +                       hdmi: hdmi-tx@fd922100 {
> > > > +                               status = "disabled";
> > > > +
> > > > +                               compatible = "qcom,hdmi-tx-8974";
> > > > +                               reg = <0xfd922100 0x35c>,
> > > > +                                     <0xfc4b8000 0x60f0>;
> > > > +                               reg-names = "core_physical",
> > > > +                                           "qfprom_physical";
> > > 
> > > Is this the qfprom "uncorrected" physical address? If so, why can't this
> > > node use an nvmem to read whatever it needs out of the qfprom?
> > 
> > The MSM HDMI code is configured to look for this reg-name here:
> > 
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/hdmi/hdmi.c#L582
> > 
> > There is a qcom,qfprom configured for this board in DTS, however its at
> > a different address range, so maybe there are multiple qfproms?
> > 
> > https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/qcom-msm8974.dtsi#L424
> > 
> > msm8996.dtsi has the same style of configuration:
> > 
> > https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L956
> > https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L1736
> > 
> 
> There's only one qfprom and there's the address space that's
> "uncorrected" which is not supposed to be used and there's the space
> that is "corrected" and is supposed to be used. It looks like this is
> poking the uncorrected space and it should probably stop doing that and
> use the nvmem provider instead. Maybe someone with docs for this chip
> and 8996 can help confirm this.

Do you know of any publicly-available documentation that describes the
"uncorrected" and "corrected" addresses? I got that qfprom address for
the HDMI from here:

https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-mdss.dtsi#L101

I assume the downstream kernel probably doesn't have the corrected
address anywhere else?

Brian
diff mbox series

Patch

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 7fc23e422cc5..af02eace14e2 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1258,6 +1258,13 @@ 
 
 					port@0 {
 						reg = <0>;
+						mdp5_intf3_out: endpoint {
+							remote-endpoint = <&hdmi_in>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
 						mdp5_intf1_out: endpoint {
 							remote-endpoint = <&dsi0_in>;
 						};
@@ -1335,6 +1342,77 @@ 
 				clocks = <&mmcc MDSS_AHB_CLK>;
 				clock-names = "iface";
 			};
+
+			hdmi: hdmi-tx@fd922100 {
+				status = "disabled";
+
+				compatible = "qcom,hdmi-tx-8974";
+				reg = <0xfd922100 0x35c>,
+				      <0xfc4b8000 0x60f0>;
+				reg-names = "core_physical",
+				            "qfprom_physical";
+
+				interrupt-parent = <&mdss>;
+				interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+
+				power-domains = <&mmcc MDSS_GDSC>;
+
+				clocks = <&mmcc MDSS_MDP_CLK>,
+				         <&mmcc MDSS_AHB_CLK>,
+				         <&mmcc MDSS_HDMI_CLK>,
+				         <&mmcc MDSS_HDMI_AHB_CLK>,
+				         <&mmcc MDSS_EXTPCLK_CLK>;
+				clock-names = "mdp_core",
+				              "iface",
+				              "core",
+				              "alt_iface",
+				              "extp";
+
+				hpd-5v-supply = <&pm8941_5vs2>;
+				core-vdda-supply = <&pm8941_l12>;
+				core-vcc-supply = <&pm8941_s3>;
+
+				phys = <&hdmi_phy>;
+				phy-names = "hdmi_phy";
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port@0 {
+						reg = <0>;
+						hdmi_in: endpoint {
+							remote-endpoint = <&mdp5_intf3_out>;
+						};
+					};
+
+					port@1 {
+						reg = <1>;
+					};
+				};
+			};
+
+			hdmi_phy: hdmi-phy@fd922500 {
+				status = "disabled";
+
+				compatible = "qcom,hdmi-phy-8974";
+				reg = <0xfd922500 0x7c>,
+				      <0xfd922700 0xd4>;
+				reg-names = "hdmi_phy",
+				            "hdmi_pll";
+
+				clocks = <&mmcc MDSS_AHB_CLK>,
+				         <&mmcc MDSS_HDMI_AHB_CLK>;
+				clock-names = "iface",
+				              "alt_iface";
+
+				core-vdda-supply = <&pm8941_l12>;
+				vddio-supply = <&pm8941_s3>;
+
+				power-domains = <&mmcc MDSS_GDSC>;
+
+				#phy-cells = <0>;
+			};
 		};
 	};