Re: [Intel-gfx] [PATCH 4/8] drm: Move -old_fb from crtc to plane

2014-07-30 Thread Daniel Vetter
On Tue, Jul 29, 2014 at 04:46:11PM -0700, Matt Roper wrote: On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote: Atomic implemenations for legacy ioctls must be able to drop locks. Which doesn't cause havoc since we only do that while constructing the new state, so no driver or

[Intel-gfx] [PATCH 4/8] drm: Move -old_fb from crtc to plane

2014-07-29 Thread Daniel Vetter
Atomic implemenations for legacy ioctls must be able to drop locks. Which doesn't cause havoc since we only do that while constructing the new state, so no driver or hardware state change has happened. The only troubling bit is the fb refcounting the core does - if someone else has snuck in then

Re: [Intel-gfx] [PATCH 4/8] drm: Move -old_fb from crtc to plane

2014-07-29 Thread Dave Airlie
On 30 July 2014 07:32, Daniel Vetter daniel.vet...@ffwll.ch wrote: Atomic implemenations for legacy ioctls must be able to drop locks. Which doesn't cause havoc since we only do that while constructing the new state, so no driver or hardware state change has happened. The only troubling bit

Re: [Intel-gfx] [PATCH 4/8] drm: Move -old_fb from crtc to plane

2014-07-29 Thread Matt Roper
On Tue, Jul 29, 2014 at 11:32:19PM +0200, Daniel Vetter wrote: Atomic implemenations for legacy ioctls must be able to drop locks. Which doesn't cause havoc since we only do that while constructing the new state, so no driver or hardware state change has happened. The only troubling bit is