LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Maxime Ripard <maxime@cerno.tech>
Cc: dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@intel.com>,
David Airlie <airlied@linux.ie>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Emma Anholt <emma@anholt.net>,
linux-rpi-kernel@lists.infradead.org,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Phil Elwell <phil@raspberrypi.com>,
Tim Gover <tim.gover@raspberrypi.com>,
Dom Cobley <dom@raspberrypi.com>, Sam Ravnborg <sam@ravnborg.org>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
bcm-kernel-feedback-list@broadcom.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] drm/vc4: hdmi: Actually check for the connector status in hotplug
Date: Tue, 14 Sep 2021 16:34:08 +0200 [thread overview]
Message-ID: <YUCy4AmYDFD2jtG6@phenom.ffwll.local> (raw)
In-Reply-To: <20210914101724.266570-3-maxime@cerno.tech>
On Tue, Sep 14, 2021 at 12:17:24PM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() documentation states that this function
> is "useful for drivers which can't or don't track hotplug interrupts for
> each connector." and that "Drivers which support hotplug interrupts for
> each connector individually and which have a more fine-grained detect
> logic should bypass this code and directly call
> drm_kms_helper_hotplug_event()". This is thus what we ended-up doing.
>
> However, what this actually means, and is further explained in the
> drm_kms_helper_hotplug_event() documentation, is that
> drm_kms_helper_hotplug_event() should be called by drivers that can
> track the connection status change, and if it has changed we should call
> that function.
>
> This underlying expectation we failed to provide is that the caller of
> drm_kms_helper_hotplug_event() should call drm_helper_probe_detect() to
> probe the new status of the connector.
>
> Since we didn't do it, it meant that even though we were sending the
> notification to user-space and the DRM clients that something changed we
> never probed or updated our internal connector status ourselves.
>
> This went mostly unnoticed since the detect callback usually doesn't
> have any side-effect. Also, if we were using the DRM fbdev emulation
> (which is a DRM client), or any user-space application that can deal
> with hotplug events, chances are they would react to the hotplug event
> by probing the connector status eventually.
>
> However, now that we have to enable the scrambler in detect() if it was
> enabled it has a side effect, and an application such as Kodi or
> modetest doesn't deal with hotplug events. This resulted with a black
> screen when Kodi or modetest was running when a screen was disconnected
> and then reconnected, or switched off and on.
Uh, why are you running this scrambler restore in your probe function? I
guess it works, but most drivers that do expensive hotplug restore to
handle the "no black screen for replug" use-case handle that in their own
dedicated code.
But those also tend to have per-output hpd interrupt sources, so maybe
that's why?
-Daniel
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a3dbd1fdff7d..d9e001b9314f 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1578,10 +1578,11 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
> static irqreturn_t vc4_hdmi_hpd_irq_thread(int irq, void *priv)
> {
> struct vc4_hdmi *vc4_hdmi = priv;
> - struct drm_device *dev = vc4_hdmi->connector.dev;
> + struct drm_connector *connector = &vc4_hdmi->connector;
> + struct drm_device *dev = connector->dev;
>
> if (dev && dev->registered)
> - drm_kms_helper_hotplug_event(dev);
> + drm_connector_helper_hpd_irq_event(connector);
>
> return IRQ_HANDLED;
> }
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-09-14 14:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 10:17 [PATCH v2 1/3] drm/probe-helper: Document drm_helper_hpd_irq_event() return value Maxime Ripard
2021-09-14 10:17 ` [PATCH v2 2/3] drm/probe-helper: Create a HPD IRQ event helper for a single connector Maxime Ripard
[not found] ` <YUB8c2If+E851x4A@ravnborg.org>
2021-09-14 15:06 ` Maxime Ripard
2021-09-28 10:36 ` (subset) " Maxime Ripard
2021-09-14 10:17 ` [PATCH v2 3/3] drm/vc4: hdmi: Actually check for the connector status in hotplug Maxime Ripard
2021-09-14 14:34 ` Daniel Vetter [this message]
2021-09-14 15:03 ` Maxime Ripard
2021-09-28 10:36 ` (subset) " Maxime Ripard
2021-09-28 10:36 ` (subset) [PATCH v2 1/3] drm/probe-helper: Document drm_helper_hpd_irq_event() return value Maxime Ripard
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=YUCy4AmYDFD2jtG6@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=daniel.vetter@intel.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dom@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emma@anholt.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime@cerno.tech \
--cc=nsaenz@kernel.org \
--cc=phil@raspberrypi.com \
--cc=sam@ravnborg.org \
--cc=tim.gover@raspberrypi.com \
--cc=tzimmermann@suse.de \
--subject='Re: [PATCH v2 3/3] drm/vc4: hdmi: Actually check for the connector status in hotplug' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).