On 09/12/2020 14:08, Daniel Vetter wrote: > On Wed, Dec 9, 2020 at 1:06 PM Tomi Valkeinen <tomi.valkei...@ti.com> wrote: >> >> On 09/12/2020 13:56, Daniel Vetter wrote: >>> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen <tomi.valkei...@ti.com> >>> wrote: >>>> >>>> On 09/12/2020 02:48, Daniel Vetter wrote: >>>>> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote: >>>>>> Use devm_drm_irq_install to register interrupts so that >>>>>> drm_irq_uninstall is not needed to be called. >>>>>> >>>>>> Signed-off-by: Tian Tao <tiant...@hisilicon.com> >>>>> >>>>> There's another drm_irq_install in the error path. But I'm not sure this >>>>> is safe since you're chaning the order in which things get cleaned up now. >>>>> So leaving this up to Tomi. >>>> >>>> Right, I don't think this works. tidss irq_uninstall uses runtime_get/put, >>>> which needs to happen >>>> before pm_runtime_disable. With devm_drm_irq_install that's not the case. >>> >>> Hm I don't spot devm_ versions of these, surely we're not the only >>> ones with this problem? >> >> drm-misc-next has these. hisilicon uses it, but doesn't have an >> irq_uninstall hook, so possibly late >> uninstall is fine there. > > I meant a devm_ version of pm_runtime_enable. Or some other way to > make this just work.
I see. No, I don't think we have. Also, I feel a bit uncomfortable with devm'ified irq request/free. devm is fine for allocs and reserving stuff, but this one affects the HW state, and your irq handler could get called until devm frees the irq at some late point of time. Well, it can be made to work, but just need to be careful. I've had my irq handlers getting called too early or too late so many times that I'm a bit paranoid about it =). Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
