From: neil.armstrong@linaro.org
To: Jonas Karlman <jonas@kwiboo.se>, Maxime Ripard <mripard@kernel.org>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>,
Robert Foss <rfoss@kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Christian Hewitt <christianshewitt@gmail.com>,
Diederik de Haas <didi.debian@cknow.org>,
dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 09/10] drm: bridge: dw_hdmi: Update EDID during hotplug processing
Date: Fri, 20 Sep 2024 09:04:19 +0200 [thread overview]
Message-ID: <e865e42c-a528-45bb-bdf5-df1cd103e695@linaro.org> (raw)
In-Reply-To: <0dcb03be-dae1-4dcb-84d8-6ec204eab6ba@kwiboo.se>
On 19/09/2024 22:34, Jonas Karlman wrote:
> Hi Neil,
>
> On 2024-09-13 10:02, Neil Armstrong wrote:
>> On 08/09/2024 15:28, Jonas Karlman wrote:
>>> Update successfully read EDID during hotplug processing to ensure the
>>> connector diplay_info is always up-to-date.
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> v2: No change
>>> ---
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index c19307120909..7bd9f895f03f 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -2457,6 +2457,18 @@ dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
>>>
>>> status = dw_hdmi_detect(hdmi);
>>>
>>> + /* Update EDID during hotplug processing (force=false) */
>>> + if (status == connector_status_connected && !force) {
>>> + const struct drm_edid *drm_edid;
>>> +
>>> + drm_edid = dw_hdmi_edid_read(hdmi, connector);
>>> + if (drm_edid)
>>> + drm_edid_connector_update(connector, drm_edid);
>>> + cec_notifier_set_phys_addr(hdmi->cec_notifier,
>>> + connector->display_info.source_physical_address);
>>> + drm_edid_free(drm_edid);
>>> + }
>>> +
>>> if (status == connector_status_disconnected)
>>> cec_notifier_phys_addr_invalidate(hdmi->cec_notifier);
>>>
>>
>> I wonder why we should read edid at each dw_hdmi_connector_detect() call,
>> AFAIK it should only be when we have HPD pulses
>
> That is what this change intends to help do.
>
> As stated in the short comment EDID is only updated at HPD processing,
> i.e. when force=false. To be on the safe side EDID is also only updated
> here when connected and EDID could be read.
>
> drm_helper_probe_detect() is called with force=true in the
> fill_modes/get_modes call path that is triggered by userspace
> or the kernel kms client.
>
> After a HPD interrupt the call to drm_helper_hpd_irq_event() will call
> check_connector_changed() that in turn calls drm_helper_probe_detect()
> with force=false to check/detect if connector status has changed. It is
> in this call chain the EDID may be read and updated in this detect ops.
>
> Reading EDID here at HPD processing may not be fully needed, however it
> help kernel keep the internal EDID state in better sync with sink when
> userspace does not act on the HOTPLUG=1 uevent.
I understand but if somehow a dw-hdmi integration fails to have HDP working
properly, EDID will be read continuously which is really not what we want.
HDMI 1.4b specifies in Section 8.5 and Appendix A:
============><==========================================
An HDMI Sink shall not assert high voltage level on its Hot Plug Detect pin when the E-EDID
is not available for reading.
An HDMI Sink shall indicate any change to the contents of the E-EDID by driving a low
voltage level pulse on the Hot Plug Detect pin. This pulse shall be at least 100 msec.
============><==========================================
So this is OK with the first sentence, and should also work with the second one because
right after the pulse we will read the EDID again, but I think we should have a much
more robust way to detect those 100ms pulses, no ?
Maxime, do you have an opinion on this ?
Neil
>
> Regards,
> Jonas
>
>>
>> Neil
>
next prev parent reply other threads:[~2024-09-20 7:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-08 13:28 [PATCH v2 00/10] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup Jonas Karlman
2024-09-08 13:28 ` [PATCH v2 01/10] drm: bridge: dw_hdmi: Disable scrambler feature when not supported Jonas Karlman
2024-09-09 13:15 ` Neil Armstrong
2024-09-08 13:28 ` [PATCH v2 02/10] drm: bridge: dw_hdmi: Only notify connected status on HPD interrupt Jonas Karlman
2024-09-09 13:16 ` Neil Armstrong
2024-09-09 15:12 ` Jonas Karlman
2024-09-08 13:28 ` [PATCH v2 03/10] drm: bridge: dw_hdmi: Call poweron/poweroff from atomic enable/disable Jonas Karlman
2024-09-13 8:05 ` Neil Armstrong
2024-09-08 13:28 ` [PATCH v2 04/10] drm: bridge: dw_hdmi: Use passed mode instead of stored previous_mode Jonas Karlman
2024-09-13 8:04 ` Neil Armstrong
2024-09-08 13:28 ` [PATCH v2 05/10] drm: bridge: dw_hdmi: Fold poweron and setup functions Jonas Karlman
2024-09-13 8:06 ` Neil Armstrong
2024-09-08 13:28 ` [PATCH v2 06/10] drm: bridge: dw_hdmi: Remove previous_mode and mode_set Jonas Karlman
2024-09-13 8:03 ` Neil Armstrong
2024-09-08 13:28 ` [PATCH v2 07/10] drm: bridge: dw_hdmi: Invalidate CEC phys addr from connector detect Jonas Karlman
2024-09-08 13:28 ` [PATCH v2 08/10] drm: bridge: dw_hdmi: Remove cec_notifier_mutex Jonas Karlman
2024-09-08 13:28 ` [PATCH v2 09/10] drm: bridge: dw_hdmi: Update EDID during hotplug processing Jonas Karlman
2024-09-13 8:02 ` Neil Armstrong
2024-09-19 20:34 ` Jonas Karlman
2024-09-20 7:04 ` neil.armstrong [this message]
2024-09-20 11:51 ` Jonas Karlman
2024-09-08 13:28 ` [PATCH v2 10/10] drm: bridge: dw_hdmi: Use display_info is_hdmi and has_audio Jonas Karlman
2024-09-13 17:30 ` [PATCH v2 00/10] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup Diederik de Haas
2024-10-02 19:38 ` Diederik de Haas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e865e42c-a528-45bb-bdf5-df1cd103e695@linaro.org \
--to=neil.armstrong@linaro.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=christianshewitt@gmail.com \
--cc=didi.debian@cknow.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox