diff mbox series

[RESEND,1/2] soc: qcom: cmd-db: Mark device as having no PM support

Message ID 20221015004934.3930651-1-swboyd@chromium.org
State Accepted
Commit 5f7e2cb56af6800a4158514cc27921141e67ae19
Headers show
Series [RESEND,1/2] soc: qcom: cmd-db: Mark device as having no PM support | expand

Commit Message

Stephen Boyd Oct. 15, 2022, 12:49 a.m. UTC
This driver purely exposes information from memory to the kernel. Let's
mark it as not having any device PM functionality, so that during
suspend we skip even trying to call a suspend function on this device.
This clears up suspend logs more than anything else, but it also shaves
a few cycles off suspend.

Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---

Resend to fix Bjorn's email.

 drivers/soc/qcom/cmd-db.c | 2 ++
 1 file changed, 2 insertions(+)


base-commit: 4fe89d07dcc2804c8b562f6c7896a45643d34b2f

Comments

Bjorn Andersson Oct. 18, 2022, 3:15 a.m. UTC | #1
On Fri, 14 Oct 2022 17:49:33 -0700, Stephen Boyd wrote:
> This driver purely exposes information from memory to the kernel. Let's
> mark it as not having any device PM functionality, so that during
> suspend we skip even trying to call a suspend function on this device.
> This clears up suspend logs more than anything else, but it also shaves
> a few cycles off suspend.
> 
> 
> [...]

Applied, thanks!

[1/2] soc: qcom: cmd-db: Mark device as having no PM support
      commit: 5f7e2cb56af6800a4158514cc27921141e67ae19
[2/2] soc: qcom: stats: Mark device as having no PM support
      commit: 367b9c70e9b25fe9ad5346b0f3544682d8b112b9

Best regards,
Pavan Kondeti July 22, 2024, 4:55 a.m. UTC | #2
Hi Stephen,
On Fri, Oct 14, 2022 at 05:49:33PM -0700, Stephen Boyd wrote:
> This driver purely exposes information from memory to the kernel. Let's
> mark it as not having any device PM functionality, so that during
> suspend we skip even trying to call a suspend function on this device.
> This clears up suspend logs more than anything else, but it also shaves
> a few cycles off suspend.
> 
> Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> 
> Resend to fix Bjorn's email.
> 
>  drivers/soc/qcom/cmd-db.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
> index 629a7188b576..33856abd560c 100644
> --- a/drivers/soc/qcom/cmd-db.c
> +++ b/drivers/soc/qcom/cmd-db.c
> @@ -338,6 +338,8 @@ static int cmd_db_dev_probe(struct platform_device *pdev)
>  
>  	debugfs_create_file("cmd-db", 0400, NULL, NULL, &cmd_db_debugfs_ops);
>  
> +	device_set_pm_not_required(&pdev->dev);
> +
>  	return 0;
>  }
>  
> 

Sorry for asking this question here, thought it would be easy for you to
get the context.

I was recently reading this driver and learned about
device_set_pm_not_required() API. However, it is not clear how this is
working in practice? 

The driver is calling device_set_pm_not_required() in probe(), however
all the checks for device_pm_not_required() happen before probe() is
called. For ex: dpm_sysfs_add() and device_pm_add() both happens before
probe(). I was expecting not to see
/sys/bus/platform/devices/XXXXXX.aop-cmd-db/power directory but it is
still present.

Also, I believe once driver set this flag, the device clean up might not
remove sysfs entries as we have device_pm_not_required() checks active
by that time.

Would it make sense to add code after probe() and take some action if
device_pm_not_required() returns true?

Thanks,
Pavan
diff mbox series

Patch

diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
index 629a7188b576..33856abd560c 100644
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -338,6 +338,8 @@  static int cmd_db_dev_probe(struct platform_device *pdev)
 
 	debugfs_create_file("cmd-db", 0400, NULL, NULL, &cmd_db_debugfs_ops);
 
+	device_set_pm_not_required(&pdev->dev);
+
 	return 0;
 }