From: Daniel Vetter <daniel@ffwll.ch>
To: Jyri Sarha <jsarha@ti.com>
Cc: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: DRM driver and runtime suspend-resume handling?
Date: Tue, 14 Jan 2020 05:29:13 +0100 [thread overview]
Message-ID: <20200114042913.GF5340@dvetter-linux.ger.corp.intel.com> (raw)
In-Reply-To: <df769d2e-5fea-403f-2d04-b3239f89256f@ti.com>
On Mon, Jan 13, 2020 at 01:03:11PM +0200, Jyri Sarha wrote:
> Hi,
> While working with CRTC color related properties (gamma and CTM for
> instance) and making them persistent over suspend-resume cycle it
> occurred to me if I am just wasting resources by storing the property
> values in the driver and restoring them in dev_pm_ops runtime_resume()..
>
> Wouldn't it work if I would just:
>
> 1. Add a flag in the driver to indicate that the context may have been
> lost since the previous atomic commit and set in runtime_resume().
>
> 2. And write the color properties to HW if the context lost flag is set
> even if the drm_crtc_state color_mgmt_changed is false.
Still feels a bit too complicated, but might be needed for your hw. The
usual approach is:
- runtime pm within modeset enable/disable. Since atomic helpers always
enable the entire pipeline for a crtc enable/disable you can put the
runtime pm into each component (drm_crtc/encoder/bridge/...).
- just unconditionally restore everything in modeset enable, assuming
everything got lost.
- drm_atomic_helper_suspend/resume for system suspend/resume.
And you should be covevered. State save/restore in your driver code is
indeed an anti-pattern for modeset drivers, don't do that - ime at least
with fragile hw you'll get divergence between the two paths in minor
details, with some really hard to track down bugs as a result.
Ime tracking state changes and trying to be clever with when to restore
stuff (maybe outside of some atomic flip fastpath) in driver code only
attracts bugs :-)
> The color property values are there despite the color_mgmt_changed ==
> false, aren't they?
Yes.
Cheers, Daniel
>
> Best regards,
> Jyri
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-01-14 4:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 11:03 DRM driver and runtime suspend-resume handling? Jyri Sarha
2020-01-14 4:29 ` Daniel Vetter [this message]
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=20200114042913.GF5340@dvetter-linux.ger.corp.intel.com \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=tomi.valkeinen@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.