This will be a recap of the discussions that already happened. The discussion spurred from the ov5640 conversion to runtime-pm and the final email from Laurent reports a few questions I hope can be answered during the meeting [1] I'm not going too much into details for the background here as Tomasz in the same discussion provided a rather complete overview [2] and there is large consensus that the current situation is not desirable as it leaves most of the work to sensor drivers. [1] https://lore.kernel.org/linux-media/YufZXoUSWzOqoVfZ@xxxxxxxxxxxxxxxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-media/CAAFQd5C7-OuNpnduwKpZXFUPQKDeqkz2xkvP+JBBs+aNjB87FQ@xxxxxxxxxxxxxx/ The first issue is what the I2C core does on ACPI systems i2c_device_probe() dev_pm_domain_attach() * ACPI: acpi_dev_pm_attach() -> actual power-up OF: genpd_dev_pm_attach() -> only parses "power-domains" * Supports ACPI D0 waiveing, but requires fw modifications Question 1: Is the desired behaviour to have the device powered up when probed ? Should we aim to have OF behave like ACPI or the other way around ? Not even sure that's possible or desirable to move to genpd_dev_pm_attach() the acquisition/enabling of resources considering how mildly enforced is the standardization of OF names for clock/regulators. Sakari suggested to extend the D0 waiving mechanism to work not only with an ACPI property but also with a device flag. This would work for new drivers, but porting the existing ones might be complicated if not impossible. Also, if we change ACPI systems not to power up the device, would the regulator/clock/gpio APIs work the same on OF/ACPI or we will end up duplicating the power-up routines ? Question 2: The runtime_pm dance. The problem is also complicated by the fact drivers have to handle cases where !CONFIG_PM and cannot rely on runtime_pm "doing the right thing" (once we know what the right thing would be), and hence device power-up during probe to support HW access have to be performed manually. It is my understanding that we can't assume CONFIG_PM. Why ? What does it take to change this ? Also what would it take to have pattern like this one: ------------------------------------------------------------------------------ int sensor_resume(dev) { } int sensor_suspend(dev) { } int probe() { RESOURCES ACQUISITION (clock/regulators/gpio) if (!is_acpi_node(dev)) sensor_resume(dev) pm_runtime_set_active(); pm_runtime_enable(); -- HW ACCESS -- pm_runtime_set_autosuspend_delay(dev, 1000); pm_runtime_use_autosuspend() pm_runtime_autosuspend(); } SET_PM_RUNTIME_OPS(sensor_suspend, sensor_resume, NULL); ------------------------------------------------------------------------------ Which in my understanding should work on both OF/ACPI and with CONFIG_PM/!CONFIG_PM to be moved to a core helper (assuming it works ofc) ? Would standardize on such a pattern be a good first move or converting existing drivers would be a burden we can't take ? See you all on Monday! Thanks j
