[PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[Brian Masney]

Here is a patch series that adds initial display support for the LG
Nexus 5 (hammerhead) phone. The board boots into terminal mode, however
there is a several second (or more) delay when writing to tty1 compared
to when the changes are actually shown on the screen. The following
errors are in dmesg:

    msm fd900000.mdss: pp done time out, lm=0
    [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out
    [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out

mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which
is causing this stack trace to be dumped into the system log several
times:

    WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
    [CRTC:49:crtc-0] vblank wait timed out
    Modules linked in:
    CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
    Hardware name: Generic DT based system
    Workqueue: events deferred_probe_work_func
    [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
    [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
    [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
    [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
    [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
    [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
    [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
    [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
    [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)
    ....

In mdp5_irq(), I see that a few vblank IRQ statuses (0x1000) come
through when the board boots, drm_handle_vblank() is called, and the
screen updates, however mdp5_get_scanoutpos() continues to return 0
after these operations complete.

I don't see any ping-pong done IRQ statuses (0x100) come through in
mdp5_irq().

I can get the text console to work with a 4.17 kernel with this patch
https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more
other patches that have been mainlined since that release. The pp done
and vblank messages still happen, however tty1 is updated when I write
to it and Wayland works.

The lg,acx467akm-7 panel listed below is currently handled by the simple
panel driver since it is sufficient for 4.17 kernel, but that may need
to change in the future for the power on commands. To be sure, I followed
the instructions at
https://github.com/freedreno/freedreno/wiki/DSI-Panel-Driver-Porting
for porting the almost 400 panel on commands from the downstream kernel
sources at
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-panel.dtsi#L645.
The screen turns all white when the panel display is turned on and the
panel exits sleep mode. Unfortunately, there are a lot of power on
commands listed in the downstream device tree that aren't listed in
mipi_display.h.

Thanks in advance for any advice that you can provide.

Brian Masney (6):
  drm/msm: fix null pointer dereference in msm_atomic_prepare_fb()
  drm/msm: add dirty framebuffer helper
  ARM: qcom_defconfig: add display-related options
  ARM: dts: msm8974: add display support
  ARM: dts: qcom: msm8974-hammerhead: add support for backlight
  ARM: dts: qcom: msm8974-hammerhead: add support for display

 .../qcom-msm8974-lge-nexus5-hammerhead.dts    |  79 +++++++++++
 arch/arm/boot/dts/qcom-msm8974.dtsi           | 132 ++++++++++++++++++
 arch/arm/configs/qcom_defconfig               |   5 +
 drivers/gpu/drm/msm/msm_atomic.c              |   8 +-
 drivers/gpu/drm/msm/msm_fb.c                  |   2 +
 5 files changed, 223 insertions(+), 3 deletions(-)

-- 
2.20.1

[PATCH RFC 1/6] drm/msm: fix null pointer dereference in msm_atomic_prepare_fb()

[Brian Masney]

_msm_gem_new() calls msm_gem_new_impl() with a NULL reservation_object
struct. msm_atomic_prepare_fb() assumes that the reservation_object is
always set, and attempts to reference a NULL pointer. Correct this by
checking to see if this value is NULL.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
 drivers/gpu/drm/msm/msm_atomic.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index f5b1256e32b6..0da80a93876a 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -56,10 +56,12 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
 		return 0;
 
 	obj = msm_framebuffer_bo(new_state->fb, 0);
-	msm_obj = to_msm_bo(obj);
-	fence = reservation_object_get_excl_rcu(msm_obj->resv);
 
-	drm_atomic_set_fence_for_plane(new_state, fence);
+	msm_obj = to_msm_bo(obj);
+	if (msm_obj->resv) {
+		fence = reservation_object_get_excl_rcu(msm_obj->resv);
+		drm_atomic_set_fence_for_plane(new_state, fence);
+	}
 
 	return msm_framebuffer_prepare(new_state->fb, kms->aspace);
 }
-- 
2.20.1

[PATCH RFC 2/6] drm/msm: add dirty framebuffer helper

[Brian Masney]

Add drm_atomic_helper_dirtyfb() callback to the msm framebuffer driver
for the dirty ioctl.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
 drivers/gpu/drm/msm/msm_fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 136058978e0f..8624a8e4025f 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -16,6 +16,7 @@
  */
 
 #include <drm/drm_crtc.h>
+#include <drm/drm_damage_helper.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_probe_helper.h>
 
@@ -35,6 +36,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev,
 static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
 	.create_handle = drm_gem_fb_create_handle,
 	.destroy = drm_gem_fb_destroy,
+	.dirty = drm_atomic_helper_dirtyfb,
 };
 
 #ifdef CONFIG_DEBUG_FS
-- 
2.20.1

[PATCH RFC 3/6] ARM: qcom_defconfig: add display-related options

[Brian Masney]

Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the
simple panel, and the TI LM3630A driver in order to support the display
on the LG Nexus 5 (hammerhead) phone.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
The panel and backlight are currently compiled into the kernel, but will
be moved to be modules once the display is fully working in a later
verison of this patch series.

 arch/arm/configs/qcom_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index c1854751c99a..4f02636f832e 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -37,6 +37,7 @@ CONFIG_ARM_CPUIDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_CMA=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -146,12 +147,14 @@ CONFIG_REGULATOR_QCOM_SMD_RPM=y
 CONFIG_REGULATOR_QCOM_SPMI=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_DRM=y
+CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_FB=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 # CONFIG_LCD_CLASS_DEVICE is not set
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 # CONFIG_BACKLIGHT_GENERIC is not set
+CONFIG_BACKLIGHT_LM3630A=y
 CONFIG_BACKLIGHT_LP855X=y
 CONFIG_SOUND=y
 CONFIG_SND=y
@@ -262,6 +265,8 @@ CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
+CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=256
 CONFIG_PRINTK_TIME=y
 CONFIG_DYNAMIC_DEBUG=y
 CONFIG_DEBUG_INFO=y
-- 
2.20.1

[PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Brian Masney]

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(+)

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 {
-- 
2.20.1

[PATCH RFC 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight

[Brian Masney]

Add necessary device tree nodes for the main LCD backlight.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
This requires this series that I submitted to the LED / backlight
subsystem:
https://lore.kernel.org/lkml/20190424092505.6578-1-masneyb@onstation.org/
It's received 3 {Reviewed,Acked}-Bys, and has no outstanding change
requests, so I expect it'll be merged soon.

 .../qcom-msm8974-lge-nexus5-hammerhead.dts    | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b3b04736a159..b7cf4b1019e9 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -289,6 +289,16 @@
 			};
 		};
 
+		i2c11_pins: i2c11 {
+			mux {
+				pins = "gpio83", "gpio84";
+				function = "blsp_i2c11";
+
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+
 		i2c12_pins: i2c12 {
 			mux {
 				pins = "gpio87", "gpio88";
@@ -369,6 +379,30 @@
 		};
 	};
 
+	i2c@f9967000 {
+		status = "ok";
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c11_pins>;
+		clock-frequency = <355000>;
+		qcom,src-freq = <50000000>;
+
+		led-controller@38 {
+			compatible = "ti,lm3630a";
+			status = "ok";
+			reg = <0x38>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			led@0 {
+				reg = <0>;
+				led-sources = <0 1>;
+				label = "lcd-backlight";
+				default-brightness = <200>;
+			};
+		};
+	};
+
 	i2c@f9968000 {
 		status = "ok";
 		pinctrl-names = "default";
-- 
2.20.1

[PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display

[Brian Masney]

Add initial support for the display found on the LG Nexus 5 (hammerhead)
phone.

Signed-off-by: Brian Masney <masneyb@onstation.org>
---
See the cover letter on this patch series for details about the issue
that I'm running into with this board.

 .../qcom-msm8974-lge-nexus5-hammerhead.dts    | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
index b7cf4b1019e9..749226e18ab5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -500,6 +500,51 @@
 			};
 		};
 	};
+
+	mdss@fd900000 {
+		status = "ok";
+
+		mdp@fd900000 {
+			status = "ok";
+		};
+
+		dsi@fd922800 {
+			status = "ok";
+
+			vdda-supply = <&pm8941_l2>;
+			vdd-supply = <&pm8941_lvs3>;
+			vddio-supply = <&pm8941_l12>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			ports {
+				port@1 {
+					endpoint {
+						remote-endpoint = <&panel_in>;
+						data-lanes = <0 1 2 3>;
+					};
+				};
+			};
+
+			panel: panel@0 {
+				reg = <0>;
+				compatible = "lg,acx467akm-7";
+
+				port {
+					panel_in: endpoint {
+						remote-endpoint = <&dsi0_out>;
+					};
+				};
+			};
+		};
+
+		dsi-phy@fd922a00 {
+			status = "ok";
+
+			vddio-supply = <&pm8941_l12>;
+		};
+	};
 };
 
 &spmi_bus {
-- 
2.20.1

Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which
> is causing this stack trace to be dumped into the system log several
> times:
>
>     WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
>     [CRTC:49:crtc-0] vblank wait timed out
>     Modules linked in:
>     CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
>     Hardware name: Generic DT based system
>     Workqueue: events deferred_probe_work_func
>     [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
>     [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
>     [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
>     [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
>     [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
>     [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
>     [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
>     [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
>     [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)

I recently merged this patch:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b3198c38f02d54a5e964258a2180d502abe6eaf0

I noticed that DSI is sometimes way slower than a monitor, even  in HS mode.
On the MCDE this happened on the first screen update, which was slower
than 50ms.

Check if your vblanks are simply slow, try bumping this timeout even higher,
I spent weeks finding this issue which boils down to an assumption that
the vblank will be fired from something like a monitor at 50 or 60 HZ
~20 ms so 50ms seemed like a good timeout at the time.

On a DSI display this is dubious, absolutely in LP mode, and even
in HS mode.

Yours,
Linus Walleij

Re: [PATCH RFC 3/6] ARM: qcom_defconfig: add display-related options

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> Add the CMA (Contiguous Memory Allocator) for the MSM DRM driver, the
> simple panel, and the TI LM3630A driver in order to support the display
> on the LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

> The panel and backlight are currently compiled into the kernel, but will
> be moved to be modules once the display is fully working in a later
> verison of this patch series.

I don't see why we would want to do that, the FB console is
traditionally (x86) good to alwaýs get up, as serial console
might not always be available. For example for people
who can't solder special cables but still want to boot a
custom ROM on their Nexus. So I'd say keep it like this.

Yours,
Linus Walleij

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> 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>

From my limited understanding it looks good:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> 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>

From my limited understanding it looks good:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH RFC 5/6] ARM: dts: qcom: msm8974-hammerhead: add support for backlight

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> Add necessary device tree nodes for the main LCD backlight.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

> This requires this series that I submitted to the LED / backlight
> subsystem:
> https://lore.kernel.org/lkml/20190424092505.6578-1-masneyb@onstation.org/
> It's received 3 {Reviewed,Acked}-Bys, and has no outstanding change
> requests, so I expect it'll be merged soon.

If the DT bindings are ACKed and reviewed we can merge DTS
files using it IMO.

Yours,
Linus Walleij

Re: [PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> Add initial support for the display found on the LG Nexus 5 (hammerhead)
> phone.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 6/6] ARM: dts: qcom: msm8974-hammerhead: add support for display

[Linus Walleij]

On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:

> Add initial support for the display found on the LG Nexus 5 (hammerhead)
> phone.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[Brian Masney]

On Mon, May 06, 2019 at 08:42:36AM +0200, Linus Walleij wrote:
> On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:
> 
> > mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which
> > is causing this stack trace to be dumped into the system log several
> > times:
> >
> >     WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
> >     [CRTC:49:crtc-0] vblank wait timed out
> >     Modules linked in:
> >     CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
> >     Hardware name: Generic DT based system
> >     Workqueue: events deferred_probe_work_func
> >     [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
> >     [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
> >     [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
> >     [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
> >     [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
> >     [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
> >     [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
> >     [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
> >     [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)
> 
> I recently merged this patch:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b3198c38f02d54a5e964258a2180d502abe6eaf0
> 
> I noticed that DSI is sometimes way slower than a monitor, even  in HS mode.
> On the MCDE this happened on the first screen update, which was slower
> than 50ms.
> 
> Check if your vblanks are simply slow, try bumping this timeout even higher,
> I spent weeks finding this issue which boils down to an assumption that
> the vblank will be fired from something like a monitor at 50 or 60 HZ
> ~20 ms so 50ms seemed like a good timeout at the time.
> 
> On a DSI display this is dubious, absolutely in LP mode, and even
> in HS mode.

That did not fix the issue for me, and I went as high as 5 seconds.
That's good to know though since I would have likely ran into that same
issue down the line.

Brian
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [PATCH RFC 0/6] ARM: qcom: initial Nexus 5 display support

[Brian Masney]

On Mon, May 06, 2019 at 08:42:36AM +0200, Linus Walleij wrote:
> On Sun, May 5, 2019 at 3:04 PM Brian Masney <masneyb@onstation.org> wrote:
> 
> > mdp5_get_scanoutpos() and mdp5_get_vblank_counter() both return 0, which
> > is causing this stack trace to be dumped into the system log several
> > times:
> >
> >     WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
> >     [CRTC:49:crtc-0] vblank wait timed out
> >     Modules linked in:
> >     CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
> >     Hardware name: Generic DT based system
> >     Workqueue: events deferred_probe_work_func
> >     [<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
> >     [<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
> >     [<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
> >     [<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
> >     [<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
> >     [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
> >     [<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
> >     [<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
> >     [<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)
> 
> I recently merged this patch:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b3198c38f02d54a5e964258a2180d502abe6eaf0
> 
> I noticed that DSI is sometimes way slower than a monitor, even  in HS mode.
> On the MCDE this happened on the first screen update, which was slower
> than 50ms.
> 
> Check if your vblanks are simply slow, try bumping this timeout even higher,
> I spent weeks finding this issue which boils down to an assumption that
> the vblank will be fired from something like a monitor at 50 or 60 HZ
> ~20 ms so 50ms seemed like a good timeout at the time.
> 
> On a DSI display this is dubious, absolutely in LP mode, and even
> in HS mode.

That did not fix the issue for me, and I went as high as 5 seconds.
That's good to know though since I would have likely ran into that same
issue down the line.

Brian

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Bjorn Andersson]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Brian Masney]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Rob Clark]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Bjorn Andersson]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Bjorn Andersson]

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
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Brian Masney]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Brian Masney]

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
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Rob Clark]

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

Re: [PATCH RFC 4/6] ARM: dts: msm8974: add display support

[Bjorn Andersson]

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