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@vmware.com Cc: Thomas Hellstrom thellstrom@vmware.com Signed-off-by: Daniel Vetter daniel.vetter@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