| Message ID | 20190505130413.32253-5-masneyb@onstation.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: qcom: initial Nexus 5 display support | expand |
On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi [..] > + dsi0: dsi@fd922800 { > + status = "disabled"; > + > + compatible = "qcom,mdss-dsi-ctrl"; > + reg = <0xfd922800 0x1f8>; > + reg-names = "dsi_ctrl"; > + > + interrupt-parent = <&mdss>; > + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>; > + > + assigned-clocks = <&mmcc BYTE0_CLK_SRC>, > + <&mmcc PCLK0_CLK_SRC>; > + assigned-clock-parents = <&dsi_phy0 0>, > + <&dsi_phy0 1>; > + > + clocks = <&mmcc MDSS_MDP_CLK>, > + <&mmcc MDSS_AHB_CLK>, > + <&mmcc MDSS_AXI_CLK>, > + <&mmcc MDSS_BYTE0_CLK>, > + <&mmcc MDSS_PCLK0_CLK>, > + <&mmcc MDSS_ESC0_CLK>, > + <&mmcc MMSS_MISC_AHB_CLK>; > + clock-names = "mdp_core", > + "iface", > + "bus", > + "byte", > + "pixel", > + "core", > + "core_mmss"; Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some underrun error from DSI. You don't see anything like this? (These clocks are controlled by msm_bus downstream and should be driven by interconnect upstream) Apart from this, I think this looks nice. Happy to see the progress. Regards, Bjorn
On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > [..] > > + clocks = <&mmcc MDSS_MDP_CLK>, > > + <&mmcc MDSS_AHB_CLK>, > > + <&mmcc MDSS_AXI_CLK>, > > + <&mmcc MDSS_BYTE0_CLK>, > > + <&mmcc MDSS_PCLK0_CLK>, > > + <&mmcc MDSS_ESC0_CLK>, > > + <&mmcc MMSS_MISC_AHB_CLK>; > > + clock-names = "mdp_core", > > + "iface", > > + "bus", > > + "byte", > > + "pixel", > > + "core", > > + "core_mmss"; > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > underrun error from DSI. You don't see anything like this? > > (These clocks are controlled by msm_bus downstream and should be driven > by interconnect upstream) > > > Apart from this, I think this looks nice. Happy to see the progress. No, I'm not seeing an underrun errors from the DSI. I think the clocks are fine since I'm able to get this working with 4.17 using these same clocks. I just sent out v2 and the cover letter has some details, along with the full dmesg. Brian
On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote: > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > > [..] > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > + <&mmcc MDSS_AHB_CLK>, > > > + <&mmcc MDSS_AXI_CLK>, > > > + <&mmcc MDSS_BYTE0_CLK>, > > > + <&mmcc MDSS_PCLK0_CLK>, > > > + <&mmcc MDSS_ESC0_CLK>, > > > + <&mmcc MMSS_MISC_AHB_CLK>; > > > + clock-names = "mdp_core", > > > + "iface", > > > + "bus", > > > + "byte", > > > + "pixel", > > > + "core", > > > + "core_mmss"; > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > underrun error from DSI. You don't see anything like this? > > > > (These clocks are controlled by msm_bus downstream and should be driven > > by interconnect upstream) > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > are fine since I'm able to get this working with 4.17 using these same > clocks. I just sent out v2 and the cover letter has some details, along > with the full dmesg. since we don't have interconnect driver for 8974, I guess there is some chance that things work or not based on how lk leaves things? BR, -R
On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote: > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > [..] > > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > > + <&mmcc MDSS_AHB_CLK>, > > > > + <&mmcc MDSS_AXI_CLK>, > > > > + <&mmcc MDSS_BYTE0_CLK>, > > > > + <&mmcc MDSS_PCLK0_CLK>, > > > > + <&mmcc MDSS_ESC0_CLK>, > > > > + <&mmcc MMSS_MISC_AHB_CLK>; > > > > + clock-names = "mdp_core", > > > > + "iface", > > > > + "bus", > > > > + "byte", > > > > + "pixel", > > > > + "core", > > > > + "core_mmss"; > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > underrun error from DSI. You don't see anything like this? > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > by interconnect upstream) > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > are fine since I'm able to get this working with 4.17 using these same > > clocks. I just sent out v2 and the cover letter has some details, along > > with the full dmesg. > > since we don't have interconnect driver for 8974, I guess there is > some chance that things work or not based on how lk leaves things? > Right, I guess the bootloader on my device does not leave the busses ticking - perhaps there's a boot splash involved on Brian's device? Regardless, this works on Nexus 5 and allows Brian to make further progress so I'm all for merging it. Regards, Bjorn
On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote: > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > > > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote: > > > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > [..] > > > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > > > + <&mmcc MDSS_AHB_CLK>, > > > > > + <&mmcc MDSS_AXI_CLK>, > > > > > + <&mmcc MDSS_BYTE0_CLK>, > > > > > + <&mmcc MDSS_PCLK0_CLK>, > > > > > + <&mmcc MDSS_ESC0_CLK>, > > > > > + <&mmcc MMSS_MISC_AHB_CLK>; > > > > > + clock-names = "mdp_core", > > > > > + "iface", > > > > > + "bus", > > > > > + "byte", > > > > > + "pixel", > > > > > + "core", > > > > > + "core_mmss"; > > > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > > underrun error from DSI. You don't see anything like this? > > > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > > by interconnect upstream) > > > > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > > are fine since I'm able to get this working with 4.17 using these same > > > clocks. I just sent out v2 and the cover letter has some details, along > > > with the full dmesg. > > > > since we don't have interconnect driver for 8974, I guess there is > > some chance that things work or not based on how lk leaves things? > > > > Right, I guess the bootloader on my device does not leave the busses > ticking - perhaps there's a boot splash involved on Brian's device? > > Regardless, this works on Nexus 5 and allows Brian to make further > progress so I'm all for merging it. There is a boot splash on the Nexus 5 and that may explain a behavior that I observed. I attempted to add reset GPIO support to the simple panel driver and the screen will clear but nothing will come on the screen after a hard reset, even on 4.17. To be sure, I got the timing information for how long to leave the GPIO high and low from the downstream MSM 3.4 sources. That's when I had a script port all of the ~400 panel on commands in the downstream device tree to a new panel driver. With the latest kernel kernel having a delay showing the console text, I observe a brief second where the boot splash is shown along with the startup text from Linux. A full refresh is performed and the boot splash goes away. I don't see this with the 4.17 kernel; perhaps maybe the full refresh occurs quick enough that its not noticeable. Can you point me to where the interconnect API is in the downstream MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead It looks like its in drivers/interconnect/ in the upstream sources. Brian
On Thu, May 9, 2019 at 12:12 AM Brian Masney <masneyb@onstation.org> wrote: > > On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote: > > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > > > > > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote: > > > > > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > > [..] > > > > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > > > > + <&mmcc MDSS_AHB_CLK>, > > > > > > + <&mmcc MDSS_AXI_CLK>, > > > > > > + <&mmcc MDSS_BYTE0_CLK>, > > > > > > + <&mmcc MDSS_PCLK0_CLK>, > > > > > > + <&mmcc MDSS_ESC0_CLK>, > > > > > > + <&mmcc MMSS_MISC_AHB_CLK>; > > > > > > + clock-names = "mdp_core", > > > > > > + "iface", > > > > > > + "bus", > > > > > > + "byte", > > > > > > + "pixel", > > > > > > + "core", > > > > > > + "core_mmss"; > > > > > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > > > underrun error from DSI. You don't see anything like this? > > > > > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > > > by interconnect upstream) > > > > > > > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > > > are fine since I'm able to get this working with 4.17 using these same > > > > clocks. I just sent out v2 and the cover letter has some details, along > > > > with the full dmesg. > > > > > > since we don't have interconnect driver for 8974, I guess there is > > > some chance that things work or not based on how lk leaves things? > > > > > > > Right, I guess the bootloader on my device does not leave the busses > > ticking - perhaps there's a boot splash involved on Brian's device? > > > > Regardless, this works on Nexus 5 and allows Brian to make further > > progress so I'm all for merging it. > > There is a boot splash on the Nexus 5 and that may explain a behavior > that I observed. I attempted to add reset GPIO support to the simple > panel driver and the screen will clear but nothing will come on the > screen after a hard reset, even on 4.17. To be sure, I got the timing > information for how long to leave the GPIO high and low from the > downstream MSM 3.4 sources. That's when I had a script port all of the > ~400 panel on commands in the downstream device tree to a new panel > driver. > > With the latest kernel kernel having a delay showing the console text, > I observe a brief second where the boot splash is shown along with the > startup text from Linux. A full refresh is performed and the boot > splash goes away. I don't see this with the 4.17 kernel; perhaps maybe > the full refresh occurs quick enough that its not noticeable. > > Can you point me to where the interconnect API is in the downstream > MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead > It looks like its in drivers/interconnect/ in the upstream sources. > Looks like this is the thing: https://github.com/AICP/kernel_lge_hammerhead/tree/n7.1/arch/arm/mach-msm/msm_bus (ahh, mach-msm... blast from the past..) BR, -R
On Thu 09 May 00:12 PDT 2019, Brian Masney wrote: > On Wed, May 08, 2019 at 08:00:47PM -0700, Bjorn Andersson wrote: > > On Wed 08 May 19:25 PDT 2019, Rob Clark wrote: > > > > > On Wed, May 8, 2019 at 7:16 PM Brian Masney <masneyb@onstation.org> wrote: > > > > > > > > On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote: > > > > > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote: > > > > > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi > > > > > [..] > > > > > > + clocks = <&mmcc MDSS_MDP_CLK>, > > > > > > + <&mmcc MDSS_AHB_CLK>, > > > > > > + <&mmcc MDSS_AXI_CLK>, > > > > > > + <&mmcc MDSS_BYTE0_CLK>, > > > > > > + <&mmcc MDSS_PCLK0_CLK>, > > > > > > + <&mmcc MDSS_ESC0_CLK>, > > > > > > + <&mmcc MMSS_MISC_AHB_CLK>; > > > > > > + clock-names = "mdp_core", > > > > > > + "iface", > > > > > > + "bus", > > > > > > + "byte", > > > > > > + "pixel", > > > > > > + "core", > > > > > > + "core_mmss"; > > > > > > > > > > Unless I enable MMSS_MMSSNOC_AXI_CLK and MMSS_S0_AXI_CLK I get some > > > > > underrun error from DSI. You don't see anything like this? > > > > > > > > > > (These clocks are controlled by msm_bus downstream and should be driven > > > > > by interconnect upstream) > > > > > > > > > > > > > > > Apart from this, I think this looks nice. Happy to see the progress. > > > > > > > > No, I'm not seeing an underrun errors from the DSI. I think the clocks > > > > are fine since I'm able to get this working with 4.17 using these same > > > > clocks. I just sent out v2 and the cover letter has some details, along > > > > with the full dmesg. > > > > > > since we don't have interconnect driver for 8974, I guess there is > > > some chance that things work or not based on how lk leaves things? > > > > > > > Right, I guess the bootloader on my device does not leave the busses > > ticking - perhaps there's a boot splash involved on Brian's device? > > > > Regardless, this works on Nexus 5 and allows Brian to make further > > progress so I'm all for merging it. > > There is a boot splash on the Nexus 5 and that may explain a behavior > that I observed. I attempted to add reset GPIO support to the simple > panel driver and the screen will clear but nothing will come on the > screen after a hard reset, even on 4.17. To be sure, I got the timing > information for how long to leave the GPIO high and low from the > downstream MSM 3.4 sources. That's when I had a script port all of the > ~400 panel on commands in the downstream device tree to a new panel > driver. > > With the latest kernel kernel having a delay showing the console text, > I observe a brief second where the boot splash is shown along with the > startup text from Linux. A full refresh is performed and the boot > splash goes away. I don't see this with the 4.17 kernel; perhaps maybe > the full refresh occurs quick enough that its not noticeable. > > Can you point me to where the interconnect API is in the downstream > MSM 3.4 sources? https://github.com/AICP/kernel_lge_hammerhead > It looks like its in drivers/interconnect/ in the upstream sources. > The data will be 8974 specific, but the plumbing should be reusable from 8916 or 404. Hopefully we can get those landed shortly. You can find the latest incarnation here: https://lore.kernel.org/lkml/20190415104357.5305-1-georgi.djakov@linaro.org/ Regards, Bjorn
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi index 45b5c8ef0374..3f613c5b95a1 100644 --- a/arch/arm/boot/dts/qcom-msm8974.dtsi +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi @@ -3,6 +3,7 @@ #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/qcom,gcc-msm8974.h> +#include <dt-bindings/clock/qcom,mmcc-msm8974.h> #include <dt-bindings/clock/qcom,rpmcc.h> #include <dt-bindings/reset/qcom,gcc-msm8974.h> #include <dt-bindings/gpio/gpio.h> @@ -1085,6 +1086,137 @@ }; }; }; + + mdss: mdss@fd900000 { + status = "disabled"; + + compatible = "qcom,mdss"; + reg = <0xfd900000 0x100>, + <0xfd924000 0x1000>; + reg-names = "mdss_phys", + "vbif_phys"; + + power-domains = <&mmcc MDSS_GDSC>; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_VSYNC_CLK>; + clock-names = "iface", + "bus", + "vsync"; + + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + + interrupt-controller; + #interrupt-cells = <1>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + mdp: mdp@fd900000 { + status = "disabled"; + + compatible = "qcom,mdp5"; + reg = <0xfd900100 0x22000>; + reg-names = "mdp_phys"; + + interrupt-parent = <&mdss>; + interrupts = <0 0>; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_VSYNC_CLK>; + clock-names = "iface", + "bus", + "core", + "vsync"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mdp5_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + }; + }; + + dsi0: dsi@fd922800 { + status = "disabled"; + + compatible = "qcom,mdss-dsi-ctrl"; + reg = <0xfd922800 0x1f8>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>; + + assigned-clocks = <&mmcc BYTE0_CLK_SRC>, + <&mmcc PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi_phy0 0>, + <&dsi_phy0 1>; + + clocks = <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_BYTE0_CLK>, + <&mmcc MDSS_PCLK0_CLK>, + <&mmcc MDSS_ESC0_CLK>, + <&mmcc MMSS_MISC_AHB_CLK>; + clock-names = "mdp_core", + "iface", + "bus", + "byte", + "pixel", + "core", + "core_mmss"; + + phys = <&dsi_phy0>; + phy-names = "dsi-phy"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&mdp5_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + }; + }; + }; + }; + + dsi_phy0: dsi-phy@fd922a00 { + status = "disabled"; + + compatible = "qcom,dsi-phy-28nm-hpm"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x280>, + <0xfd922d80 0x30>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + qcom,dsi-phy-index = <0>; + + clocks = <&mmcc MDSS_AHB_CLK>; + clock-names = "iface"; + }; + }; }; smd {
Add the MDP5, DSI and DSI PHY blocks for the display found on the msm8974 SoCs. This is based on work from msm8916.dtsi and Jonathan Marek. Signed-off-by: Brian Masney <masneyb@onstation.org> --- arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+)