From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 13/16] drm/i915: Properly track domain of the fbcon fb
Date: Wed, 18 Jun 2014 14:44:41 +0200 [thread overview]
Message-ID: <20140618124441.GF5821@phenom.ffwll.local> (raw)
In-Reply-To: <20140618121032.GA31023@nuc-i3427.alporthouse.com>
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
next prev parent reply other threads:[~2014-06-18 12:44 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 11:59 [PATCH 00/16] PSR rework and accurate frontbuffer tracking Daniel Vetter
2014-06-18 11:59 ` [PATCH 01/16] drm/i915: Drop unecessary complexity from psr_inactivate Daniel Vetter
2014-06-18 11:59 ` [PATCH 02/16] drm/i915: Ditch intel_edp_psr_update Daniel Vetter
2014-06-18 11:59 ` [PATCH 03/16] drm/i915: Run psr_setup unconditionally Daniel Vetter
2014-06-18 11:59 ` [PATCH 04/16] drm/i915: Drop schedule_back from psr_exit Daniel Vetter
2014-06-18 11:59 ` [PATCH 05/16] drm/i915: Add a FIXME about drrs/psr interactions Daniel Vetter
2014-06-18 11:59 ` [PATCH 06/16] drm/i915: Track the psr dp connector in dev_priv->psr.enabled Daniel Vetter
2014-06-18 11:59 ` [PATCH 07/16] drm/i915: Don't try to disable psr harder from the work item Daniel Vetter
2014-06-18 11:59 ` [PATCH 08/16] drm/i915: Lock down psr sw/hw state tracking Daniel Vetter
2014-06-18 11:59 ` [PATCH 09/16] drm/i915: More checks for psr.enabled Daniel Vetter
2014-06-18 12:27 ` Chris Wilson
2014-06-18 12:41 ` Daniel Vetter
2014-06-18 12:46 ` Chris Wilson
2014-06-18 13:03 ` Daniel Vetter
2014-06-18 11:59 ` [PATCH 10/16] drm/i915: Add locking to psr code Daniel Vetter
2014-06-18 11:59 ` [PATCH 11/16] drm/i915: Introduce accurate frontbuffer tracking Daniel Vetter
2014-06-18 12:20 ` Chris Wilson
2014-06-18 13:01 ` [PATCH] " Daniel Vetter
2014-06-18 14:55 ` Chris Wilson
2014-06-18 15:55 ` Daniel Vetter
2014-06-18 15:58 ` Chris Wilson
2014-06-18 16:05 ` Daniel Vetter
2014-06-18 16:14 ` Chris Wilson
2014-06-18 21:28 ` Daniel Vetter
2014-06-19 7:29 ` Chris Wilson
2014-06-18 13:05 ` [PATCH] drm/i915: Properly track domain of the fbcon fb Daniel Vetter
2014-06-18 14:57 ` Chris Wilson
2014-06-18 15:57 ` Daniel Vetter
2014-06-18 16:15 ` Chris Wilson
2014-06-18 11:59 ` [PATCH 12/16] drm/i915: Use new frontbuffer bits to increase pll clock Daniel Vetter
2014-06-18 14:46 ` Chris Wilson
2014-06-18 11:59 ` [PATCH 13/16] drm/i915: Properly track domain of the fbcon fb Daniel Vetter
2014-06-18 12:10 ` Chris Wilson
2014-06-18 12:44 ` Daniel Vetter [this message]
2014-06-18 13:09 ` [PATCH] " Daniel Vetter
2014-06-18 11:59 ` [PATCH 14/16] drm/i915: Track frontbuffer invalidation/flushing Daniel Vetter
2014-06-18 14:43 ` Chris Wilson
2014-06-19 12:41 ` [PATCH] " Daniel Vetter
2014-06-19 13:02 ` Chris Wilson
2014-06-19 13:54 ` Daniel Vetter
2014-06-19 14:01 ` Daniel Vetter
2014-06-19 15:12 ` Chris Wilson
2014-06-19 16:15 ` Daniel Vetter
2014-06-18 11:59 ` [PATCH 15/16] drm/i915: Fix up PSR frontbuffer tracking Daniel Vetter
2014-06-18 11:59 ` [PATCH 16/16] drm/i915: Improve PSR debugfs output Daniel Vetter
2014-06-18 12:46 ` [PATCH] drm/i915: Print obj->frontbuffer_bits in " Daniel Vetter
2014-06-18 14:50 ` Chris Wilson
2014-06-18 16:00 ` Daniel Vetter
2014-06-18 14:51 ` [PATCH 16/16] drm/i915: Improve PSR " Chris Wilson
2014-06-18 16:02 ` Daniel Vetter
2014-06-18 13:08 ` [PATCH] drm/i915: Remove redundant HAS_PSR checks Daniel Vetter
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=20140618124441.GF5821@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox