From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Paul Wise" <pabs3@bonedaddy.net>,
"Ilpo Järvinen" <ilpo.jarvinen@cs.helsinki.fi>,
stable@vger.kernel.org, "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Harish Chegondi" <harish.chegondi@intel.com>
Subject: Re: [PATCH 2/2] drm: add fallback override/firmware EDID modes workaround
Date: Fri, 7 Jun 2019 17:10:21 +0200 [thread overview]
Message-ID: <20190607151021.GJ21222@phenom.ffwll.local> (raw)
In-Reply-To: <20190607110513.12072-2-jani.nikula@intel.com>
On Fri, Jun 07, 2019 at 02:05:13PM +0300, Jani Nikula wrote:
> We've moved the override and firmware EDID (simply "override EDID" from
> now on) handling to the low level drm_do_get_edid() function in order to
> transparently use the override throughout the stack. The idea is that
> you get the override EDID via the ->get_modes() hook.
>
> Unfortunately, there are scenarios where the DDC probe in drm_get_edid()
> called via ->get_modes() fails, although the preceding ->detect()
> succeeds.
>
> In the case reported by Paul Wise, the ->detect() hook,
> intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the
> case reported by Ilpo Järvinen, there is no ->detect() hook, which is
> interpreted as connected. The subsequent DDC probe reached via
> ->get_modes() fails, and we don't even look at the override EDID,
> resulting in no modes being added.
>
> Because drm_get_edid() is used via ->detect() all over the place, we
> can't trivially remove the DDC probe, as it leads to override EDID
> effectively meaning connector forcing. The goal is that connector
> forcing and override EDID remain orthogonal.
>
> Generally, the underlying problem here is the conflation of ->detect()
> and ->get_modes() via drm_get_edid(). The former should just detect, and
> the latter should just get the modes, typically via reading the EDID. As
> long as drm_get_edid() is used in ->detect(), it needs to retain the DDC
> probe. Or such users need to have a separate DDC probe step first.
>
> Work around the regression by falling back to a separate attempt at
> getting the override EDID at drm_helper_probe_single_connector_modes()
> level. With a working DDC and override EDID, it'll never be called; the
> override EDID will come via ->get_modes(). There will still be a failing
> DDC probe attempt in the cases that require the fallback.
I think we should also highlight here that EDID caching between ->detect
and ->get_modes is a further complicating concern, which is why making
drm_do_get_edid magically dtrt between ->detect and ->get_modes doesn't
work either.
Aside from that nit I think this covers our lengthy discussion completely.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583
> Reported-by: Paul Wise <pabs3@bonedaddy.net>
> Cc: Paul Wise <pabs3@bonedaddy.net>
> References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi
> Reported-by: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
> Cc: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
> References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid ddc probe")
> Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at drm_do_get_edid() level")
> Cc: <stable@vger.kernel.org> # v4.15+
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Harish Chegondi <harish.chegondi@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
As discussed on irc, we need tested-by here from the reporters since
there's way too many losing and frustrangingly few winning moves here.
With all that, on the series:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thanks a lot for slogging through all this and pondering all the options
and implications!
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 29 +++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_probe_helper.c | 7 +++++++
> include/drm/drm_edid.h | 1 +
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c59a1e8c5ada..780146bfc225 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1587,6 +1587,35 @@ static struct edid *drm_get_override_edid(struct drm_connector *connector)
> return IS_ERR(override) ? NULL : override;
> }
>
> +/**
> + * drm_add_override_edid_modes - add modes from override/firmware EDID
> + * @connector: connector we're probing
> + *
> + * Add modes from the override/firmware EDID, if available. Only to be used from
> + * drm_helper_probe_single_connector_modes() as a fallback for when DDC probe
> + * failed during drm_get_edid() and caused the override/firmware EDID to be
> + * skipped.
> + *
> + * Return: The number of modes added or 0 if we couldn't find any.
> + */
> +int drm_add_override_edid_modes(struct drm_connector *connector)
> +{
> + struct edid *override;
> + int num_modes = 0;
> +
> + override = drm_get_override_edid(connector);
> + if (override) {
> + num_modes = drm_add_edid_modes(connector, override);
> + kfree(override);
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] adding %d modes via fallback override/firmware EDID\n",
> + connector->base.id, connector->name, num_modes);
> + }
> +
> + return num_modes;
> +}
> +EXPORT_SYMBOL(drm_add_override_edid_modes);
> +
> /**
> * drm_do_get_edid - get EDID data using a custom EDID block read function
> * @connector: connector we're probing
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index 01e243f1ea94..ef2c468205a2 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -480,6 +480,13 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
>
> count = (*connector_funcs->get_modes)(connector);
>
> + /*
> + * Fallback for when DDC probe failed in drm_get_edid() and thus skipped
> + * override/firmware EDID.
> + */
> + if (count == 0 && connector->status == connector_status_connected)
> + count = drm_add_override_edid_modes(connector);
> +
> if (count == 0 && connector->status == connector_status_connected)
> count = drm_add_modes_noedid(connector, 1024, 768);
> count += drm_helper_probe_add_cmdline_mode(connector);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 88b63801f9db..b9719418c3d2 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -478,6 +478,7 @@ struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> struct i2c_adapter *adapter);
> struct edid *drm_edid_duplicate(const struct edid *edid);
> int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> +int drm_add_override_edid_modes(struct drm_connector *connector);
>
> u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
> enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2019-06-07 15:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 11:05 [PATCH 1/2] drm/edid: abstract override/firmware EDID retrieval Jani Nikula
2019-06-07 11:05 ` [PATCH 2/2] drm: add fallback override/firmware EDID modes workaround Jani Nikula
2019-06-07 15:10 ` Daniel Vetter [this message]
2019-06-08 1:06 ` Paul Wise
2019-06-08 5:10 ` Paul Wise
2019-06-08 5:48 ` Paul Wise
2019-06-10 9:32 ` Jani Nikula
2019-06-11 8:28 ` Paul Wise
2019-06-08 15:40 ` Paul Wise
2019-06-10 9:30 ` [PATCH v2] " Jani Nikula
2019-06-11 8:27 ` Paul Wise
2019-06-12 10:53 ` Jani Nikula
2019-06-07 11:48 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval Patchwork
2019-06-07 12:08 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-09 22:57 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-06-10 12:31 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval (rev2) Patchwork
2019-06-10 12:53 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-11 6:26 ` ✓ Fi.CI.IGT: " Patchwork
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=20190607151021.GJ21222@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=harish.chegondi@intel.com \
--cc=ilpo.jarvinen@cs.helsinki.fi \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=pabs3@bonedaddy.net \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@linux.intel.com \
/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