Messages in this thread | | | From | Doug Anderson <> | Date | Wed, 23 Feb 2022 08:37:44 -0800 | Subject | Re: [PATCH] drm/bridge: ti-sn65dsi86: Properly undo autosuspend |
| |
Hi,
On Wed, Feb 23, 2022 at 7:55 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > > How about a middle ground, though: we could add a devm function that > > does all the magic. Somewhat recently devm_pm_runtime_enable() was > > added. What if we add a variant for those that use autosuspend, like: > > > > devm_pm_runtime_enable_with_autosuspend(dev, initial_delay) > > > > That would: > > * pm_runtime_enable() > > * pm_runtime_set_autosuspend_delay() > > * pm_runtime_use_autosuspend() > > * Use devm_add_action_or_reset() to undo everything. > > > > Assuming that the pm_runtime folks are OK with that, we could > > transition things over to the new function once it rolls into > > mainline. > > > > So this doesn't magically fix all existing code but provides a path to > > make this more discoverable. > > Sounds like a good idea. I wonder if this could be handled by > devm_pm_runtime_enable() actually. If a driver calls > devm_pm_runtime_enable() and then enables auto-suspend, can't the > runtime PM core reasonably expect that auto-suspend should be disabled > at .remove() time ? The pm_runtime_disable_action() function could > disable auto-suspend unconditionally (assuming > pm_runtime_use_autosuspend() and pm_runtime_dont_use_autosuspend() don't > need to be balanced, if they do, then I'll just go cry in a corner).
I like your idea. I think you're right that we can just leverage the existing function. This yak didn't look to hairy, so I posted a patch:
https://lore.kernel.org/r/20220223083441.1.I925ce9fa12992a58caed6b297e0171d214866fe7@changeid
I guess now we see what Rafael thinks. ;-)
-Doug
| |