From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
intel-gfx@lists.freedesktop.org,
DRI Development <dri-devel@lists.freedesktop.org>,
Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)
Date: Wed, 12 Nov 2014 13:49:47 +0200 [thread overview]
Message-ID: <20141112114947.GO10649@intel.com> (raw)
In-Reply-To: <20141111093057.GF25711@phenom.ffwll.local>
On Tue, Nov 11, 2014 at 10:30:57AM +0100, Daniel Vetter wrote:
> On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote:
> > As a side note if someone is looking for stuff to do, then the pin/unpin
> > logic might be good thing to look at. We're currently a bit inconsistent
> > whether we have the buffer pinned when the plane is disabled, or just
> > otherwise invisible, or when the crtc itself is disabled. And I guess
> > cooking up some tests to poke at planes with disabled crtcs might be in
> > order too, as well as all kinds of variations on the
> > crtc_enable->plane_enable->crtc_disable->plane_disable theme.
>
> Hm, I've thought that thus far we've kept the buffer pinned when the crtc
> is enabled (irrespective or crtc state). And when the crtc gets disabled
> we dropped the buffers. Then planes happened and everything got messy.
>
> Actually I'm not really sure what the right semantics are here - in the
> atomic helpers I don't disable planes/framebuffers. Which is consistent
> with the legacy plane interface, but not consistent with the legacy
> setCrtc ioctl.
>
> Anyone has a good idea how to handle all this properly?
Well I think we should avoid the "change in property X changes
property Y" problem. That means leaving the plane->fb alone when the
crtc is disabled.
But as as far as the pinning goes, my original idea was that we keep
things pinned as long as plane->fb is set, whether the plane is
invisible or crtc disabled. The idea was you could set up all the planes
in advance, and then enable the crtc and it would at least not fail due
to failure to pin the buffers.
But that is rather wasteful and might prevent defragmenting the address
space. So I suppose we should just change things so that at least we
don't keep the buffers pinned when the crtc is disabled. And perhaps
we should just go all the way and not pin when the plane is invisible,
for any reason.
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-11-12 11:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 13:51 [PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates Gustavo Padovan
2014-10-24 13:51 ` [PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates Gustavo Padovan
2014-10-30 13:32 ` Paulo Zanoni
2014-10-30 14:08 ` [Intel-gfx] " Imre Deak
2014-10-30 14:34 ` Ville Syrjälä
2014-10-30 18:02 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Paulo Zanoni
2014-10-30 19:10 ` Ville Syrjälä
2014-10-30 19:33 ` Paulo Zanoni
2014-11-10 16:47 ` Paulo Zanoni
2014-11-10 17:15 ` Ville Syrjälä
2014-11-11 9:30 ` How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane) Daniel Vetter
2014-11-12 11:49 ` Ville Syrjälä [this message]
2014-11-12 14:22 ` How to handle planes/fbs when disabling the crtc? (was " Daniel Vetter
2014-11-12 14:45 ` Ville Syrjälä
2014-11-11 9:31 ` [PATCH] drm/i915: use the correct obj when preparing the sprite plane Daniel Vetter
2014-11-11 8:41 ` [PATCH] drm/i915: use the correct obj when preparing shuang.he
2014-10-24 13:51 ` [PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects Gustavo Padovan
2014-10-24 13:51 ` [PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active Gustavo Padovan
2014-10-24 15:07 ` Ville Syrjälä
2014-10-27 9:10 ` Daniel Vetter
2014-10-24 13:51 ` [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj() Gustavo Padovan
2014-10-24 15:16 ` Ville Syrjälä
2014-10-28 12:02 ` Gustavo Padovan
2014-10-28 12:35 ` [Intel-gfx] " Ville Syrjälä
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=20141112114947.GO10649@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
/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