| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20241216-courageous-mysterious-pelican-5a8d2e@houat>
Date: Mon, 16 Dec 2024 18:20:04 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Phong LE <ple@...libre.com>,
Inki Dae <inki.dae@...sung.com>, Seung-Woo Kim <sw0312.kim@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>, Krzysztof Kozlowski <krzk@...nel.org>,
Alim Akhtar <alim.akhtar@...sung.com>, Russell King <linux@...linux.org.uk>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Sandy Huang <hjc@...k-chips.com>,
Heiko Stübner <heiko@...ech.de>, Andy Yan <andy.yan@...k-chips.com>,
Alain Volmat <alain.volmat@...s.st.com>, Raphael Gallais-Pou <rgallaispou@...il.com>,
Dave Stevenson <dave.stevenson@...pberrypi.com>, Maíra Canal <mcanal@...lia.com>,
Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>, Jani Nikula <jani.nikula@...ux.intel.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v6 06/10] drm/display/hdmi: implement hotplug functions
On Fri, Dec 06, 2024 at 12:16:00PM +0200, Dmitry Baryshkov wrote:
> The HDMI Connectors need to perform a variety of tasks when the HDMI
> connector state changes. Such tasks include setting or invalidating CEC
> address, notifying HDMI codec driver, updating scrambler data, etc.
>
> Implementing such tasks in a driver-specific callbacks is error prone.
> Start implementing the generic helper function (currently handling only
> the HDMI Codec framework) to be used by drivers utilizing HDMI Connector
> framework.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 61 +++++++++++++++++++++++++
> include/drm/display/drm_hdmi_state_helper.h | 8 ++++
> 2 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index 80bf2829ba89b5f84fed4fa9eb1d6302e10a4f9e..4cdeb63688b9e48acd8e8ae87a45b6253f7dd12b 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -769,3 +769,64 @@ drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector *con
> return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_clear_audio_infoframe);
> +
> +/**
> + * drm_atomic_helper_connector_hdmi_hotplug_edid - Handle the hotplug event for the HDMI connector passing custom EDID
> + * @connector: A pointer to the HDMI connector
> + * @status: Connection status
> + * @drm_edid: EDID to process
> + *
> + * This function should be called as a part of the .detect() / .detect_ctx()
> + * and .force() callbacks, updating the HDMI-specific connector's data. Most
> + * drivers should be able to use @drm_atomic_helper_connector_hdmi_hotplug()
> + * instead.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int
> +drm_atomic_helper_connector_hdmi_hotplug_edid(struct drm_connector *connector,
> + enum drm_connector_status status,
> + const struct drm_edid *drm_edid)
> +{
> + if (status == connector_status_disconnected) {
> + // TODO: also handle CEC and scramber, HDMI sink disconnected.
> + drm_connector_hdmi_codec_plugged_notify(connector, false);
> + }
> +
> + drm_edid_connector_update(connector, drm_edid);
> +
> + if (status == connector_status_connected) {
> + // TODO: also handle CEC and scramber, HDMI sink is now connected.
> + drm_connector_hdmi_codec_plugged_notify(connector, true);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_hotplug_edid);
I think we discussed it in a previous version's thread after you sent
that one, but I'd rather have that helper call an edid retrieval
function than passing it edids.
Also, EDIDs are mandatory for HDMI, so I'd call the function
drm_atomic_helper_connector_hdmi_hotplug.
> +/**
> + * drm_atomic_helper_connector_hdmi_hotplug - Handle the hotplug event for the HDMI connector
> + * @connector: A pointer to the HDMI connector
> + * @status: Connection status
> + *
> + * This function should be called as a part of the .detect() / .detect_ctx()
> + * and .force() callbacks, updating the HDMI-specific connector's data.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int
> +drm_atomic_helper_connector_hdmi_hotplug(struct drm_connector *connector,
> + enum drm_connector_status status)
> +{
> + const struct drm_edid *drm_edid;
> + int ret;
> +
> + drm_edid = drm_edid_read(connector);
> + ret = drm_atomic_helper_connector_hdmi_hotplug_edid(connector, status, drm_edid);
> + drm_edid_free(drm_edid);
Oh. Why do we need the two variants? Or is it to deal with drivers that
don't set connector->ddc?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists