[PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

[Daniel Vetter]

On Tue, Mar 28, 2017 at 03:18:36PM +0300, Tomi Valkeinen wrote:
> On 27/03/17 10:43, Daniel Vetter wrote:
> 
> > With atomic we've stopped killing the entire CRTC when you the last
> > userspace reference for the framebuffer on the primary plane disappears,
> > but just shut down the primary plane. Assuming the driver can do that, we
> > fall back to full CRTC shutdown if not. That avoids a pile of flickering
> > and unecessary modesets.
> > 
> > But yeah downside is that the crtc is active even when unloading. Note
> 
> Not only that, but also when you stop a DRM userspace app and don't
> start a new one, the crtc stays active. Maybe that's not so common
> scenario, but I wouldn't be that surprised if on embedded world someone
> only runs a DRM app when they're showing something, and no app in
> between the runs.
> 
> What makes the behavior a bit funny is that if I boot without fbdev
> emulation, the crtcs stay off (as they should). But run a DRM app, quit
> it, and the crtcs are on.

Atm the recommendation is "don't do that". And keeping display state us
unchanged as possible is one of the things atomic was meant for: With
solid state tracking where sw state always matches hw state you can do
stuff like fastboot, i.e. take over the display state from firmware. Not a
common thing on embedded things, but rather important for i915. Ofc in
that case you can't use the reset helper, but instead need a hw state
readout logic.

> This is a bit related to the other annoyance, which is that we don't
> reset properties when a DRM app quits. I think the state of the HW
> should be restored to exactly the same state as it was (including
> turning off the crtcs). I'm planning to have a look at this whenever I
> happen to find some time...

I have a blog post with all the ideas from last time around we've
discussed this:

http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html

Consensus was that we'll look at this again when someone has a real use
case that needs it. And then maybe still decide that they just need a
system compositor :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch