The call to pm_runtime_get_noresume() should make sure that the device is
in active state (at least in state where it can access the bus) if I'm
understanding this right.
I can't see how this would happen. How runtime_resume/runtime_suspend
callbacks would get invoked with this code, if, e.g. originally driver called
pm_runtime_enable(), pm_runtime_get_sync(), pm_runtime_put_sync() in probe() ?
The driver callbacks are not called but if the device has been attached to
a power domain (like we do with ACPI) the power domain callbacks get called
and it brings the "bus" to such state that we are able to access the
device. That also was the reason I used _noresume() but didn't look too
close the implementation.
pm_runtime_get_noresume() merely increments usage counter of a device.
It seems that these changes will break the s5p-tv driver. I might be missing
something though.
You are right and Kevin also mentioned this. It should be pm_runtime_get(),
if I'm not mistaken.
As Mark pointed out this is currently unwanted behaviour to runtime PM
activate a bus controller device manually in the core for when the client's
probe() is executed, since i2c core will activate the bus controller for when
transfer is being carried out.
But I can understand this is needed for ACPI and it shouldn't break existing
drivers, that do runtime PM activate the client device in probe().
Indeed, we don't want to break anything (and we still need something like
this for ACPI).
Now I'm sure this will break power management of the drivers/media/exynos4-is
driver, due to incorrect power sequence (power domain and clocks handling).
I'll try to take care of it in separate patch, as I have some patches pending,
that move most of code from drivers/media/exynos4-is/fimc-is-sensor.c to
drivers/media/i2c/s5k6a3.c.
I missed that code when I converted existing users to this method. Sorry
about that (I can handle that in the next version).
I quickly looked at it and I don't see anything that could break (once
converted). What it does is this:
pm_runtime_no_callbacks(dev);
pm_runtime_enable(dev);
changing that to:
pm_runtime_no_callbacks(dev);
pm_runtime_put(dev);
shouldn't cause problems AFAICT.