[PATCH 00/14] drm: Make DRM's IRQ helpers legacy

Sam Ravnborg sam at ravnborg.org
Sat Jul 31 18:50:02 UTC 2021

Hi Thomas,

On Tue, Jul 27, 2021 at 08:27:07PM +0200, Thomas Zimmermann wrote:
> DRM's IRQ helpers are only helpful for old, non-KMS drivers. Move
> the code behind CONFIG_DRM_LEGACY. Convert KMS drivers to Linux
> IRQ interfaces.
> DRM provides IRQ helpers for setting up, receiving and removing IRQ
> handlers. It's an abstraction over plain Linux functions. The code
> is mid-layerish with several callbacks to hook into the rsp drivers.
> Old UMS driver have their interrupts enabled via ioctl, so these
> abstractions makes some sense. Modern KMS manage all their interrupts
> internally. Using the DRM helpers adds indirection without benefits.
> Most KMs drivers already use Linux IRQ functions instead of DRM's
> abstraction layer. Patches 1 to 12 convert the remaining ones.
> The patches also resolve a bug for devices without assigned interrupt
> number. DRM helpers don't test for IRQ_NOTCONNECTED, so drivers do
> not detect if the device has no interrupt assigned.
> Patch 13 removes an unused function.
> Patch 14 moves the DRM IRQ helpers behind CONFIG_DRM_LEGACY. Only
> the old non-KMS drivers still use the functionality.
> Thomas Zimmermann (14):
>   drm/amdgpu: Convert to Linux IRQ interfaces
>   drm/arm/hdlcd: Convert to Linux IRQ interfaces
>   drm/atmel-hlcdc: Convert to Linux IRQ interfaces
>   drm/fsl-dcu: Convert to Linux IRQ interfaces
>   drm/gma500: Convert to Linux IRQ interfaces
>   drm/kmb: Convert to Linux IRQ interfaces
>   drm/msm: Convert to Linux IRQ interfaces
>   drm/mxsfb: Convert to Linux IRQ interfaces
>   drm/radeon: Convert to Linux IRQ interfaces
>   drm/tidss: Convert to Linux IRQ interfaces
>   drm/tilcdc: Convert to Linux IRQ interfaces
>   drm/vc4: Convert to Linux IRQ interfaces
>   drm: Remove unused devm_drm_irq_install()
>   drm: IRQ midlayer is now legacy

With the irq_enabled confusion out of the way I want to re-address two
issues here that I know you have answered but I am just not convinced.


We do not have this check in drm_irq today and we should avoid spreading
it all over. We are either carrying it forever or we wil lsee patches
floating in to drop the check again.
The current use in the kernel is minimal:

So as a minimum drop it from atmel_hlcdc and preferably from the rest as
it is really not used. (Speaking as atmel_hlcdc maintainer)

2) devm_request_irq()

We are moving towards managed allocation so we do not fail to free
resources. And an irq has a lifetime equal the device itself - so an
obvious cnadidate for devm_request_irq.
If we do not introduce it now we will see a revisit of this later.
I can be convinced to wait with this as we will have to do much more in
each driver, but I cannot see any good arguments to avoid the more
modern way to use devm_request_irq.


More information about the amd-gfx mailing list