[Intel-gfx] [PATCH 13/16] drm/i915: Properly track domain of the fbcon fb

[Daniel Vetter]

On Wed, Jun 18, 2014 at 01:10:32PM +0100, Chris Wilson wrote:
> On Wed, Jun 18, 2014 at 01:59:14PM +0200, Daniel Vetter wrote:
> > X could end up putting the fbcon fb into other domains, e.g.
> > for smooth take-overs. Also we want this for accurate frontbuffer
> > tracking: The set_config is an implicit flush and will re-enable
> > psr and similar features, so we need to bring the bo back into
> > the gtt domain.
> 
> Is this possibly an atomic path? It would be nice to have a note on
> fb_ops which were. But I remember having lots of in_atomic() handling
> for fbdev acceleration (copied from nouveau).

They are all callable from atomic, at least in Oopses. fbdev accel is
completely bonghits in that regard (imnsho) and I think the only option we
have is to block _any_ fbdev operation in atomic contexts from the start
and use David Herrmann's special last effort emergency logging support to
print the Oops. Even trying to make all this code work from atomic
contexts is imo a losing battle and a complete validation nightmare.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch