[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

[Tomi Valkeinen]

On 03/09/14 17:27, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
>> omap_crtc_flush() is used to wait for scheduled work to be done for the
>> give crtc. However, it's not quite right at the moment.
>>
>> omap_crtc_flush() does wait for work that is ran via vsync irq to be
>> done. However, work is also queued to the driver's priv->wq workqueue,
>> which is not handled by omap_crtc_flush().
>>
>> Improve omap_crtc_flush() to flush the workqueue so that work there will
>> be ran.
>>
>> This fixes a race issue on module unload, where an unpin work may be on
>> the work queue, but does not get ran before drm core starts tearing the
>> driver down, leading to a WARN.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> 
> I didn't really dig into details, but isn't that the same workqueue as
> used by the async modeset code? So the same deadlocks might happen ...

Yes, we have just one workqueue in the driver.

Hmm, deadlocks with what lock? The modeconfig or crtc->mutex? I don't
think they are locked at any place where omap_crtc_flush is called.

> lockdep won't complain though since you essentially open-code a
> workqueue_flush, and lockdep also doesn't complain about all possible
> deadlocks (due to some design issues with lockdep).

What do you mean "open-code a workqueue_flush"?. I use flush_workqueue
there. We have two things to wait for: work on the workqueue and work
which is triggered by the vsync irq. So we loop and test for both of
those, until there's no more work.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/07dced87/attachment-0001.sig>