mbox series

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

Message ID 20210727182721.17981-1-tzimmermann@suse.de (mailing list archive)
Headers show
Series drm: Make DRM's IRQ helpers legacy | expand

Message

Thomas Zimmermann July 27, 2021, 6:27 p.m. UTC
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

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c      |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c      |  21 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h      |   2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c              | 174 ++++++++++---------
 drivers/gpu/drm/arm/hdlcd_drv.h              |   1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  85 +++++----
 drivers/gpu/drm/drm_irq.c                    |  95 +---------
 drivers/gpu/drm/drm_legacy_misc.c            |   3 +-
 drivers/gpu/drm/drm_vblank.c                 |   8 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c    |  78 +++++----
 drivers/gpu/drm/gma500/power.c               |   1 +
 drivers/gpu/drm/gma500/psb_drv.c             |   8 +-
 drivers/gpu/drm/gma500/psb_drv.h             |   5 -
 drivers/gpu/drm/gma500/psb_irq.c             |  26 ++-
 drivers/gpu/drm/gma500/psb_irq.h             |   4 +-
 drivers/gpu/drm/i810/i810_dma.c              |   3 +-
 drivers/gpu/drm/kmb/kmb_drv.c                |  26 ++-
 drivers/gpu/drm/mga/mga_dma.c                |   2 +-
 drivers/gpu/drm/mga/mga_drv.h                |   1 -
 drivers/gpu/drm/msm/msm_drv.c                | 113 +++++++-----
 drivers/gpu/drm/msm/msm_kms.h                |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c            |  81 +++++----
 drivers/gpu/drm/mxsfb/mxsfb_drv.h            |   2 +
 drivers/gpu/drm/r128/r128_cce.c              |   3 +-
 drivers/gpu/drm/radeon/radeon_drv.c          |   4 -
 drivers/gpu/drm/radeon/radeon_irq_kms.c      |  44 ++++-
 drivers/gpu/drm/radeon/radeon_kms.h          |   4 -
 drivers/gpu/drm/tidss/tidss_drv.c            |  15 +-
 drivers/gpu/drm/tidss/tidss_drv.h            |   2 +
 drivers/gpu/drm/tidss/tidss_irq.c            |  27 ++-
 drivers/gpu/drm/tidss/tidss_irq.h            |   4 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c          |  51 ++++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h          |   3 +
 drivers/gpu/drm/vc4/vc4_drv.c                |   4 -
 drivers/gpu/drm/vc4/vc4_drv.h                |   8 +-
 drivers/gpu/drm/vc4/vc4_irq.c                |  48 +++--
 drivers/gpu/drm/vc4/vc4_v3d.c                |  17 +-
 drivers/gpu/drm/via/via_mm.c                 |   3 +-
 include/drm/drm_device.h                     |  18 +-
 include/drm/drm_drv.h                        |  44 +----
 include/drm/drm_irq.h                        |  32 ----
 include/drm/drm_legacy.h                     |   3 +
 42 files changed, 572 insertions(+), 504 deletions(-)
 delete mode 100644 include/drm/drm_irq.h


base-commit: 2bda1ca4d4acb4892556fec3a7ea1f02afcd40bb
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
--
2.32.0

Comments

Sam Ravnborg July 27, 2021, 6:51 p.m. UTC | #1
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.

Before diving into a review of these..
Any specific reason devm_request_irq is not used?

	Sam
Thomas Zimmermann July 28, 2021, 5:19 a.m. UTC | #2
Hi Sam

Am 27.07.21 um 20:51 schrieb Sam Ravnborg:
> 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.
> 
> Before diving into a review of these..
> Any specific reason devm_request_irq is not used?

Thanks for looking at the patches.

Switching to devm_ definately makes sense in the longer term.
  I didn't do this here to not change the order of clean-up operations 
in general. And some of the drivers have dedicated IRQ clean-up code, 
which might depend on the correct order as well.

Best regards
Thomas

> 
> 	Sam
>
Sam Ravnborg July 31, 2021, 6:50 p.m. UTC | #3
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.

1) IRQ_NOTCONNECTED

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:
https://elixir.bootlin.com/linux/latest/A/ident/IRQ_NOTCONNECTED

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.

	Sam
Thomas Zimmermann Aug. 1, 2021, 7:56 p.m. UTC | #4
Hi Sam

Am 31.07.21 um 20:50 schrieb Sam Ravnborg:
> 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.
> 
> 1) IRQ_NOTCONNECTED
> 
> 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:
> https://elixir.bootlin.com/linux/latest/A/ident/IRQ_NOTCONNECTED
> 
> 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)

I'll drop it from atmel_hlcdc then.

But saying that it's not used is not correct. At least radeon an gma500 
handle PCI-based devices and BIOSes often had the option of disabling 
the rsp graphics interrupts.

> 
> 
> 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.

I'll change this in atmel_hdlcd and maybe I can find trivial cases where 
devm_request_irq() can be used. But drivers that had an uninstall 
callback before should not have the cleanup logic altered by a patch as 
this one. I suspect that most of the IRQ cleanup
is actually a vblank cleanup and should be done in response to 
drm_vblank_init(). But that's again not something for this patchset 
here. We cannot change multiple things at once and still expect any of 
it to work.

I welcome the use of devm_ et al. But these changes are better done in a 
per-driver patchset that changes all of the driver to managed release.

Best regards
Thomas

> 
> 	Sam
>
Sam Ravnborg Aug. 1, 2021, 8:24 p.m. UTC | #5
Hi Thomas,

> > 
> > 1) IRQ_NOTCONNECTED
> > 
> > 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:
> > https://elixir.bootlin.com/linux/latest/A/ident/IRQ_NOTCONNECTED
> > 
> > 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)
> 
> I'll drop it from atmel_hlcdc then.
> 
> But saying that it's not used is not correct.
My point is the drm_irq do not check this - so adding this check add
something there was not needed/done before.

> > 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.
> 
> I'll change this in atmel_hdlcd and maybe I can find trivial cases where
> devm_request_irq() can be used. But drivers that had an uninstall callback
> before should not have the cleanup logic altered by a patch as this one. I
> suspect that most of the IRQ cleanup
> is actually a vblank cleanup and should be done in response to
> drm_vblank_init(). But that's again not something for this patchset here. We
> cannot change multiple things at once and still expect any of it to work.
> 
> I welcome the use of devm_ et al. But these changes are better done in a
> per-driver patchset that changes all of the driver to managed release.
Fair enough, and fine with me.
I have yet to read through all patches - will do so in the coming week.

	Sam
Thomas Zimmermann Aug. 2, 2021, 8:42 a.m. UTC | #6
Hi Sam

Am 01.08.21 um 22:24 schrieb Sam Ravnborg:
> Hi Thomas,
> 
>>>
>>> 1) IRQ_NOTCONNECTED
>>>
>>> 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:
>>> https://elixir.bootlin.com/linux/latest/A/ident/IRQ_NOTCONNECTED
>>>
>>> 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)
>>
>> I'll drop it from atmel_hlcdc then.
>>
>> But saying that it's not used is not correct.
> My point is the drm_irq do not check this - so adding this check add
> something there was not needed/done before.

What is being done at [1] is actually a check for unassigned interrupts. 
It's just that both, test and errno code, are plain wrong. The patchset 
fixes this.

> 
>>> 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.
>>
>> I'll change this in atmel_hdlcd and maybe I can find trivial cases where
>> devm_request_irq() can be used. But drivers that had an uninstall callback
>> before should not have the cleanup logic altered by a patch as this one. I
>> suspect that most of the IRQ cleanup
>> is actually a vblank cleanup and should be done in response to
>> drm_vblank_init(). But that's again not something for this patchset here. We
>> cannot change multiple things at once and still expect any of it to work.
>>
>> I welcome the use of devm_ et al. But these changes are better done in a
>> per-driver patchset that changes all of the driver to managed release.
> Fair enough, and fine with me.
> I have yet to read through all patches - will do so in the coming week.

OK, thanks a lot. I'll send out a new revision soon, so maybe don't 
waste time with this one.

Best regards
Thomas


[1] 
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_irq.c#L111



> 
> 	Sam
>