The ELD (EDID-Like Data) is not updated when the HDMI cable
is plugged into different HDMI monitors.
This is because the EDID is not updated in the HDMI HPD function.
As a result, the ELD data remains unchanged and may not reflect
the capabilities of the newly connected HDMI sink device.
To address this issue, the handle_plugged_change function should move to
the bridge_atomic_enable and bridge_atomic_disable functions.
Make sure the EDID is properly updated before updating ELD.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230804061145.2824843-1-Sandor.yu@nxp.com
On system resume, the driver might call it6505_poweron directly if the
runtime PM hasn't been enabled. In such case, pm_runtime_get_if_in_use
will always return 0 because dev->power.runtime_status stays at
RPM_SUSPENDED, and the IRQ will never be handled.
Use it6505->powered from the driver struct fixes this because it always
gets updated when it6505_poweron is called.
Fixes: 5eb9a43140 ("drm/bridge: it6505: Guard bridge power in IRQ handler")
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727100131.2338127-1-treapking@chromium.org
When building with W=1, the following warning occurs.
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c:48:17: warning: ‘anx781x_i2c_addresses’ defined but not used [-Wunused-const-variable=] static const u8 anx781x_i2c_addresses[] = {
^~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c:40:17: warning: ‘anx7808_i2c_addresses’ defined but not used [-Wunused-const-variable=] static const u8 anx7808_i2c_addresses[] = {
When CONFIG_IO is disabled, above two variables are not used,
since the place where it is used is inclueded in the macro
CONFIG_OF.
Even for drivers that do not depend on CONFIG_OF, it's almost
always better to leave out the of_match_ptr(), since the only
thing it can possibly do is to save a few bytes of .text if a
driver can be used both with and without it. Hence we remove
all of_match_ptr() used in other places.
Fixes: 0647e7dd3f ("drm/bridge: Add Analogix anx78xx support")
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230731021345.219588-1-wangzhu9@huawei.com
The device lock is used to serialize the low level power sequencing
operations. Since drm_helper_hpd_irq_event() could end up calling
.atomic_enable, which also calls power sequencing functions through
runtime PM, this results in a real deadlock. This was observed on an
MT8192-based Chromebook's external display (with appropriate patches [1]
and DT changes applied).
Move the drm_helper_hpd_irq_event() call outside of the lock range. The
lock only needs to be held so that the device status can be read back.
This is the bare minimum change to avoid the deadlock. The lock could
be dropped completely and have pm_runtime_get_if_in_use() increase the
reference count, but this is not the same as pm_runtime_suspended().
Dropping the lock completely also causes the internal display of the
same device to not function correctly if the internal bridge's
interrupt line is added in the device tree. Both the internal and
external display of said device each use one anx7625 bridge.
[1] https://lore.kernel.org/dri-devel/20230112042104.4107253-1-treapking@chromium.org/
Fixes: 60487584a7 ("drm/bridge: anx7625: refactor power control to use runtime PM framework")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230710085922.1871465-1-wenst@chromium.org
The documentation is not clear about how this delay works.
Empirical tests have shown that with a VSDELAY of 0, the first
scanline is not properly formatted in the output stream when
DSI->DP mode is used. The calculation spreadsheets from Toshiba
seem to always make this value equal to the HFP + 10 for DSI->DP
use-case. For DSI->DPI this value should be > 2 and for DPI->DP
it seems to always be 0x64.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Marek Vasut <marex@denx.de> # TC9595
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230721165328.3968759-2-l.stach@pengutronix.de
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Steven Price <steven.price@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Acked-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714174545.4056287-1-robh@kernel.org
drm-misc-next for v6.6:
UAPI Changes:
* fbdev:
* Make fbdev userspace interfaces optional; only leaves the
framebuffer console active
* prime:
* Support dma-buf self-import for all drivers automatically: improves
support for many userspace compositors
Cross-subsystem Changes:
* backlight:
* Fix interaction with fbdev in several drivers
* base: Convert struct platform.remove to return void; part of a larger,
tree-wide effort
* dma-buf: Acquire reservation lock for mmap() in exporters; part
of an on-going effort to simplify locking around dma-bufs
* fbdev:
* Use Linux device instead of fbdev device in many places
* Use deferred-I/O helper macros in various drivers
* i2c: Convert struct i2c from .probe_new to .probe; part of a larger,
tree-wide effort
* video:
* Avoid including <linux/screen_info.h>
Core Changes:
* atomic:
* Improve logging
* prime:
* Remove struct drm_driver.gem_prime_mmap plus driver updates: all
drivers now implement this callback with drm_gem_prime_mmap()
* gem:
* Support execution contexts: provides locking over multiple GEM
objects
* ttm:
* Support init_on_free
* Swapout fixes
Driver Changes:
* accel:
* ivpu: MMU updates; Support debugfs
* ast:
* Improve device-model detection
* Cleanups
* bridge:
* dw-hdmi: Improve support for YUV420 bus format
* dw-mipi-dsi: Fix enable/disable of DSI controller
* lt9611uxc: Use MODULE_FIRMWARE()
* ps8640: Remove broken EDID code
* samsung-dsim: Fix command transfer
* tc358764: Handle HS/VS polarity; Use BIT() macro; Various cleanups
* Cleanups
* ingenic:
* Kconfig REGMAP fixes
* loongson:
* Support display controller
* mgag200:
* Minor fixes
* mxsfb:
* Support disabling overlay planes
* nouveau:
* Improve VRAM detection
* Various fixes and cleanups
* panel:
* panel-edp: Support AUO B116XAB01.4
* Support Visionox R66451 plus DT bindings
* Cleanups
* ssd130x:
* Support per-controller default resolution plus DT bindings
* Reduce memory-allocation overhead
* Cleanups
* tidss:
* Support TI AM625 plus DT bindings
* Implement new connector model plus driver updates
* vkms
* Improve write-back support
* Documentation fixes
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230713090830.GA23281@linux-uq9g
When removing the tidss driver, there is a warning reported by
kernel about an unhandled interrupt for mhdp driver.
[ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
... [snipped backtrace]
[ 43.330735] handlers:
[ 43.333020] [<000000005367c4f9>] irq_default_primary_handler threaded [<000000007e02b601>]
cdns_mhdp_irq_handler [cdns_mhdp8546]
[ 43.344607] Disabling IRQ #31
This happens because as part of cdns_mhdp_bridge_hpd_disable, driver tries
to disable the interrupts. While disabling the SW_EVENT interrupts,
it accidentally enables the MBOX interrupts, which are not handled by
the driver.
Fix this with a read-modify-write to update only required bits.
Use the enable / disable function as required in other places.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Reviewed-by: Swapnil Jakhade <sjakhade@cadence.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-9-a-bhatia1@ti.com
With new connector model, sii902x will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and SoC driver will rely on format
negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is
the case with older model.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-6-a-bhatia1@ti.com
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support minimal format negotiations hooks in the drm_bridge_funcs.
Complete format negotiation can be added based on EDID data.
This patch adds the minimal required support to avoid failure
after moving to new connector model.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
[a-bhatia1: Drop the output_fmt check condition]
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-4-a-bhatia1@ti.com
Wait until the command transfer FIFO is empty before loading in the next
command. The previous behavior where the code waited until command transfer
FIFO was not full suffered from transfer corruption, where the last command
in the FIFO could be overwritten in case the FIFO indicates not full, but
also does not have enough space to store another transfer yet.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # imx8mm-icore
Link: https://patchwork.freedesktop.org/patch/msgid/20230615201511.565923-1-marex@denx.de
Memory for the "struct device" for any given device isn't supposed to
be released until the device's release() is called. This is important
because someone might be holding a kobject reference to the "struct
device" and might try to access one of its members even after any
other cleanup/uninitialization has happened.
Code analysis of ti-sn65dsi86 shows that this isn't quite right. When
the code was written, it was believed that we could rely on the fact
that the child devices would all be freed before the parent devices
and thus we didn't need to worry about a release() function. While I
still believe that the parent's "struct device" is guaranteed to
outlive the child's "struct device" (because the child holds a kobject
reference to the parent), the parent's "devm" allocated memory is a
different story. That appears to be freed much earlier.
Let's make this better for ti-sn65dsi86 by allocating each auxiliary
with kzalloc and then free that memory in the release().
Fixes: bf73537f41 ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers")
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230613065812.v2.1.I24b838a5b4151fb32bccd6f36397998ea2df9fbb@changeid
In order to read the EDID from an eDP panel, you not only need to
power on the bridge chip itself but also the panel. In the ps8640
driver, this was made to work by having the bridge chip manually power
the panel on by calling pre_enable() on everything connectorward on
the bridge chain. This worked OK, but...
...when trying to do the same thing on ti-sn65dsi86, feedback was that
this wasn't a great idea. As a result, we designed the "DP AUX"
bus. With the design we ended up with the panel driver itself was in
charge of reading the EDID. The panel driver could power itself on and
the bridge chip was able to power itself on because it implemented the
DP AUX bus.
Despite the fact that we came up with a new scheme, implemented in on
ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept
the old code around. This was because the new scheme required a DT
change. Previously the panel was a simple "platform_device" and in DT
at the top level. With the new design the panel needs to be listed in
DT under the DP controller node. The old code allowed us to properly
fetch EDIDs with ps8640 with the old DTs.
Unfortunately, the old code stopped working as of commit 102e80d1fa
("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There
are cases at bootup where connector->state->state is NULL and the
kernel crashed at:
* drm_atomic_bridge_chain_pre_enable
* drm_atomic_get_old_bridge_state
* drm_atomic_get_old_private_obj_state
The crash went away at commit 4fb912e5e1 ("drm/bridge: Introduce
pre_enable_prev_first to alter bridge init order") which added a NULL
check. However, even though we were no longer crashing the end result
was that we weren't actually powering the panel on when we thought we
were. Things could end up working (despite warning splats) if
userspace was persistent and tried to get the mode again, but it
wasn't great.
A bit of digging was done to see if there was an easy fix but there
was nothing obvious. Instead, the only device using ps8640 the "old"
way had its DT updated so that the panel was no longer a simple
"platform_deice". See commit c2d94f7214 ("arm64: dts: mediatek:
mt8173-elm: Move display to ps8640 auxiliary bus") and commit
113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model
number in DT").
Let's delete the old broken code so nobody gets tempted to copy it or
figure out how it works (since it doesn't).
NOTE: from a device tree "purist" point of view, we're supposed to
keep old device trees working and this patch is technically "against
policy". Reasons I'm still proposing it anyway:
1. Officially, old mt8173-elm device trees worked via the "little
white lie" approach. The DT would list an arbitrary/representative
panel that would be used for power sequencing. The mode information
in the panel driver would then be ignored / overridden by the EDID
reading code in ps8640. I don't feel too terrible breaking DTs that
contained the wrong "compatible" string to begin with. NOTE that
any old device trees that _didn't_ lie about their compatible will
still work because the mode information will come from the
hardcoded panels in panel-edp.
2. The only users of the old code were Chromebooks and Chromebooks
don't bake their DTs into the BIOS (they are bundled with the
kernel). Thus we don't need to worry about breaking someone using
an old DT with a new kernel.
3. The old code was broken anyway. If someone wants to fix the old
code instead of deleting it then they have my blessing, but without
a proper fix the old code isn't useful.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616165517.v2.1.I7b8f60b3fbfda068f9bf452d584dc934494bfbfa@changeid
Commit 5d844091f2 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc
interface to pick up an i2c adapter from a connector instead. However, in
the case of dw-hdmi, the wrong connector was being used to pass i2c adapter
information, since dw-hdmi's embedded connector structure is only populated
when the bridge attachment callback explicitly asks for it.
drm-meson is handling connector creation, so this won't happen, leading to
a NULL pointer dereference.
Fix it by having scdc functions access dw-hdmi's current connector pointer
instead, which is assigned during the bridge enablement stage.
Fixes: 5d844091f2 ("drm/scdc-helper: Pimp SCDC debugs")
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reported-by: Lukas F. Hartmann <lukas@mntre.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
[narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230601123153.196867-1-adrian.larumbe@collabora.com
Before this patch, booting to Linux VT and doing a simple:
echo 2 > /sys/class/graphics/fb0/blank
echo 0 > /sys/class/graphics/fb0/blank
would result in failures to re-enable the panel. Mode set callback is
called only once during boot in this scenario, while calls to
enable/disable callbacks are balanced afterwards. The driver doesn't
work unless userspace calls modeset before enabling the CRTC/connector.
This patch moves enabling of the DSI host from mode_set into pre_enable
callback, and removes some old hacks where this bridge driver is
directly calling into other bridge driver's callbacks.
pre_enable_prev_first flag is set on the panel's bridge so that panel
drivers will get their prepare function called between DSI host's
pre_enable and enable callbacks, so that they get a chance to
perform panel setup while DSI host is already enabled in command
mode. Otherwise panel's prepare would be called before DSI host
is enabled, and any DSI communication used in prepare callback
would fail.
With all these changes, the enable/disable sequence is now well
balanced, and host's and panel's callbacks are called in proper order
documented in the drm_panel API documentation without needing the old
hacks. (Mainly that panel->prepare is called when DSI host is ready to
allow the panel driver to send DSI commands and vice versa during
disable.)
Tested on Pinephone Pro. Trace of the callbacks follows.
Before:
[ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable
echo 2 > /sys/class/graphics/fb0/blank
[ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable
[ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare
echo 0 > /sys/class/graphics/fb0/blank
[ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable
[ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
echo 2 > /sys/class/graphics/fb0/blank
[ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable
[ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110
[ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare
[ 431.169357] pclk_mipi_dsi0 already disabled
echo 0 > /sys/class/graphics/fb0/blank
[ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable
[ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO
[ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110
[ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110
-----------------------------------------------------------------------
After:
[ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set
[ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable
echo 2 > /sys/class/graphics/fb0/blank
[ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable
[ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable
[ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare
echo 0 > /sys/class/graphics/fb0/blank
[ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable
[ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare
[ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable
[ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable
(But depends on functionality intorduced in Linux 6.3, so this patch will
not build on older kernels when applied to older stable branches.)
Fixes: 46fc51546d ("drm/bridge/synopsys: Add MIPI DSI host controller bridge")
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230617224915.1923630-1-megi@xff.cz
Move the register programming part, which actually enables the bridge and
makes it push data out of its DPI side, into the enable callback. The DSI
host like DSIM may not be able to transmit commands in pre_enable, moving
the register programming into enable assures it can transmit commands.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230615201902.566182-1-marex@denx.de
Backmerging into drm-misc-next to get commit 2c1c7ba457
("drm/amdgpu: support partition drm devices"), which is required to fix
commit 0adec22702 ("drm: Remove struct drm_driver.gem_prime_mmap").
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
