Messages in this thread | | | Date | Sun, 15 Sep 2013 13:47:44 +0100 | From | Mark Brown <> | Subject | Re: [PATCH v2 1/9] i2c: prepare runtime PM support for I2C client devices |
| |
On Sun, Sep 15, 2013 at 09:41:39AM +0300, Mika Westerberg wrote:
> There's also a less intrusive way of fixing the problem we see with ACPI > enabled I2C devices:
> 1. In I2C core i2c_device_probe() we power on the I2C controller > and attach the client device to the ACPI power domain. Just like in > this patch but we don't touch the I2C client device runtime PM.
> -> This should allow the existing drivers to keep using whatever > runtime PM strategy they have chosen.
There should be no explicit need to power on the I2C controller if it's implemented the same way the existing ones are - just have it power itself on when it is doing a transfer.
> 2. For ACPI enumerated I2C client devices drivers we need to > implement the runtime PM in order to save power (otherwise the > devices will be left powered on).
> and do the same for SPI devices as well.
> Then only thing that changes for non-ACPI devices is that the controller > will be powered on during the client device probe (well, and during > remove).
> Thoughts?
This is definitely less intrusive than the current proposal, there's one ACPI I2C device binding queued for -next after the merge window (rt5640) which will need an update. [unhandled content-type:application/pgp-signature] | |