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
> this point.
> 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
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
dri-devel mailing list