[Intel-gfx] [PATCH v5 0/2] drm: Add detection of changing of edid on between suspend and resume
Mun, Gwan-gyeong
gwan-gyeong.mun at intel.com
Wed Apr 17 19:40:30 UTC 2019
On Mon, 2019-04-15 at 18:32 +0200, Daniel Vetter wrote:
> On Thu, Apr 11, 2019 at 05:36:30PM +0300, Gwan-gyeong Mun wrote:
> > This patch series fix missed detection of changing of edid on
> > between
> > suspend and resume.
> > First patch fixes drm_helper_hdp_irq_event() in order to fix a
> > below use
> > case.
> >
> > Following scenario requires detection of changing of edid.
> >
> > 1) plug display device to a connector
> > 2) system suspend
> > 3) unplug 1)'s display device and plug the other display device
> > to a
> > connector
> > 4) system resume
> >
> > It adds edid check routine when a connector status still remains as
> > "connector_status_connected".
> >
> > Second patch adds a missed update of edid property of drm connector
> > on i915.
> >
> > v2: Add NULL check before comparing of EDIDs.
> > v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan,
> > Mika)
> > v4: Rebased
> > v5: Use a cached edid property blob data of connector instead of
> > adding
> > a new detected_edid variable. (Maarten)
> > Add an using of reference count for getting a cached edid
> > property
> > blob data. (Maarten)
> >
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
> > Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
> > Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
> >
> > v1, v2: https://patchwork.freedesktop.org/series/47680/
> > v3: https://patchwork.freedesktop.org/series/49298/
> > v4: https://patchwork.freedesktop.org/series/57397/
>
> I guess I missed this, but there's a few fundamental things here
> first
> imo:
>
> - patch 2 is fallout from the fairly abitrary split between ->detect
> and
> ->get_modes. There's not really any good reason for that, I think
> we can
> just always call ->get_modes if ->detect says the connector is
> connected. There's more than just dp and hdmi (that's simply the 2
> things we test in CI using chamelium).
>
Thank you for checking it.
I agree. I'll modify first patch with your guide and will resend it.
> - the problem is bigger than just the edid changing (e.g. when
> repeaters
> change, or when something else changes aside from the edid, e.g. in
> dp
> aux, like how many lanes the dp cable has). Plus we have this long-
> term
> idea to give userspace a better idea about which connector exactly
> has
> changed. Therefor:
>
Yes, you pointed an essential problem.
> 1. add a new drm_connector->detect_epoque counter.
> 2. Increment that counter every time something has changed, i.e.
> from
> probe helpers (we can push this down into the detect wrappers) when
> connector->status has changed, or when we update the edid blob.
> 3. probe helpers look for changes in ->detect_epoque to decided
> whether
> to fire the uevent or not.
> 4. long term we could expose the ->detect_epoque as a read-only
> property, or at least supply information about which connector
> caused
> the uevent using the new drm_sysfs_connector_status_event() (see
> the
> patch from Ram "[PATCH v3 09/10] drm: uevent for connector status
> change").
>
I'll make new patches which followes your guide.
Thanks for reviewing it and giving me a new approach.
Br,
G.G.
> I think that gives us a much better long term foundation than adding
> lots
> of hacks.
>
> Cheers, Daniel
>
> > Gwan-gyeong Mun (2):
> > drm: Add detection of changing of edid on between suspend and
> > resume
> > drm/i915: Add a missed update of edid property of drm connector
> >
> > drivers/gpu/drm/drm_probe_helper.c | 34
> > +++++++++++++++++++++++++++++-
> > drivers/gpu/drm/i915/intel_dp.c | 1 +
> > drivers/gpu/drm/i915/intel_hdmi.c | 1 +
> > 3 files changed, 35 insertions(+), 1 deletion(-)
> >
> > --
> > 2.21.0
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
More information about the Intel-gfx
mailing list