Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
[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
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 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.
I'm new to the DRM subsystem and continuing to dig into the issue, however I'd appreciate any suggestions. I suspect the issue lies somewhere in the second patch in this series.
Changes since v1: - Shortened problem description above. I'll reply to this email and send a full dmesg with the boot log with debugging turned on. - Dropped patch 'fix null pointer dereference in msm_atomic_prepare_fb()' - New patch: Remove resv fields from msm_gem_object struct that was incorrectly being referenced by the prepare_fb callbacks. - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5, and dpu1. - Add Linus Walleij's reviewed-by to patches 3-6
Brian Masney (6): drm: msm: remove resv fields from msm_gem_object struct 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/disp/dpu1/dpu_plane.c | 7 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 + drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 + drivers/gpu/drm/msm/msm_atomic.c | 4 +- drivers/gpu/drm/msm/msm_fb.c | 2 + drivers/gpu/drm/msm/msm_gem.c | 3 - drivers/gpu/drm/msm/msm_gem.h | 4 - 10 files changed, 229 insertions(+), 13 deletions(-)
The msm_gem_object structure contains resv and _resv fields that are no longer needed since the reservation object is now stored on drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb() both referenced the wrong reservation object, and would lead to an attempt to dereference a NULL pointer. Correct those two cases to point to the correct reservation object.
Signed-off-by: Brian Masney masneyb@onstation.org Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object reservation_object") --- Patch introduced in v2
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +--- drivers/gpu/drm/msm/msm_atomic.c | 4 +--- drivers/gpu/drm/msm/msm_gem.c | 3 --- drivers/gpu/drm/msm/msm_gem.h | 4 ---- 4 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index da1f727d7495..ce1a555e1f31 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -780,7 +780,6 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane, struct dpu_plane_state *pstate = to_dpu_plane_state(new_state); struct dpu_hw_fmt_layout layout; struct drm_gem_object *obj; - struct msm_gem_object *msm_obj; struct dma_fence *fence; struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base); int ret; @@ -799,8 +798,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane, * implicit fence and fb prepare by hand here. */ obj = msm_framebuffer_bo(new_state->fb, 0); - msm_obj = to_msm_bo(obj); - fence = reservation_object_get_excl_rcu(msm_obj->resv); + fence = reservation_object_get_excl_rcu(obj->resv); if (fence) drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index f5b1256e32b6..131c23a267ee 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -49,15 +49,13 @@ int msm_atomic_prepare_fb(struct drm_plane *plane, struct msm_drm_private *priv = plane->dev->dev_private; struct msm_kms *kms = priv->kms; struct drm_gem_object *obj; - struct msm_gem_object *msm_obj; struct dma_fence *fence;
if (!new_state->fb) 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); + fence = reservation_object_get_excl_rcu(obj->resv);
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 31d5a744d84f..947508e8269d 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev, msm_obj->flags = flags; msm_obj->madv = MSM_MADV_WILLNEED;
- if (resv) - msm_obj->base.resv = resv; - INIT_LIST_HEAD(&msm_obj->submit_entry); INIT_LIST_HEAD(&msm_obj->vmas);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h index c5ac781dffee..812d1b1369a5 100644 --- a/drivers/gpu/drm/msm/msm_gem.h +++ b/drivers/gpu/drm/msm/msm_gem.h @@ -86,10 +86,6 @@ struct msm_gem_object {
struct llist_node freed;
- /* normally (resv == &_resv) except for imported bo's */ - struct reservation_object *resv; - struct reservation_object _resv; - /* For physically contiguous buffers. Used when we don't have * an IOMMU. Also used for stolen/splashscreen buffer. */
On Wed 08 May 19:03 PDT 2019, Brian Masney wrote:
The msm_gem_object structure contains resv and _resv fields that are no longer needed since the reservation object is now stored on drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb() both referenced the wrong reservation object, and would lead to an attempt to dereference a NULL pointer. Correct those two cases to point to the correct reservation object.
Signed-off-by: Brian Masney masneyb@onstation.org Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object reservation_object")
Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org Tested-by: Bjorn Andersson bjorn.andersson@linaro.org
This resolves a NULL-pointer dereference about to show up in v5.2-rc1, so please pick this up for -rc.
Regards, Bjorn
Patch introduced in v2
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 +--- drivers/gpu/drm/msm/msm_atomic.c | 4 +--- drivers/gpu/drm/msm/msm_gem.c | 3 --- drivers/gpu/drm/msm/msm_gem.h | 4 ---- 4 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index da1f727d7495..ce1a555e1f31 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -780,7 +780,6 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane, struct dpu_plane_state *pstate = to_dpu_plane_state(new_state); struct dpu_hw_fmt_layout layout; struct drm_gem_object *obj;
- struct msm_gem_object *msm_obj; struct dma_fence *fence; struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base); int ret;
@@ -799,8 +798,7 @@ static int dpu_plane_prepare_fb(struct drm_plane *plane, * implicit fence and fb prepare by hand here. */ obj = msm_framebuffer_bo(new_state->fb, 0);
- msm_obj = to_msm_bo(obj);
- fence = reservation_object_get_excl_rcu(msm_obj->resv);
- fence = reservation_object_get_excl_rcu(obj->resv); if (fence) drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index f5b1256e32b6..131c23a267ee 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -49,15 +49,13 @@ int msm_atomic_prepare_fb(struct drm_plane *plane, struct msm_drm_private *priv = plane->dev->dev_private; struct msm_kms *kms = priv->kms; struct drm_gem_object *obj;
struct msm_gem_object *msm_obj; struct dma_fence *fence;
if (!new_state->fb) 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);
fence = reservation_object_get_excl_rcu(obj->resv);
drm_atomic_set_fence_for_plane(new_state, fence);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 31d5a744d84f..947508e8269d 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev, msm_obj->flags = flags; msm_obj->madv = MSM_MADV_WILLNEED;
- if (resv)
msm_obj->base.resv = resv;- INIT_LIST_HEAD(&msm_obj->submit_entry); INIT_LIST_HEAD(&msm_obj->vmas);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h index c5ac781dffee..812d1b1369a5 100644 --- a/drivers/gpu/drm/msm/msm_gem.h +++ b/drivers/gpu/drm/msm/msm_gem.h @@ -86,10 +86,6 @@ struct msm_gem_object {
struct llist_node freed;
- /* normally (resv == &_resv) except for imported bo's */
- struct reservation_object *resv;
- struct reservation_object _resv;
- /* For physically contiguous buffers. Used when we don't have
*/
- an IOMMU. Also used for stolen/splashscreen buffer.
-- 2.20.1
On Mon, May 13, 2019 at 01:32:39PM -0700, Bjorn Andersson wrote:
On Wed 08 May 19:03 PDT 2019, Brian Masney wrote:
The msm_gem_object structure contains resv and _resv fields that are no longer needed since the reservation object is now stored on drm_gem_object. msm_atomic_prepare_fb() and msm_atomic_prepare_fb() both referenced the wrong reservation object, and would lead to an attempt to dereference a NULL pointer. Correct those two cases to point to the correct reservation object.
Signed-off-by: Brian Masney masneyb@onstation.org Fixes: dd55cf6929e6 ("drm: msm: Switch to use drm_gem_object reservation_object")
Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org Tested-by: Bjorn Andersson bjorn.andersson@linaro.org
This resolves a NULL-pointer dereference about to show up in v5.2-rc1, so please pick this up for -rc.
Let me send out another version of just this patch. This snippet below that I removed needs to stay. I got a little too over eager removing code.
@@ -973,9 +973,6 @@ static int msm_gem_new_impl(struct drm_device *dev, msm_obj->flags = flags; msm_obj->madv = MSM_MADV_WILLNEED;
- if (resv)
msm_obj->base.resv = resv;- INIT_LIST_HEAD(&msm_obj->submit_entry); INIT_LIST_HEAD(&msm_obj->vmas);
Brian
Use drm_atomic_helper_dirtyfb() as the dirty callback in the msm_framebuffer_funcs struct. Call drm_plane_enable_fb_damage_clips() when the planes are initialized in mdp4, mdp5, and dpu1.
Signed-off-by: Brian Masney masneyb@onstation.org --- Changes since v1: - Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5, and dpu1.
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +++ drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 +++ drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +++ drivers/gpu/drm/msm/msm_fb.c | 2 ++ 4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index ce1a555e1f31..f3d009a3dc63 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -21,6 +21,7 @@ #include <linux/debugfs.h> #include <linux/dma-buf.h>
+#include <drm/drm_damage_helper.h> #include <drm/drm_atomic_uapi.h>
#include "msm_drv.h" @@ -1540,6 +1541,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev, if (ret) DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+ drm_plane_enable_fb_damage_clips(plane); + /* success! finalize initialization */ drm_plane_helper_add(plane, &dpu_plane_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c index 005066f7154d..2d46d1126283 100644 --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c @@ -15,6 +15,7 @@ * this program. If not, see http://www.gnu.org/licenses/. */
+#include <drm/drm_damage_helper.h> #include "mdp4_kms.h"
#define DOWN_SCALE_MAX 8 @@ -391,6 +392,8 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,
mdp4_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane); + return plane;
fail: diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c index be13140967b4..fcb6d32c2b38 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c @@ -16,6 +16,7 @@ * this program. If not, see http://www.gnu.org/licenses/. */
+#include <drm/drm_damage_helper.h> #include <drm/drm_print.h> #include "mdp5_kms.h"
@@ -1099,6 +1100,8 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane_install_properties(plane, &plane->base);
+ drm_plane_enable_fb_damage_clips(plane); + return plane;
fail: 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
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 --- Changes since v1: - None
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
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 Reviewed-by: Linus Walleij linus.walleij@linaro.org --- Changes since v1: - None
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 {
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 should be merged soon: https://lore.kernel.org/lkml/20190424092505.6578-1-masneyb@onstation.org/ The device tree bindings have been reviewed. The driver changes have received 3 {Reviewed,Acked}-bys.
Changes since v1: - None
.../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";
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 --- Changes since v1: - None
.../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 {
On Wed, May 08, 2019 at 10:03:46PM -0400, Brian Masney wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I attached the full dmesg output with this patch series applied. I enabled debugging messages for just the DRM subsystem.
Brian
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Yours, Linus Walleij
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
Brian
On Tue, May 28, 2019 at 7:17 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
Do you know if the nexus 5 has a video or command mode panel? There is some glitchyness with vblanks and command mode panels.
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
On Tue, May 28, 2019 at 7:17 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
Do you know if the nexus 5 has a video or command mode panel? There is some glitchyness with vblanks and command mode panels.
Its in command mode. I know this because I see two 'pp done time out' messages, even on 4.17. Based on my understanding, the ping pong code is only applicable for command mode panels.
Brian
On Tue, May 28, 2019 at 7:37 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
On Tue, May 28, 2019 at 7:17 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
Do you know if the nexus 5 has a video or command mode panel? There is some glitchyness with vblanks and command mode panels.
Its in command mode. I know this because I see two 'pp done time out' messages, even on 4.17. Based on my understanding, the ping pong code is only applicable for command mode panels.
Actually, the ping pong element exists in both modes, but 'pp done time out' is a good indicator that it is command mode.
Are you also seeing vblank timeouts?
Do you have busybox?
Can you run - sudo busybox devmem 0xFD900614 sudo busybox devmem 0xFD900714 sudo busybox devmem 0xFD900814 sudo busybox devmem 0xFD900914 sudo busybox devmem 0xFD900A14
On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote:
Do you know if the nexus 5 has a video or command mode panel? There is some glitchyness with vblanks and command mode panels.
Its in command mode. I know this because I see two 'pp done time out' messages, even on 4.17. Based on my understanding, the ping pong code is only applicable for command mode panels.
Actually, the ping pong element exists in both modes, but 'pp done time out' is a good indicator that it is command mode.
Are you also seeing vblank timeouts?
Yes, here's a snippet of the first one.
[ 2.556014] WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290 [ 2.556020] [CRTC:49:crtc-0] vblank wait timed out [ 2.556023] Modules linked in: [ 2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426 [ 2.556038] Hardware name: Generic DT based system [ 2.556056] Workqueue: events deferred_probe_work_func ...
Do you have busybox?
Can you run - sudo busybox devmem 0xFD900614 sudo busybox devmem 0xFD900714 sudo busybox devmem 0xFD900814 sudo busybox devmem 0xFD900914 sudo busybox devmem 0xFD900A14
# busybox devmem 0xFD900614 0x00020020 # busybox devmem 0xFD900714 0x00000000 # busybox devmem 0xFD900814 0x00000000 # busybox devmem 0xFD900914 0x00000000 # busybox devmem 0xFD900A14 0x00000000
I get the same values with the mainline kernel and 4.17.
Brian
On Tue, May 28, 2019 at 6:17 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
interconnect probably good to get going anyways (and I need to find some time to respin those mdp5/dpu patches) but I guess not related to what you see (ie. I'd expect interconnect issue would trigger underflow irq's)..
I'm not entirely sure why atomic would break things but cmd mode panels aren't especially well tested. I can't find it now but there was a thread (or IRC discussion?) that intf2vblank() should be returning MDP5_IRQ_PING_PONG_<n>_DONE instead of MDP5_IRQ_PING_PONG_<n>_RD_PTR, which seems likely and possibly related to vblank timing issues..
BR, -R
Brian
On Tue, May 28, 2019 at 8:15 PM Rob Clark robdclark@gmail.com wrote:
On Tue, May 28, 2019 at 6:17 PM Brian Masney masneyb@onstation.org wrote:
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
On Thu, May 9, 2019 at 4:04 AM Brian Masney masneyb@onstation.org wrote:
Here is a patch series that adds initial display support for the LG Nexus 5 (hammerhead) phone. It's not fully working so that's why some of these patches are RFC until we can get it fully working.
The phones 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:
I tested to apply patches 2-6 and got the console up on the phone as well. I see the same timouts, and I also notice the update is slow in the display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on 4.17 before the msm kms/drm driver was converted to the DRM atomic API so this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17 that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in mainline now and the last 5 are in essence this patch series with the exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'. There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of the outstanding interconnect patches for the msm kms/drm driver arrive in mainline. I'd really like to understand why the display works on 4.17 with those patches though. I assume that it's related to the vblank events not working properly? Let me preface this with I'm a total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't looking for these events in the atomic commits before the migration? See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic helper commit"), specifically the drm_atomic_helper_wait_for_vblanks() call that was added.
interconnect probably good to get going anyways (and I need to find some time to respin those mdp5/dpu patches) but I guess not related to what you see (ie. I'd expect interconnect issue would trigger underflow irq's)..
I'm not entirely sure why atomic would break things but cmd mode panels aren't especially well tested. I can't find it now but there was a thread (or IRC discussion?) that intf2vblank() should be returning MDP5_IRQ_PING_PONG_<n>_DONE instead of MDP5_IRQ_PING_PONG_<n>_RD_PTR, which seems likely and possibly related to vblank timing issues..
That was an irc discussion, and I've changed my mind on that.
My big issue ended up being that autorefresh was enabled (which basically turns the command panel into a pseudo video mode panel), which appears incompatible with using the start kick. If FW is configuring things in autorefresh mode, the driver likely doesn't know, and will make a mess of things by using the start kick.
Disabling autorefresh would make the driver work as is, but fbcon wouldn't work well (you'd need to do a start kick per frame, which doesn't seem to happen). Removing the start kick and using the autorefresh feature seemed better in my testing, but I haven't cleaned up my code tree to send something up.
However, lets see how the hardware is actually configured in Brian's case.
On Wed, May 29, 2019 at 3:17 AM Brian Masney masneyb@onstation.org wrote:
It's in low speed mode but its usable.
How low speed is that?
I assume that it's related to the vblank events not working properly?
They are only waiting for 50 ms before timing out, I raised it to 100ms in the -next kernel. I'm still suspicious about this even though I think you said this was not the problem.
For a command mode panel in LP mode it will nevertheless be more than 100ms for sure, the update is visible to the naked eye.
Raise it to 10000 ms or something and see what happens. drivers/gpu/drm/drm_atomic_helper.c: msecs_to_jiffies(50)
Yours, Linus Walleij
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote:
On Wed, May 29, 2019 at 3:17 AM Brian Masney masneyb@onstation.org wrote:
It's in low speed mode but its usable.
How low speed is that?
I don't have a number but my test with 4.17 is to run 'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls will fill up the screen and the file contents appear to show up on the screen immediately to the human eye. The next time that I run it requires scrolling the entire console and there is a small fraction of a second where I see the entire framebuffer contents scroll up. I don't have a graphics background, but I believe that this is the tearing effect that I'm seeing based on what I've read. I believe that disp-te-gpios can be used to mitigate this tearing effect. I have a few questions about this later once we get the basic display working.
I assume that it's related to the vblank events not working properly?
They are only waiting for 50 ms before timing out, I raised it to 100ms in the -next kernel. I'm still suspicious about this even though I think you said this was not the problem.
For a command mode panel in LP mode it will nevertheless be more than 100ms for sure, the update is visible to the naked eye.
Raise it to 10000 ms or something and see what happens. drivers/gpu/drm/drm_atomic_helper.c: msecs_to_jiffies(50)
I previously raised those timeouts as high as 5 seconds and it still has the same issue. Writing to /dev/tty1 can take anywhere between a few seconds to 30 seconds or more.
Brian
dri-devel@lists.freedesktop.org
-
Bjorn Andersson -
Brian Masney -
Jeffrey Hugo -
Linus Walleij -
Rob Clark