On Tue, Sep 17, 2013 at 01:07:37PM +0200, Sylwester Nawrocki wrote:
> On 09/16/2013 10:47 AM, Mika Westerberg wrote:
> > I'm actually thinking that it is probably better now if we don't touch the
> > client runtime PM at all in the I2C core.
> >
> > I proposed a less intrusive solution in this
On Tue, Sep 17, 2013 at 01:07:37PM +0200, Sylwester Nawrocki wrote:
On 09/16/2013 10:47 AM, Mika Westerberg wrote:
I'm actually thinking that it is probably better now if we don't touch the
client runtime PM at all in the I2C core.
I proposed a less intrusive solution in this same thread
On Tuesday, September 17, 2013 02:00:22 PM Mika Westerberg wrote:
> On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
> > On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
> > > On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
> > > > On
On 09/16/2013 10:47 AM, Mika Westerberg wrote:
> I'm actually thinking that it is probably better now if we don't touch the
> client runtime PM at all in the I2C core.
>
> I proposed a less intrusive solution in this same thread where we power the
> I2C controller briefly at the client ->probe()
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
> On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
> > On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
> > > On 09/13/2013 05:40 PM, Mika Westerberg wrote:
> > > [...]
> > > >>>The call to
On Tue, Sep 17, 2013 at 03:25:25AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote:
> > It shouldn't even need to do that, it should just be able to rely on the
> > controller to power itself up when asked to do work. This is how the
> > existing
On Tue, Sep 17, 2013 at 03:25:25AM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote:
It shouldn't even need to do that, it should just be able to rely on the
controller to power itself up when asked to do work. This is how the
existing
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
On 09/13/2013 05:40 PM, Mika Westerberg wrote:
[...]
The call to
On 09/16/2013 10:47 AM, Mika Westerberg wrote:
I'm actually thinking that it is probably better now if we don't touch the
client runtime PM at all in the I2C core.
I proposed a less intrusive solution in this same thread where we power the
I2C controller briefly at the client -probe() (In
On Tuesday, September 17, 2013 02:00:22 PM Mika Westerberg wrote:
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
On 09/13/2013 05:40
On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote:
> On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
>
> > That may be left to the client driver altogether. I mean, if the client
> > wants
> > the controller to be powered up, it should just call
> >
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
> That may be left to the client driver altogether. I mean, if the client wants
> the controller to be powered up, it should just call
> pm_runtime_get_sync(controller device) at a suitable place (and then do the
> corresponding
On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
> On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
> > On 09/13/2013 05:40 PM, Mika Westerberg wrote:
> > [...]
> > >>>The call to pm_runtime_get_noresume() should make sure that the device is
> > >>>in active
On Mon, Sep 16, 2013 at 03:46:16PM +0100, Graeme Gregory wrote:
> On Mon, Sep 16, 2013 at 05:38:12PM +0300, Mika Westerberg wrote:
> > On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
> > > That's definitely an ACPI specific (probably x86 specific ACPI?)
> > > requirement not a generic
On Mon, Sep 16, 2013 at 05:38:12PM +0300, Mika Westerberg wrote:
> On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
> > That's definitely an ACPI specific (probably x86 specific ACPI?)
> > requirement not a generic one, on some systems it would increase power
> > consumption since the
On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
> That's definitely an ACPI specific (probably x86 specific ACPI?)
> requirement not a generic one, on some systems it would increase power
> consumption since the controller will need to sit on while the device is
> functioning
On Sun, Sep 15, 2013 at 04:28:24PM +0300, Mika Westerberg wrote:
> On Sun, Sep 15, 2013 at 01:47:44PM +0100, Mark Brown wrote:
> > On Sun, Sep 15, 2013 at 09:41:39AM +0300, Mika Westerberg wrote:
> > > 1. In I2C core i2c_device_probe() we power on the I2C controller
> > > and attach the
On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
> On 09/13/2013 05:40 PM, Mika Westerberg wrote:
> [...]
> >>>The call to pm_runtime_get_noresume() should make sure that the device is
> >>>in active state (at least in state where it can access the bus) if I'm
> >>>understanding
On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
On 09/13/2013 05:40 PM, Mika Westerberg wrote:
[...]
The call to pm_runtime_get_noresume() should make sure that the device is
in active state (at least in state where it can access the bus) if I'm
understanding this right.
On Sun, Sep 15, 2013 at 04:28:24PM +0300, Mika Westerberg wrote:
On Sun, Sep 15, 2013 at 01:47:44PM +0100, Mark Brown wrote:
On Sun, Sep 15, 2013 at 09:41:39AM +0300, Mika Westerberg wrote:
1. In I2C core i2c_device_probe() we power on the I2C controller
and attach the client device
On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
That's definitely an ACPI specific (probably x86 specific ACPI?)
requirement not a generic one, on some systems it would increase power
consumption since the controller will need to sit on while the device is
functioning autonomously.
On Mon, Sep 16, 2013 at 05:38:12PM +0300, Mika Westerberg wrote:
On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
That's definitely an ACPI specific (probably x86 specific ACPI?)
requirement not a generic one, on some systems it would increase power
consumption since the
On Mon, Sep 16, 2013 at 03:46:16PM +0100, Graeme Gregory wrote:
On Mon, Sep 16, 2013 at 05:38:12PM +0300, Mika Westerberg wrote:
On Mon, Sep 16, 2013 at 11:12:49AM +0100, Mark Brown wrote:
That's definitely an ACPI specific (probably x86 specific ACPI?)
requirement not a generic one, on
On Monday, September 16, 2013 11:47:08 AM Mika Westerberg wrote:
On Sun, Sep 15, 2013 at 03:48:12PM +0200, Sylwester Nawrocki wrote:
On 09/13/2013 05:40 PM, Mika Westerberg wrote:
[...]
The call to pm_runtime_get_noresume() should make sure that the device is
in active state (at least in
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
That may be left to the client driver altogether. I mean, if the client wants
the controller to be powered up, it should just call
pm_runtime_get_sync(controller device) at a suitable place (and then do the
corresponding _put
On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote:
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
That may be left to the client driver altogether. I mean, if the client
wants
the controller to be powered up, it should just call
On 09/13/2013 05:40 PM, Mika Westerberg wrote:
[...]
The call to pm_runtime_get_noresume() should make sure that the device is
in active state (at least in state where it can access the bus) if I'm
understanding this right.
I can't see how this would happen. How runtime_resume/runtime_suspend
On Sun, Sep 15, 2013 at 01:47:44PM +0100, Mark Brown wrote:
> 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
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
On Fri, Sep 13, 2013 at 02:10:43PM -0700, Kevin Hilman wrote:
> >
> > // This makes sure that the controller itself is powered on
> > // (adapter device follows its parent which is the controller). The
> > // controller is attached to the ACPI power domain so it is
> > // brought
On Fri, Sep 13, 2013 at 02:10:43PM -0700, Kevin Hilman wrote:
// This makes sure that the controller itself is powered on
// (adapter device follows its parent which is the controller). The
// controller is attached to the ACPI power domain so it is
// brought to D0 now.
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.
On Sun, Sep 15, 2013 at 01:47:44PM +0100, Mark Brown wrote:
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
On 09/13/2013 05:40 PM, Mika Westerberg wrote:
[...]
The call to pm_runtime_get_noresume() should make sure that the device is
in active state (at least in state where it can access the bus) if I'm
understanding this right.
I can't see how this would happen. How runtime_resume/runtime_suspend
Mika Westerberg writes:
> On Fri, Sep 13, 2013 at 05:50:22PM +0300, Mika Westerberg wrote:
>> On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
>> > Mika Westerberg writes:
>> >
>> > > On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
>> > >> > diff --git
On Fri, Sep 13, 2013 at 05:50:22PM +0300, Mika Westerberg wrote:
> On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
> > Mika Westerberg writes:
> >
> > > On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
> > >> > diff --git a/drivers/i2c/i2c-core.c
On Fri, Sep 13, 2013 at 05:14:56PM +0200, Sylwester Nawrocki wrote:
> On 09/13/2013 08:54 AM, Mika Westerberg wrote:
> > On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
> >>> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >>> > > index f32ca29..44374b4 100644
>
On 09/13/2013 08:54 AM, Mika Westerberg wrote:
> On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
>>> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>>> > > index f32ca29..44374b4 100644
>>> > > --- a/drivers/i2c/i2c-core.c
>>> > > +++ b/drivers/i2c/i2c-core.c
>>> >
Mika Westerberg writes:
> On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
>> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> > index f32ca29..44374b4 100644
>> > --- a/drivers/i2c/i2c-core.c
>> > +++ b/drivers/i2c/i2c-core.c
>> > @@ -248,11 +248,30 @@ static int
On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
> Mika Westerberg writes:
>
> > On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
> >> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >> > index f32ca29..44374b4 100644
> >> > --- a/drivers/i2c/i2c-core.c
On Fri, Sep 13, 2013 at 02:50:35PM +0300, Mika Westerberg wrote:
> On Fri, Sep 13, 2013 at 11:31:52AM +0100, Mark Brown wrote:
> > Right, but this probably needs to be highlighted more since it's a very
> > surprising thing for I2C and is causing confusion.
> By highlighted more, do you mean
On Fri, Sep 13, 2013 at 11:31:52AM +0100, Mark Brown wrote:
> On Fri, Sep 13, 2013 at 01:16:11PM +0300, Mika Westerberg wrote:
> > On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
>
> > > Accessing the bus isn't an issue for I2C outside of ACPI, the power
> > > management of the device
On Fri, Sep 13, 2013 at 01:16:11PM +0300, Mika Westerberg wrote:
> On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
> > Accessing the bus isn't an issue for I2C outside of ACPI, the power
> > management of the device is totally disassociated from the bus and the
> > controller is
On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
> On Fri, Sep 13, 2013 at 09:54:34AM +0300, Mika Westerberg wrote:
> > On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
>
> > > For hardware that is disabled/powered-off on startup, there will now be
> > > a mismatch between
On Fri, Sep 13, 2013 at 09:14:20AM +0800, Aaron Lu wrote:
> On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
> > So there is currently no way to avoid this behaviour, i.e. to have the
> > adapter
> > not activated before any of its client devices is probed, but only later on,
> > after explicit
On Fri, Sep 13, 2013 at 09:54:34AM +0300, Mika Westerberg wrote:
> On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
> > For hardware that is disabled/powered-off on startup, there will now be
> > a mismatch between the hardware state an the RPM core state.
> The call to
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index f32ca29..44374b4 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -248,11 +248,30 @@ static int i2c_device_probe(struct device
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -248,11 +248,30 @@ static int i2c_device_probe(struct device *dev)
On Fri, Sep 13, 2013 at 09:54:34AM +0300, Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
For hardware that is disabled/powered-off on startup, there will now be
a mismatch between the hardware state an the RPM core state.
The call to
On Fri, Sep 13, 2013 at 09:14:20AM +0800, Aaron Lu wrote:
On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
So there is currently no way to avoid this behaviour, i.e. to have the
adapter
not activated before any of its client devices is probed, but only later on,
after explicit call to
On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
On Fri, Sep 13, 2013 at 09:54:34AM +0300, Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
For hardware that is disabled/powered-off on startup, there will now be
a mismatch between the
On Fri, Sep 13, 2013 at 01:16:11PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
Accessing the bus isn't an issue for I2C outside of ACPI, the power
management of the device is totally disassociated from the bus and the
controller is responsible
On Fri, Sep 13, 2013 at 11:31:52AM +0100, Mark Brown wrote:
On Fri, Sep 13, 2013 at 01:16:11PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
Accessing the bus isn't an issue for I2C outside of ACPI, the power
management of the device is
On Fri, Sep 13, 2013 at 02:50:35PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 11:31:52AM +0100, Mark Brown wrote:
Right, but this probably needs to be highlighted more since it's a very
surprising thing for I2C and is causing confusion.
By highlighted more, do you mean something
On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
---
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -248,11 +248,30
On 09/13/2013 08:54 AM, Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -248,11 +248,30 @@
On Fri, Sep 13, 2013 at 05:14:56PM +0200, Sylwester Nawrocki wrote:
On 09/13/2013 08:54 AM, Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index f32ca29..44374b4 100644
---
On Fri, Sep 13, 2013 at 05:50:22PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
diff --git a/drivers/i2c/i2c-core.c
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Fri, Sep 13, 2013 at 05:50:22PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 07:30:55AM -0700, Kevin Hilman wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin
On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
> On 09/11/2013 05:32 PM, Mika Westerberg wrote:
>> From: Aaron Lu
>>
>> This patch adds runtime PM support for the I2C bus in a similar way that
>> has been done for PCI bus already. This means that the I2C bus core
>> prepares runtime PM for a
On 09/11/2013 05:32 PM, Mika Westerberg wrote:
From: Aaron Lu
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver is about to be
bound to it.
On Thu, Sep 12, 2013 at 2:34 PM, Kevin Hilman wrote:
> Mika Westerberg writes:
>
>> From: Aaron Lu
>>
>> This patch adds runtime PM support for the I2C bus in a similar way that
>> has been done for PCI bus already. This means that the I2C bus core
>> prepares runtime PM for a client device
Mika Westerberg writes:
> From: Aaron Lu
>
> This patch adds runtime PM support for the I2C bus in a similar way that
> has been done for PCI bus already. This means that the I2C bus core
> prepares runtime PM for a client device just before a driver is about to be
> bound to it. Devices that
Mika Westerberg mika.westerb...@linux.intel.com writes:
From: Aaron Lu aaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver
On Thu, Sep 12, 2013 at 2:34 PM, Kevin Hilman khil...@linaro.org wrote:
Mika Westerberg mika.westerb...@linux.intel.com writes:
From: Aaron Lu aaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the
On 09/11/2013 05:32 PM, Mika Westerberg wrote:
From: Aaron Luaaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver is about to
On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
On 09/11/2013 05:32 PM, Mika Westerberg wrote:
From: Aaron Luaaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM
From: Aaron Lu
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver is about to be
bound to it. Devices that are not bound to any driver are not
From: Aaron Lu aaron...@intel.com
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver is about to be
bound to it. Devices that are not bound to any
70 matches
Mail list logo
