Hi, On 4/9/24 7:15 PM, Andy Shevchenko wrote: > On Mon, Apr 08, 2024 at 06:20:03PM +0200, Hans de Goede wrote: >> On 4/3/24 12:55 PM, Andy Shevchenko wrote: > > ... > >> As mentioned in the description of DEFINE_RUNTIME_DEV_PM_OPS() >> DEFINE_RUNTIME_DEV_PM_OPS() is NOT a 1:1 replacement for >> UNIVERSAL_DEV_PM_OPS() specifically it uses pm_runtime_force_suspend() / >> pm_runtime_force_resume() . > > Right. > >> Specifically pm_runtime_force_suspend() may NOT get set (and in this case >> will not set) needs_force_resume skipping a resume + suspend cycle >> after a system suspend, which is a problem if firmware has touched >> the state of the device during the suspend/resume cycle since the device >> may now actually be left powered on. > > I see, thanks for explaining me this. So this driver is kinda very special. > Still the old question, can we get rid altogether of these atomisp "drivers" > in PDx86? At some time in the future yes. I've recently done some improvements to the staging atomisp driver so that it will run in a pm-only mode when the firmware is missing so that the ISP still gets turned off properly in this case and the driver now supports both BYT + CHT in a single build so in a way it is ready to replace the atomisp2 pm driver. But it is still in staging, so distros are unlikely to enable it and without a atomisp2-pm driver the battery drains much to quickly especially when suspended. So I think we are getting there, but now is not the right moment to drop this driver. >> It seems there is no direct replacement for UNIVERSAL_DEV_PM_OPS() >> without a behavior change. > > Correct. > > ... > > Btw, have you seen a few cleanup patches against AtomISP v2 by me? Yes I have a bit of a backlog, I have just processed them, thank you for those patches. Regards, Hans
