On Mon, Feb 13, 2012 at 11:31:39PM +, Ben Dooks wrote:
> On Sun, Jan 22, 2012 at 09:39:53PM +, Mark Brown wrote:
> > TBH I think most of the devices for which people are running these days
> > will be able to get some win from the system wide stuff - the WFI modes
> > aren't exactly the la
On Sun, Jan 22, 2012 at 09:39:53PM +, Mark Brown wrote:
> On Sun, Jan 22, 2012 at 06:48:36PM +0100, Sylwester Nawrocki wrote:
> > On 01/22/2012 06:27 PM, Bill Gatliff wrote:
>
> > > I for one would rather see in-kernel drivers that require it, and then
>
> > In fact we have to deal with the o
On 01/22/2012 10:39 PM, Mark Brown wrote:
> On Sun, Jan 22, 2012 at 06:48:36PM +0100, Sylwester Nawrocki wrote:
>> On 01/22/2012 06:27 PM, Bill Gatliff wrote:
>
>>> I for one would rather see in-kernel drivers that require it, and then
>
>> In fact we have to deal with the opposite now, as some e
On Sun, Jan 22, 2012 at 06:48:36PM +0100, Sylwester Nawrocki wrote:
> On 01/22/2012 06:27 PM, Bill Gatliff wrote:
> > I for one would rather see in-kernel drivers that require it, and then
> In fact we have to deal with the opposite now, as some existing drivers
> have been used for multiple gene
Hi,
On 01/22/2012 06:27 PM, Bill Gatliff wrote:
> On Sun, Jan 22, 2012 at 6:22 PM, Sylwester Nawrocki
> wrote:
>> The best solution would be to force platform to enable PM_RUNTIME if
>> they want to use a driver which does runtime PM. But this has to wait,
>> yet, probably infinitely.. :)
>
>
Guys:
On Sun, Jan 22, 2012 at 6:22 PM, Sylwester Nawrocki
wrote:
> The best solution would be to force platform to enable PM_RUNTIME if they
> want to
> use a driver which does runtime PM. But this has to wait, yet, probably
> infinitely.. :)
Probably easier to motivate platforms to enable PM_R
On 01/22/2012 04:22 PM, Mark Brown wrote:
> On Sun, Jan 22, 2012 at 01:59:25PM +0100, Sylwester Nawrocki wrote:
>> How about the following patch (untested) ? It might be a better start for
>> proper power management implementation and would still allow the driver
>> to work on platforms that don't
On Sun, Jan 22, 2012 at 01:59:25PM +0100, Sylwester Nawrocki wrote:
> On 01/21/2012 07:46 PM, Mark Brown wrote:
> > + pm_runtime_get_sync(&adap->dev);
> IMHO it's more appropriate to use i2c->dev here instead, i.e. to reference
> the platform device we've enabled runtime PM for.
Oh, bah humbug
On 01/21/2012 07:46 PM, Mark Brown wrote:
> Add stub runtime_pm calls which go through the flow of enabling and
> disabling but don't actually do anything with the device itself as
> there's nothing useful we can do. This provides the core PM framework
> with information about when the device is id
On Sat, Jan 21, 2012 at 10:25:20PM +0100, Sylwester Nawrocki wrote:
> On 01/21/2012 07:46 PM, Mark Brown wrote:
> > Add stub runtime_pm calls which go through the flow of enabling and
> > disabling but don't actually do anything with the device itself as
> > there's nothing useful we can do. This p
On 01/21/2012 07:46 PM, Mark Brown wrote:
> Add stub runtime_pm calls which go through the flow of enabling and
> disabling but don't actually do anything with the device itself as
> there's nothing useful we can do. This provides the core PM framework
> with information about when the device is id
Add stub runtime_pm calls which go through the flow of enabling and
disabling but don't actually do anything with the device itself as
there's nothing useful we can do. This provides the core PM framework
with information about when the device is idle, enabling chip wide
power savings.
Signed-off-
12 matches
Mail list logo
