[PATCH] drm: Support drivers with threaded irqs
Thomas Hellstrom
thellstrom at vmware.com
Wed Aug 9 18:18:35 UTC 2017
On 08/09/2017 08:00 PM, Daniel Vetter wrote:
> On Wed, Aug 9, 2017 at 7:50 PM, Thomas Hellstrom <thellstrom at 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 <thellstrom at vmware.com>
>>>>>
>>>>> See LWN article at
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_302043_&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=NYyVOtVu5iQrNCGt-QcVtR_IU0lhhztOmFP3qnN88tc&s=ruWozYT16Yk3p7sIscOFDNKCC1_WHX_7ChY7q5Ko4vw&e=
>>>>>
>>>>> Signed-off-by: Thomas Hellstrom <thellstrom at vmware.com>
>>>>> Reviewed-by: Deepak Singh Rawat <drawat at vmware.com>
>>>>> Reviewed-by: Sinclair Yeh <syeh at 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.
>>> -Daniel
>>
>> 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
> extension".
> -Daniel
OK. We'll roll our own.
/Thomas
More information about the dri-devel
mailing list