[PATCH/RFC] platform_bus: Allow runtime PM by default

[PATCH/RFC] platform_bus: Allow runtime PM by default

[Mark Brown]

Currently the default runtime PM callbacks for platform devices return
-ENOSYS, preventing the use of runtime PM platforms until they have
provided at least a default implementation. This hinders the use of
runtime PM by devices which work with many platforms such as memory
mapped devices, MFDs and on chip IPs shared by multiple architectures.

Change the default implementation to the standard pm_generic_runtime
one, allowing drivers to use runtime PM without per-architecture
changes.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---

I'm not 100% sure why the curret implementation returns -ENOSYS - I've
got a horrible feeling I might be breaking something somewhere.

 drivers/base/platform.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 43479a9..eb0f8d9 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -967,17 +967,17 @@ static int platform_pm_restore_noirq(struct device *dev)
 
 int __weak platform_pm_runtime_suspend(struct device *dev)
 {
-	return -ENOSYS;
+	return pm_generic_runtime_suspend(dev);
 };
 
 int __weak platform_pm_runtime_resume(struct device *dev)
 {
-	return -ENOSYS;
+	return pm_generic_runtime_resume(dev);
 };
 
 int __weak platform_pm_runtime_idle(struct device *dev)
 {
-	return -ENOSYS;
+	return pm_generic_runtime_idle(dev);
 };
 
 #else /* !CONFIG_PM_RUNTIME */
-- 
1.7.0.2

Re: [PATCH/RFC] platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Friday 26 March 2010, Mark Brown wrote:
> Currently the default runtime PM callbacks for platform devices return
> -ENOSYS, preventing the use of runtime PM platforms until they have
> provided at least a default implementation. This hinders the use of
> runtime PM by devices which work with many platforms such as memory
> mapped devices, MFDs and on chip IPs shared by multiple architectures.
> 
> Change the default implementation to the standard pm_generic_runtime
> one, allowing drivers to use runtime PM without per-architecture
> changes.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Acked-by: Rafael J. Wysocki <rjw@sisk.pl>

Is it very urgent?

Rafael


> ---
> 
> I'm not 100% sure why the curret implementation returns -ENOSYS - I've
> got a horrible feeling I might be breaking something somewhere.
> 
>  drivers/base/platform.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 43479a9..eb0f8d9 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -967,17 +967,17 @@ static int platform_pm_restore_noirq(struct device *dev)
>  
>  int __weak platform_pm_runtime_suspend(struct device *dev)
>  {
> -	return -ENOSYS;
> +	return pm_generic_runtime_suspend(dev);
>  };
>  
>  int __weak platform_pm_runtime_resume(struct device *dev)
>  {
> -	return -ENOSYS;
> +	return pm_generic_runtime_resume(dev);
>  };
>  
>  int __weak platform_pm_runtime_idle(struct device *dev)
>  {
> -	return -ENOSYS;
> +	return pm_generic_runtime_idle(dev);
>  };
>  
>  #else /* !CONFIG_PM_RUNTIME */
> 

Re: [PATCH/RFC] platform_bus: Allow runtime PM by default

[Mark Brown]

On 26 Mar 2010, at 22:35, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Friday 26 March 2010, Mark Brown wrote:
>> Currently the default runtime PM callbacks for platform devices  
>> return
>> -ENOSYS, preventing the use of runtime PM platforms until they have
>> provided at least a default implementation. This hinders the use of
>> runtime PM by devices which work with many platforms such as memory
>> mapped devices, MFDs and on chip IPs shared by multiple  
>> architectures.
>>
>> Change the default implementation to the standard pm_generic_runtime
>> one, allowing drivers to use runtime PM without per-architecture
>> changes.
>>
>> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
>
> Is it very urgent?

Not especially - worst case you just don't get devices suspending  
which isn't the end of the world and there's no build time  
dependencies introduced.

>
> Rafael
>
>
>> ---
>>
>> I'm not 100% sure why the curret implementation returns -ENOSYS -  
>> I've
>> got a horrible feeling I might be breaking something somewhere.
>>
>> drivers/base/platform.c |    6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index 43479a9..eb0f8d9 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -967,17 +967,17 @@ static int platform_pm_restore_noirq(struct  
>> device *dev)
>>
>> int __weak platform_pm_runtime_suspend(struct device *dev)
>> {
>> -    return -ENOSYS;
>> +    return pm_generic_runtime_suspend(dev);
>> };
>>
>> int __weak platform_pm_runtime_resume(struct device *dev)
>> {
>> -    return -ENOSYS;
>> +    return pm_generic_runtime_resume(dev);
>> };
>>
>> int __weak platform_pm_runtime_idle(struct device *dev)
>> {
>> -    return -ENOSYS;
>> +    return pm_generic_runtime_idle(dev);
>> };
>>
>> #else /* !CONFIG_PM_RUNTIME */
>>
>

Re: [PATCH/RFC] platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Saturday 27 March 2010, Mark Brown wrote:
> On 26 Mar 2010, at 22:35, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > On Friday 26 March 2010, Mark Brown wrote:
> >> Currently the default runtime PM callbacks for platform devices  
> >> return
> >> -ENOSYS, preventing the use of runtime PM platforms until they have
> >> provided at least a default implementation. This hinders the use of
> >> runtime PM by devices which work with many platforms such as memory
> >> mapped devices, MFDs and on chip IPs shared by multiple  
> >> architectures.
> >>
> >> Change the default implementation to the standard pm_generic_runtime
> >> one, allowing drivers to use runtime PM without per-architecture
> >> changes.
> >>
> >> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> >
> > Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > Is it very urgent?
> 
> Not especially - worst case you just don't get devices suspending  
> which isn't the end of the world and there's no build time  
> dependencies introduced.

OK, so I guess it will be sufficient if Greg queues it for .35.

Rafael

Re: platform_bus: Allow runtime PM by default

[Greg KH]

On Fri, Mar 26, 2010 at 05:42:50PM +0000, Mark Brown wrote:
> 
> Currently the default runtime PM callbacks for platform devices return
> -ENOSYS, preventing the use of runtime PM platforms until they have
> provided at least a default implementation. This hinders the use of
> runtime PM by devices which work with many platforms such as memory
> mapped devices, MFDs and on chip IPs shared by multiple architectures.
> 
> Change the default implementation to the standard pm_generic_runtime
> one, allowing drivers to use runtime PM without per-architecture
> changes.

That's nice, but it breaks the build on my system:
  CC      drivers/base/platform.o
drivers/base/platform.c: In function ‘platform_pm_runtime_suspend’:
drivers/base/platform.c:970: error: implicit declaration of function ‘pm_generic_runtime_suspend’
drivers/base/platform.c: In function ‘platform_pm_runtime_resume’:
drivers/base/platform.c:975: error: implicit declaration of function ‘pm_generic_runtime_resume’
drivers/base/platform.c: In function ‘platform_pm_runtime_idle’:
drivers/base/platform.c:980: error: implicit declaration of function ‘pm_generic_runtime_idle’
make[1]: *** [drivers/base/platform.o] Error 1
make: *** [_module_drivers/base] Error 2

Care to fix it up?

thanks,

greg k-h

Re: platform_bus: Allow runtime PM by default

[Mark Brown]

On Thu, Apr 22, 2010 at 04:53:53PM -0700, Greg KH wrote:
> On Fri, Mar 26, 2010 at 05:42:50PM +0000, Mark Brown wrote:

> > Change the default implementation to the standard pm_generic_runtime
> > one, allowing drivers to use runtime PM without per-architecture
> > changes.

> That's nice, but it breaks the build on my system:
>   CC      drivers/base/platform.o
> drivers/base/platform.c: In function ‘platform_pm_runtime_suspend’:
> drivers/base/platform.c:970: error: implicit declaration of function ‘pm_generic_runtime_suspend’
> drivers/base/platform.c: In function ‘platform_pm_runtime_resume’:
> drivers/base/platform.c:975: error: implicit declaration of function ‘pm_generic_runtime_resume’
> drivers/base/platform.c: In function ‘platform_pm_runtime_idle’:
> drivers/base/platform.c:980: error: implicit declaration of function ‘pm_generic_runtime_idle’
> make[1]: *** [drivers/base/platform.o] Error 1
> make: *** [_module_drivers/base] Error 2

> Care to fix it up?

This depends on "PM: Provide generic subsystem-level callbacks" which is
in Linus' tree - which kernel version are you building against and with
what config?  Things work fine for me in -next...

Re: platform_bus: Allow runtime PM by default

[Greg KH]

On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2010 at 04:53:53PM -0700, Greg KH wrote:
> > On Fri, Mar 26, 2010 at 05:42:50PM +0000, Mark Brown wrote:
> 
> > > Change the default implementation to the standard pm_generic_runtime
> > > one, allowing drivers to use runtime PM without per-architecture
> > > changes.
> 
> > That's nice, but it breaks the build on my system:
> >   CC      drivers/base/platform.o
> > drivers/base/platform.c: In function ???platform_pm_runtime_suspend???:
> > drivers/base/platform.c:970: error: implicit declaration of function ???pm_generic_runtime_suspend???
> > drivers/base/platform.c: In function ???platform_pm_runtime_resume???:
> > drivers/base/platform.c:975: error: implicit declaration of function ???pm_generic_runtime_resume???
> > drivers/base/platform.c: In function ???platform_pm_runtime_idle???:
> > drivers/base/platform.c:980: error: implicit declaration of function ???pm_generic_runtime_idle???
> > make[1]: *** [drivers/base/platform.o] Error 1
> > make: *** [_module_drivers/base] Error 2
> 
> > Care to fix it up?
> 
> This depends on "PM: Provide generic subsystem-level callbacks" which is
> in Linus' tree - which kernel version are you building against and with
> what config?  Things work fine for me in -next...

I was using Linus's latest tree as of yesterday when this failed.  Are
you relying on something in -next that is not in Linus's tree?

thanks,

greg k-h

Re: platform_bus: Allow runtime PM by default

[Mark Brown]

On Fri, Apr 23, 2010 at 08:05:28AM -0700, Greg KH wrote:
> On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:

> > This depends on "PM: Provide generic subsystem-level callbacks" which is
> > in Linus' tree - which kernel version are you building against and with
> > what config?  Things work fine for me in -next...

> I was using Linus's latest tree as of yesterday when this failed.  Are
> you relying on something in -next that is not in Linus's tree?

Not intentionally - it's also possible that it's specific to some option
in .config, either an option or something that gets included by default
due to the arch.

Re: platform_bus: Allow runtime PM by default

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Fri, Apr 23, 2010 at 04:13:27PM +0100, Mark Brown wrote:
> On Fri, Apr 23, 2010 at 08:05:28AM -0700, Greg KH wrote:
> > On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:
> 
> > > This depends on "PM: Provide generic subsystem-level callbacks" which is
> > > in Linus' tree - which kernel version are you building against and with
> > > what config?  Things work fine for me in -next...
> 
> > I was using Linus's latest tree as of yesterday when this failed.  Are
> > you relying on something in -next that is not in Linus's tree?
> 
> Not intentionally - it's also possible that it's specific to some option
> in .config, either an option or something that gets included by default
> due to the arch.

x86-64 is a pretty common arch :)

Attached is my .config file.

thanks,

greg k-h

[-- Attachment #2: .config --]
[-- Type: application/x-config, Size: 82256 bytes --]

Re: platform_bus: Allow runtime PM by default

[Mark Brown]

On Fri, Apr 23, 2010 at 08:05:28AM -0700, Greg KH wrote:
> On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:

> > > Care to fix it up?

> > This depends on "PM: Provide generic subsystem-level callbacks" which is
> > in Linus' tree - which kernel version are you building against and with
> > what config?  Things work fine for me in -next...

> I was using Linus's latest tree as of yesterday when this failed.  Are
> you relying on something in -next that is not in Linus's tree?

Turns out it's commit ad53012 "i2c: Fix bus-level power management
callbacks" in the PM tree that it depends on.  Does it make sense to
merge this via there rather than via your tree?

Re: platform_bus: Allow runtime PM by default

[Greg KH]

On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:
> On Fri, Apr 23, 2010 at 08:05:28AM -0700, Greg KH wrote:
> > On Fri, Apr 23, 2010 at 11:57:51AM +0100, Mark Brown wrote:
> 
> > > > Care to fix it up?
> 
> > > This depends on "PM: Provide generic subsystem-level callbacks" which is
> > > in Linus' tree - which kernel version are you building against and with
> > > what config?  Things work fine for me in -next...
> 
> > I was using Linus's latest tree as of yesterday when this failed.  Are
> > you relying on something in -next that is not in Linus's tree?
> 
> Turns out it's commit ad53012 "i2c: Fix bus-level power management
> callbacks" in the PM tree that it depends on.  Does it make sense to
> merge this via there rather than via your tree?

Why would an i2c specific patch be needed here?  Do you have a pointer
to that patch?

And yes, if it depends on something else in the PM tree, feel free to
send this patch also through it, I have no objection to that.  Rafael,
care to pick it up?  Mark, you might have to resend it to him.

thanks,

greg k-h

Re: platform_bus: Allow runtime PM by default

[Mark Brown]

On Fri, Apr 23, 2010 at 09:11:57AM -0700, Greg KH wrote:
> On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:

> > Turns out it's commit ad53012 "i2c: Fix bus-level power management
> > callbacks" in the PM tree that it depends on.  Does it make sense to
> > merge this via there rather than via your tree?

> Why would an i2c specific patch be needed here?  Do you have a pointer
> to that patch?

Despite the patch title being I2C specific it actually includes exposing
some of the runtime PM implementation to external users - I2C being the
first user of the generic PM runtime callbacks that I'm trying to use in
the platform device implementation.

http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=ad530128cd302e5df930b6eb4d4c7e162c40fcb2;hp=b938b00444e900f1c86e754539e3d00f172c184e
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d690b2cd222afc75320b9b8e9da7df02e9e630ca

> And yes, if it depends on something else in the PM tree, feel free to
> send this patch also through it, I have no objection to that.  Rafael,
> care to pick it up?  Mark, you might have to resend it to him.

OK, Raphael please let me know if you need a resend.  Greg, I guess I
can add your Acked-by to that?

Re: platform_bus: Allow runtime PM by default

[Greg KH]

On Fri, Apr 23, 2010 at 05:28:12PM +0100, Mark Brown wrote:
> On Fri, Apr 23, 2010 at 09:11:57AM -0700, Greg KH wrote:
> > On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:
> 
> > > Turns out it's commit ad53012 "i2c: Fix bus-level power management
> > > callbacks" in the PM tree that it depends on.  Does it make sense to
> > > merge this via there rather than via your tree?
> 
> > Why would an i2c specific patch be needed here?  Do you have a pointer
> > to that patch?
> 
> Despite the patch title being I2C specific it actually includes exposing
> some of the runtime PM implementation to external users - I2C being the
> first user of the generic PM runtime callbacks that I'm trying to use in
> the platform device implementation.
> 
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=ad530128cd302e5df930b6eb4d4c7e162c40fcb2;hp=b938b00444e900f1c86e754539e3d00f172c184e
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d690b2cd222afc75320b9b8e9da7df02e9e630ca
> 
> > And yes, if it depends on something else in the PM tree, feel free to
> > send this patch also through it, I have no objection to that.  Rafael,
> > care to pick it up?  Mark, you might have to resend it to him.
> 
> OK, Raphael please let me know if you need a resend.  Greg, I guess I
> can add your Acked-by to that?

Yes, please feel free to add it.

thanks,

greg k-h

Re: platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Friday 23 April 2010, Mark Brown wrote:
> On Fri, Apr 23, 2010 at 09:11:57AM -0700, Greg KH wrote:
> > On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:
> 
> > > Turns out it's commit ad53012 "i2c: Fix bus-level power management
> > > callbacks" in the PM tree that it depends on.  Does it make sense to
> > > merge this via there rather than via your tree?
> 
> > Why would an i2c specific patch be needed here?  Do you have a pointer
> > to that patch?
> 
> Despite the patch title being I2C specific it actually includes exposing
> some of the runtime PM implementation to external users - I2C being the
> first user of the generic PM runtime callbacks that I'm trying to use in
> the platform device implementation.
> 
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=ad530128cd302e5df930b6eb4d4c7e162c40fcb2;hp=b938b00444e900f1c86e754539e3d00f172c184e
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d690b2cd222afc75320b9b8e9da7df02e9e630ca
> 
> > And yes, if it depends on something else in the PM tree, feel free to
> > send this patch also through it, I have no objection to that.  Rafael,
> > care to pick it up?  Mark, you might have to resend it to him.
> 
> OK, Raphael please let me know if you need a resend.

No, thanks, I have your original post.

Rafael

Re: platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Friday 23 April 2010, Rafael J. Wysocki wrote:
> On Friday 23 April 2010, Mark Brown wrote:
> > On Fri, Apr 23, 2010 at 09:11:57AM -0700, Greg KH wrote:
> > > On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:
> > 
> > > > Turns out it's commit ad53012 "i2c: Fix bus-level power management
> > > > callbacks" in the PM tree that it depends on.  Does it make sense to
> > > > merge this via there rather than via your tree?
> > 
> > > Why would an i2c specific patch be needed here?  Do you have a pointer
> > > to that patch?
> > 
> > Despite the patch title being I2C specific it actually includes exposing
> > some of the runtime PM implementation to external users - I2C being the
> > first user of the generic PM runtime callbacks that I'm trying to use in
> > the platform device implementation.
> > 
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=ad530128cd302e5df930b6eb4d4c7e162c40fcb2;hp=b938b00444e900f1c86e754539e3d00f172c184e
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d690b2cd222afc75320b9b8e9da7df02e9e630ca
> > 
> > > And yes, if it depends on something else in the PM tree, feel free to
> > > send this patch also through it, I have no objection to that.  Rafael,
> > > care to pick it up?  Mark, you might have to resend it to him.
> > 
> > OK, Raphael please let me know if you need a resend.
> 
> No, thanks, I have your original post.

Now applied to suspend-2.6/linux-next .

Thanks,
Rafael

Re: platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Friday 23 April 2010, Rafael J. Wysocki wrote:
> On Friday 23 April 2010, Rafael J. Wysocki wrote:
> > On Friday 23 April 2010, Mark Brown wrote:
> > > On Fri, Apr 23, 2010 at 09:11:57AM -0700, Greg KH wrote:
> > > > On Fri, Apr 23, 2010 at 04:57:21PM +0100, Mark Brown wrote:
> > > 
> > > > > Turns out it's commit ad53012 "i2c: Fix bus-level power management
> > > > > callbacks" in the PM tree that it depends on.  Does it make sense to
> > > > > merge this via there rather than via your tree?
> > > 
> > > > Why would an i2c specific patch be needed here?  Do you have a pointer
> > > > to that patch?
> > > 
> > > Despite the patch title being I2C specific it actually includes exposing
> > > some of the runtime PM implementation to external users - I2C being the
> > > first user of the generic PM runtime callbacks that I'm trying to use in
> > > the platform device implementation.
> > > 
> > > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=ad530128cd302e5df930b6eb4d4c7e162c40fcb2;hp=b938b00444e900f1c86e754539e3d00f172c184e
> > > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=d690b2cd222afc75320b9b8e9da7df02e9e630ca
> > > 
> > > > And yes, if it depends on something else in the PM tree, feel free to
> > > > send this patch also through it, I have no objection to that.  Rafael,
> > > > care to pick it up?  Mark, you might have to resend it to him.
> > > 
> > > OK, Raphael please let me know if you need a resend.
> > 
> > No, thanks, I have your original post.
> 
> Now applied to suspend-2.6/linux-next .

Reverted, sorry.

The i2c patch is not in my tree, it's in the i2c tree.
Perhaps I can handle the both of them.

Jean, the patch we're discussing depends on the
"i2c: Fix bus-level power management callbacks" patch that's in your tree right
now.  Would it be possible to move the i2c patch to my tree, or alternatively
would it be acceptable for you to merge a core PM patch through your tree?

Rafael

Re: platform_bus: Allow runtime PM by default

[Mark Brown]

On Fri, Apr 23, 2010 at 08:41:41PM +0200, Rafael J. Wysocki wrote:

> Jean, the patch we're discussing depends on the
> "i2c: Fix bus-level power management callbacks" patch that's in your tree right
> now.  Would it be possible to move the i2c patch to my tree, or alternatively
> would it be acceptable for you to merge a core PM patch through your tree?

Jean, any updates on this?

Re: platform_bus: Allow runtime PM by default

[Jean Delvare]

Hi Mark,

On Fri, 7 May 2010 14:27:46 +0100, Mark Brown wrote:
> On Fri, Apr 23, 2010 at 08:41:41PM +0200, Rafael J. Wysocki wrote:
> 
> > Jean, the patch we're discussing depends on the
> > "i2c: Fix bus-level power management callbacks" patch that's in your tree right
> > now.  Would it be possible to move the i2c patch to my tree, or alternatively
> > would it be acceptable for you to merge a core PM patch through your tree?
> 
> Jean, any updates on this?

I'm sorry, I never received Rafael's initial message. I just checked
through my mailbox and it isn't there.

The current status is that patch "i2c: Fix bus-level power management
callbacks" is currently queued in my i2c tree at:
ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-fix-bus-level-power-management-callbacks.patch
and is scheduled to be merged in 2.6.35-rc1. If this isn't OK, we can
change the plan.

Merging a core PM patch through the i2c tree would be quite confusing,
I think, and might draw even more odd dependencies. So I'd rather have
the i2c patch moved to the PM staging tree (or whatever tree the
dependent patch lives in.) Just let me know and I'll drop my copy.

-- 
Jean Delvare

Re: platform_bus: Allow runtime PM by default

[Rafael J. Wysocki]

On Friday 07 May 2010, Jean Delvare wrote:
> Hi Mark,
> 
> On Fri, 7 May 2010 14:27:46 +0100, Mark Brown wrote:
> > On Fri, Apr 23, 2010 at 08:41:41PM +0200, Rafael J. Wysocki wrote:
> > 
> > > Jean, the patch we're discussing depends on the
> > > "i2c: Fix bus-level power management callbacks" patch that's in your tree right
> > > now.  Would it be possible to move the i2c patch to my tree, or alternatively
> > > would it be acceptable for you to merge a core PM patch through your tree?
> > 
> > Jean, any updates on this?
> 
> I'm sorry, I never received Rafael's initial message. I just checked
> through my mailbox and it isn't there.
> 
> The current status is that patch "i2c: Fix bus-level power management
> callbacks" is currently queued in my i2c tree at:
> ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-fix-bus-level-power-management-callbacks.patch
> and is scheduled to be merged in 2.6.35-rc1. If this isn't OK, we can
> change the plan.
> 
> Merging a core PM patch through the i2c tree would be quite confusing,
> I think, and might draw even more odd dependencies. So I'd rather have
> the i2c patch moved to the PM staging tree (or whatever tree the
> dependent patch lives in.) Just let me know and I'll drop my copy.

The patch above has been applied to suspend-2.6/linux-next along with the
Mark's $subject patch.

I have converted your sign-off into an ack, hope that's fine.

Thanks,
Rafael

Re: platform_bus: Allow runtime PM by default

[Jean Delvare]

On Mon, 10 May 2010 23:10:55 +0200, Rafael J. Wysocki wrote:
> On Friday 07 May 2010, Jean Delvare wrote:
> > I'm sorry, I never received Rafael's initial message. I just checked
> > through my mailbox and it isn't there.
> > 
> > The current status is that patch "i2c: Fix bus-level power management
> > callbacks" is currently queued in my i2c tree at:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/i2c-fix-bus-level-power-management-callbacks.patch
> > and is scheduled to be merged in 2.6.35-rc1. If this isn't OK, we can
> > change the plan.
> > 
> > Merging a core PM patch through the i2c tree would be quite confusing,
> > I think, and might draw even more odd dependencies. So I'd rather have
> > the i2c patch moved to the PM staging tree (or whatever tree the
> > dependent patch lives in.) Just let me know and I'll drop my copy.
> 
> The patch above has been applied to suspend-2.6/linux-next along with the
> Mark's $subject patch.

OK, I've dropped it from my i2c tree.

> I have converted your sign-off into an ack, hope that's fine.

Perfectly fine, yes, thanks.

-- 
Jean Delvare

Re: [linux-pm] platform_bus: Allow runtime PM by default

[Mark Brown]

On Tue, May 11, 2010 at 08:19:00AM +0200, Jean Delvare wrote:
> On Mon, 10 May 2010 23:10:55 +0200, Rafael J. Wysocki wrote:

> > The patch above has been applied to suspend-2.6/linux-next along with the
> > Mark's $subject patch.

> OK, I've dropped it from my i2c tree.

> > I have converted your sign-off into an ack, hope that's fine.

> Perfectly fine, yes, thanks.

Thanks to both of you for sorting this out!