kernel/linux.git/drivers/gpu/drm/panel, branch v5.13.1

drm/panel: ld9040: reference spi_device_id table

2021-06-19T20:30:23+00:00

Reference the spi_device_id table to silence W=1 warning: drivers/gpu/drm/panel/panel-samsung-ld9040.c:377:35: warning: ‘ld9040_ids’ defined but not used [-Wunused-const-variable=] This also would be needed for matching the driver if booted without CONFIG_OF (although it's not necessarily real case). Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210526123002.12913-1-krzysztof.kozlowski@canonical.com

Merge drm/drm-fixes into drm-next

2021-04-13T21:15:09+00:00

msm-next pull request has a baseline with stuff from -fixes, roll forward first. Some simple conflicts in amdgpu, ttm and one in i915 where git gets confused and tries to add the same function twice. Signed-off-by: Daniel Vetter

drm/panel: Convert sysfs sprintf/snprintf family to sysfs_emit

2021-04-09T00:41:38+00:00

Fix the following coccicheck warning: drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Tian Tao Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com

drm/panel: panel-dsi-cm: disable TE for now

2021-04-06T13:51:29+00:00

Disable TE for Droid 4 panel, since implementation is currently broken. Also disable it for N950 panel, which is untested. Reported-by: Tony Lindgren Reported-by: Tomi Valkeinen Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Sebastian Reichel Tested-by: Tony Lindgren Acked-by: Thierry Reding Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20210227214542.99961-1-sebastian.reichel@collabora.com

Merge drm/drm-next into drm-misc-next

2021-03-16T08:06:23+00:00

Noralf needs some patches in 5.12-rc3, and we've been delaying the 5.12 merge due to the swap issue so it looks like a good time. Signed-off-by: Maxime Ripard

Merge tag 'drm-misc-next-2021-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2021-03-16T07:08:46+00:00

drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - %p4cc printk format modifier - atomic: introduce drm_crtc_commit_wait, rework atomic plane state helpers to take the drm_commit_state structure - dma-buf: heaps rework to return a struct dma_buf - simple-kms: Add plate state helpers - ttm: debugfs support, removal of sysfs Driver Changes: - Convert drivers to shadow plane helpers - arc: Move to drm/tiny - ast: cursor plane reworks - gma500: Remove TTM and medfield support - mxsfb: imx8mm support - panfrost: MMU IRQ handling rework - qxl: rework to better handle resources deallocation, locking - sun4i: Add alpha properties for UI and VI layers - vc4: RPi4 CEC support - vmwgfx: doc cleanup Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210303100600.dgnkadonzuvfnu22@gilmour

drm: panel: simple: Set enable delay for BOE NV110WTM-N61

2021-03-11T16:19:52+00:00

Panel power sequence says timing T8 (time from link idle to turn on the backlight) should be at least 50 ms. This is what the .enable delay in simple-panel is for, so set it. NOTE: this overlaps with the 80 ms .prepare_to_enable delay on purpose. The data sheet says that at least 80 ms needs to pass between HPD going high and turning on the backlight and that at least 50 ms needs to pass between the link idle and the backlight going on. Thus it works like this on the system in front of me: * In bridge chip pre_enable call drm_panel_prepare() * drm_panel_prepare() -> panel_simple_prepare() * Wait for HPD GPIO to go high. * Start counting for 80 ms (store in prepared_time) * In bridge chip enable, train link then call drm_panel_enable() * drm_panel_enable() -> panel_simple_enable() * panel_simple_enable() does hardcoded 50 ms delay then enforces 80 ms from HPD going high (in case the bridge took less than 30 ms to enable / link train). * drm_panel_enable() -> backlight_enable(). Signed-off-by: Douglas Anderson Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid

drm/panel-simple: Add N116BCA-EA1

2021-03-11T16:14:43+00:00

This panel is quite similar to the similarly named N116BGE panel (the nominal timings are, in fact identical). However, let's add a new entry because the full range of clocks listed for N116BGE aren't supported for N116BCA-EA1, at least according to the datasheet. Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.5.I3c01f3aab8335cb509da7009d8938c1a27a266dc@changeid

drm/panel-simple: Retry if we timeout waiting for HPD

2021-03-11T16:14:41+00:00

On an Innolux N116BCA panel that I have in front of me, sometimes HPD simply doesn't assert no matter how long you wait for it. As per the very wise advice of The IT Crowd ("Have you tried turning it off and on again?") it appears that power cycling is enough to kick this panel back into a sane state. >From tests on this panel, it appears that leaving it powered off for a while stimulates the problem. Adding a 6 second sleep at the start of panel_simple_prepare_once() makes it happen fairly reliably and, with this delay, I saw up to 3 retries needed sometimes. Without the 6 second sleep, however, the panel came up much more reliably the first time or after only 1 retry. While it's unknown what the problems are with this panel (and probably the hardware should be debugged), adding a few retries to the power on routine doesn't seem insane. Even if this panel's problems are attributed to the fact that it's pre-production and/or can be fixed, retries clearly can help in some cases and really don't hurt. Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.3.I6916959daa7c5c915e889442268d23338de17923@changeid

drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay

2021-03-11T16:14:40+00:00

If a panel has an hpd_absent_delay specified then we know exactly how long the maximum time is before HPD must be asserted. That means we can use it as a timeout for polling the HPD pin instead of using an arbitrary timeout. This is especially useful for dealing with panels that periodically fail to power on and need to be retried. We can detect the problem sooner. Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Reviewed-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210115144345.v2.2.I183b1817610d7a82fdd3bc852e96d2985df9623f@changeid