[PATCH v1 1/1] platform/x86/intel: atomisp2: Replace deprecated UNIVERSAL_DEV_PM_OPS()

[PATCH v1 1/1] platform/x86/intel: atomisp2: Replace deprecated UNIVERSAL_DEV_PM_OPS()

[Andy Shevchenko]

The UNIVERSAL_DEV_PM_OPS() macro is deprecated. Replace it.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/platform/x86/intel/atomisp2/pm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/intel/atomisp2/pm.c b/drivers/platform/x86/intel/atomisp2/pm.c
index 805fc0d8515c..1081b632bd5e 100644
--- a/drivers/platform/x86/intel/atomisp2/pm.c
+++ b/drivers/platform/x86/intel/atomisp2/pm.c
@@ -118,8 +118,7 @@ static int isp_pci_resume(struct device *dev)
 	return 0;
 }
 
-static UNIVERSAL_DEV_PM_OPS(isp_pm_ops, isp_pci_suspend,
-			    isp_pci_resume, NULL);
+static DEFINE_RUNTIME_DEV_PM_OPS(isp_pm_ops, isp_pci_suspend, isp_pci_resume, NULL);
 
 static const struct pci_device_id isp_id_table[] = {
 	{ PCI_VDEVICE(INTEL, 0x0f38), },
@@ -133,7 +132,7 @@ static struct pci_driver isp_pci_driver = {
 	.id_table = isp_id_table,
 	.probe = isp_probe,
 	.remove = isp_remove,
-	.driver.pm = &isp_pm_ops,
+	.driver.pm = pm_ptr(&isp_pm_ops),
 };
 
 module_pci_driver(isp_pci_driver);
-- 
2.43.0.rc1.1.gbec44491f096

Re: [PATCH v1 1/1] platform/x86/intel: atomisp2: Replace deprecated UNIVERSAL_DEV_PM_OPS()

[Hans de Goede]

Hi Andy,

On 4/3/24 12:55 PM, Andy Shevchenko wrote:
> The UNIVERSAL_DEV_PM_OPS() macro is deprecated. Replace it.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

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

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.

It seems there is no direct replacement for UNIVERSAL_DEV_PM_OPS()
without a behavior change.

Regards,

Hans




> ---
>  drivers/platform/x86/intel/atomisp2/pm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel/atomisp2/pm.c b/drivers/platform/x86/intel/atomisp2/pm.c
> index 805fc0d8515c..1081b632bd5e 100644
> --- a/drivers/platform/x86/intel/atomisp2/pm.c
> +++ b/drivers/platform/x86/intel/atomisp2/pm.c
> @@ -118,8 +118,7 @@ static int isp_pci_resume(struct device *dev)
>  	return 0;
>  }
>  
> -static UNIVERSAL_DEV_PM_OPS(isp_pm_ops, isp_pci_suspend,
> -			    isp_pci_resume, NULL);
> +static DEFINE_RUNTIME_DEV_PM_OPS(isp_pm_ops, isp_pci_suspend, isp_pci_resume, NULL);
>  
>  static const struct pci_device_id isp_id_table[] = {
>  	{ PCI_VDEVICE(INTEL, 0x0f38), },
> @@ -133,7 +132,7 @@ static struct pci_driver isp_pci_driver = {
>  	.id_table = isp_id_table,
>  	.probe = isp_probe,
>  	.remove = isp_remove,
> -	.driver.pm = &isp_pm_ops,
> +	.driver.pm = pm_ptr(&isp_pm_ops),
>  };
>  
>  module_pci_driver(isp_pci_driver);

Re: [PATCH v1 1/1] platform/x86/intel: atomisp2: Replace deprecated UNIVERSAL_DEV_PM_OPS()

[Andy Shevchenko]

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?

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] platform/x86/intel: atomisp2: Replace deprecated UNIVERSAL_DEV_PM_OPS()

[Hans de Goede]

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