Re: [PATCH v2 1/9] i2c: prepare runtime PM support for I2C client devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux