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.
Attachment:
signature.asc
Description: Digital signature
