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)
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? -Daniel
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.
On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
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.
The problem is a bit that the legacy setCrtc does free the buffer, and userspace might rely on that. So if we decide to keep the plane fb around when the crtc is disabled we need to at least update the set_config atomic helper function to release the fb of the primary plane and unlink/disable the primary plane. -Daniel
On Wed, Nov 12, 2014 at 03:22:07PM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 01:49:47PM +0200, Ville Syrjälä wrote:
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.
The problem is a bit that the legacy setCrtc does free the buffer, and userspace might rely on that. So if we decide to keep the plane fb around when the crtc is disabled we need to at least update the set_config atomic helper function to release the fb of the primary plane and unlink/disable the primary plane.
Sounds reasonable. At least I'd prefer if we can keep such uglies neatly tucked away in their own legacy corner, and not let them spread into the general population.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Ville Syrjälä