On 08/09/2017 08:00 PM, Daniel Vetter wrote:
On Wed, Aug 9, 2017 at 7:50 PM, Thomas Hellstrom <thellst...@vmware.com> wrote:
On 08/09/2017 07:40 PM, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:38:29PM +0200, Daniel Vetter wrote:
On Wed, Aug 09, 2017 at 07:17:54PM +0200, Sinclair Yeh wrote:
From: Thomas Hellstrom <thellst...@vmware.com>
See LWN article at
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
Reviewed-by: Deepak Singh Rawat <dra...@vmware.com>
Reviewed-by: Sinclair Yeh <s...@vmware.com>
We definitely can't do this in general due to latency reasons. Please
read the kerneldoc of drm_irq_install and just roll your own. This also
seems to like break every driver's compilation.
Oops misread, I thought you rename stuff instead of adding. I still don't
see the point - drm_irq_install happened because of the *bsd abstraction
layer, not because it's actually all that useful.
So the whole point of this is to replace the vmwgfx tasklets with treaded
irqs to be nicer on the system. Seems like no other drivers use tasklets at
The vmwgfx driver is using drm_irq_install(), Of course we could duplicate
that code into the driver, but I don't see the point in doing that nor how
this would violate what's written in the drm_irq_install kerneldoc? It just
extends its functionality somewhat.
Ok, it only says you should roll your own if your simple needs extend
to needing multiple devices, but threaded interrupts, priorities,
whatever else also belongs in there. The only reason we had this
abstraction was really only the *bsd stuff and maybe ums. Simply
open-coding is imo much better, since then you can even do stuff like
using the devm_ variants and other bits. It's not so bad that I'd
outright remove it all (there's better things to clean up), but imo
really no point extending it.
That's pretty much the same answer as when people wanted to extend
this to multiple devices 3 years ago, again with "it's just a minor
OK. We'll roll our own.
dri-devel mailing list