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@xxxxxxxxxx> > > > Cc: Thomas Hellstrom <thellstrom@xxxxxxxxxx> > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
