[PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

[Daniel Vetter]

On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> > On 03/22/2017 10:50 PM, Daniel Vetter wrote:
> > > It's been around forever, no one bothered to address the FIXME, so I
> > > presume it's all fine.
> > >
> > > Cc: Sinclair Yeh <syeh at vmware.com>
> > > Cc: Thomas Hellstrom <thellstrom at vmware.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > 
> > NAK. We need to properly address this. Probably as part of the atomic
> > update.
> 
> So could someone with vmwgfx understanding explain this? Note that the
> FIXME was originally added by me years ago, because I wasn't sure (only
> about 90%) that this is safe, and was essentially pleading for a vmwgfx
> expert to review this?
> 
> Since it didn't happen I presume it's not that terribly and probably safe
> ...
> 
> I'm still 90% sure that this is correct, but I'd love for a vmwgfx to
> audit it. Replying with a NAK is kinda not the response I was hoping for
> (and yes I guess I should have explained what's going on here better, but
> it's just a git blame of the FIXME comment away).

Bit more context even: This lock dropping dance is _not_ safe from a drm
core perspective. But when I've done the original kms locking rework the
tradeoff between upsetting core state a bit and totally breaking vmwgfx
leaned towards not breaking vmwgfx. And iirc you or Syeh promised to look
at this and then either remove the FIXME, maybe with a vmwgfx lock/unlock
added if there's a gap (I looked, didn't find one, but I don't understand
vmwgfx in details really).

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch