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

Reply via email to