The recently introduced hotplug event handler in the HDMI Connector
framework attempts to unconditionally read the EDID data, leading to a
bunch of non-harmful, yet quite annoying DDC/I2C related errors being
reported.
Ensure the operation is done only for connectors having the status
connected or unknown. Additionally, perform an explicit reset of the
connector information when dealing with a disconnected status.
Fixes: ab716b74dc ("drm/display/hdmi: implement hotplug functions")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113-hdmi-conn-edid-read-fix-v2-1-d2a0438a44ab@collabora.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
It's ok to pass atomic check successfully if an atomic commit tries to
disable the display pipeline which the connector belongs to. That is,
when the crtc or the best_encoder pointers in struct drm_connector_state
are NULL, drm_atomic_helper_connector_hdmi_check() should return 0.
Without the check against the NULL pointers, drm_default_rgb_quant_range()
called by drm_atomic_helper_connector_hdmi_check() would dereference
the NULL pointer to_match in drm_match_cea_mode().
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
drm_default_rgb_quant_range+0x0/0x4c (P)
drm_bridge_connector_atomic_check+0x20/0x2c
drm_atomic_helper_check_modeset+0x488/0xc78
drm_atomic_helper_check+0x20/0xa4
drm_atomic_check_only+0x4b8/0x984
drm_atomic_commit+0x48/0xc4
drm_framebuffer_remove+0x44c/0x530
drm_mode_rmfb_work_fn+0x7c/0xa0
process_one_work+0x150/0x294
worker_thread+0x2dc/0x3dc
kthread+0x130/0x204
ret_from_fork+0x10/0x20
Fixes: 8ec116ff21 ("drm/display: bridge_connector: provide atomic_check for HDMI bridges")
Fixes: 84e541b1e5 ("drm/sun4i: use drm_atomic_helper_connector_hdmi_check()")
Fixes: 65548c8ff0 ("drm/rockchip: inno_hdmi: Switch to HDMI connector")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110084821.3239518-2-victor.liu@nxp.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Our infoframe setting code currently lacks the ability to clear
infoframes. For some of the infoframes, we only need to replace them,
so if an error occurred when generating a new infoframe we would leave
a stale frame instead of clearing the frame.
However, the Dynamic Range and Mastering (DRM) infoframe should only
be present when displaying HDR content (ie: the HDR_OUTPUT_METADATA blob
is set). If we can't clear infoframes, the stale DRM infoframe will
remain and we can never set the display back to SDR mode.
With this change, we clear infoframes when they can not, or should not,
be generated. This fixes switching to an SDR mode from an HDR one.
Fixes: f378b77227 ("drm/connector: hdmi: Add Infoframes generation")
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241202181939.724011-1-derek.foreman@collabora.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The largest infoframe we create is the DRM (Dynamic Range Mastering)
infoframe which is 26 bytes + a 4 byte header, for a total of 30
bytes.
With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we
allocate too little space to pack a DRM infoframe in
write_device_infoframe(), leading to an ENOSPC return from
hdmi_infoframe_pack(), and never calling the connector's
write_infoframe() vfunc.
Instead of having HDMI_MAX_INFOFRAME_SIZE defined in two places,
replace HDMI_MAX_INFOFRAME_SIZE with HDMI_INFOFRAME_SIZE(MAX) and make
MAX 27 bytes - which is defined by the HDMI specification to be the
largest infoframe payload.
Fixes: f378b77227 ("drm/connector: hdmi: Add Infoframes generation")
Fixes: c602e4959a ("drm/connector: hdmi: Create Infoframe DebugFS entries")
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240827163918.48160-1-derek.foreman@collabora.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To make that easier to handle for drivers, let's provide an optional
hook to be implemented by drivers so they can tell the HDMI controller
helpers if a given TMDS character rate is reachable for them or not.
This will then be useful to figure out the best format and bpc count for
a given mode.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-13-c5af16c3aae2@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
