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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
