On Wed, Apr 07, 2021 at 02:54:00PM +0800, Dinghao Liu wrote:
pm_runtime_set_active(&client->dev);
pm_runtime_set_autosuspend_delay(&client->dev, 1000);
pm_runtime_use_autosuspend(&client->dev);
pm_runtime_enable(&client->dev);
pm_runtime_mark_last_busy(&client->dev);
pm_runtime_put_sync_autosuspend(&client->dev);
dev_set_drvdata(&client->dev, data);
ret = devm_snd_soc_register_component(&client->dev,
@@ -733,6 +726,13 @@ static int tas2552_probe(struct i2c_client *client, if (ret < 0) dev_err(&client->dev, "Failed to register component: %d\n", ret);
- pm_runtime_set_active(&client->dev);
- pm_runtime_set_autosuspend_delay(&client->dev, 1000);
- pm_runtime_use_autosuspend(&client->dev);
It's not clear to me that just moving the operations after the registration is a good fix - once the component is registered we could start trying to do runtime PM operations with it which AFAIR won't count references and so on properly if runtime PM isn't enabled so if we later enable runtime PM we might have the rest of the code in a confused state about what's going on.
Thanks for your advice. I checked the use of devm_snd_soc_register_component() in the kernel and found sometimes runtime PM is enabled before registration and sometimes after registration. To be on the safe side, I will send a new patch to fix this in error handling path.
Regards, Dinghao