From: Thomas Hellstrom <thellstrom@vmware.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: Modesetting lock changes breaks vmwgfx since 3.18-rc1
Date: Mon, 3 Nov 2014 11:29:39 +0100 [thread overview]
Message-ID: <54575913.9030506@vmware.com> (raw)
In-Reply-To: <20141031173321.GX26941@phenom.ffwll.local>
Hi!
On 10/31/2014 06:33 PM, Daniel Vetter wrote:
> On Thu, Oct 30, 2014 at 03:41:31PM +0100, Thomas Hellstrom wrote:
>> Hi!
>>
>> Details in
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1155825&d=AAIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=lsrU5TbpNlecpBoc0CpsmwopYh2VrihduvgGEIFPsXw&s=uzLKWffads4edz_fJN5-3K2IObzmVFUcH6kty4ObySs&e=
>>
>> Can whoever broke the driver please make an effort to fix it up?
>>
>> Daniel, You've been named as a suspect. I'm not sure if that is true.
> Yeah the recent locking frobbing didn't account for the FIXME comment in
> vmwgfx. Might be good to address that long-term to get vmwgfx more in line
> with everyone else again - I simply don't understand the interactions well
> enough to make that call. There's two of those in total.
>
> Can we just remove them perhaps? The question is whether you can do the
> cursor operation just with the per-crtc lock as protection, or whether
> there's any shared resources and you need the full exclusion provided by
> modeset_lock_all. If the crtc locking is good enough then we could rip
> this out in both function and be done.
>
> Note that this FIXME has been in vmwgfx since almost two years now.
>
> If that's not possible then I have a major kludge of a hack in my atomic
> helpers branch which will keep this alive for a bit longer. It ain't
> pretty though.
>
> Cheers, Daniel
Hi.
Actually we haven't looked much at the new modesetting locking at all
but been pretty happy with what others have put in the code, but it
sounds like we need to actually deal with this now. I've basically never
been really convinced that we'd see any modesetting locking contention
with a single lock, but OTOH I guess with a single lock we'd eventually
start to run into locking recursion problems.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-11-03 10:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 14:41 Modesetting lock changes breaks vmwgfx since 3.18-rc1 Thomas Hellstrom
2014-10-31 17:33 ` Daniel Vetter
2014-11-03 10:29 ` Thomas Hellstrom [this message]
2014-11-03 16:10 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54575913.9030506@vmware.com \
--to=thellstrom@vmware.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.