From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 13/16] drm/i915: Properly track domain of
 the fbcon fb
Date: Wed, 18 Jun 2014 14:44:41 +0200
Message-ID: <20140618124441.GF5821@phenom.ffwll.local>
References: <1403092757-31421-1-git-send-email-daniel.vetter@ffwll.ch>
 <1403092757-31421-14-git-send-email-daniel.vetter@ffwll.ch>
 <20140618121032.GA31023@nuc-i3427.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com
 [209.85.212.170])
 by gabe.freedesktop.org (Postfix) with ESMTP id 8AAB06E208
 for <intel-gfx@lists.freedesktop.org>; Wed, 18 Jun 2014 05:44:49 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cc10so8460579wib.1
 for <intel-gfx@lists.freedesktop.org>; Wed, 18 Jun 2014 05:44:48 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140618121032.GA31023@nuc-i3427.alporthouse.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

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