All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
To: Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support
Date: Fri, 13 Apr 2012 11:54:21 +0200	[thread overview]
Message-ID: <4F87F7CD.4000004@stericsson.com> (raw)
In-Reply-To: <20120413091828.GJ3168-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>

On 04/13/2012 11:18 AM, Mark Brown wrote:
> On Fri, Apr 13, 2012 at 11:03:56AM +0200, Ulf Hansson wrote:
>
>> But, how should those amba drivers that implements runtime PM
>> support be able to switch of the vcore regulator during normal
>> suspend? In normal suspend case we can not use
>
> A generic AMBA driver should have no idea about the implementation of
> the particular SoC that it's integrated on to.  This applies even more
> to system suspend (where drivers can generally just assume that they
> will loose all power normally) than it does to runtime suspend.
>
>> pm_runtime_put/pm_runtime_put_sync to trigger the power domain
>> runtime functions to switch of vcore. This is kind of more generic
>> problem when dealing with power domains, but as said this patch will
>> have consequences.
>
> The power domain gets callbacks on the system suspend path too and can
> do whatever is sensible there.
>
>> As far as I can see, the power domain must then implement a
>> suspend_noirq function to make sure same things is done as for the
>> runtime_suspend function. Do you agree with this as well or is there
>> another option?
>
> Yes, the power domain should just be handling this transparently.

Alright, thanks for your confirmation. Let's see how this works out then.

Kind regards
Ulf Hansson

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

WARNING: multiple messages have this Message-ID (diff)
From: ulf.hansson@stericsson.com (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support
Date: Fri, 13 Apr 2012 11:54:21 +0200	[thread overview]
Message-ID: <4F87F7CD.4000004@stericsson.com> (raw)
In-Reply-To: <20120413091828.GJ3168@opensource.wolfsonmicro.com>

On 04/13/2012 11:18 AM, Mark Brown wrote:
> On Fri, Apr 13, 2012 at 11:03:56AM +0200, Ulf Hansson wrote:
>
>> But, how should those amba drivers that implements runtime PM
>> support be able to switch of the vcore regulator during normal
>> suspend? In normal suspend case we can not use
>
> A generic AMBA driver should have no idea about the implementation of
> the particular SoC that it's integrated on to.  This applies even more
> to system suspend (where drivers can generally just assume that they
> will loose all power normally) than it does to runtime suspend.
>
>> pm_runtime_put/pm_runtime_put_sync to trigger the power domain
>> runtime functions to switch of vcore. This is kind of more generic
>> problem when dealing with power domains, but as said this patch will
>> have consequences.
>
> The power domain gets callbacks on the system suspend path too and can
> do whatever is sensible there.
>
>> As far as I can see, the power domain must then implement a
>> suspend_noirq function to make sure same things is done as for the
>> runtime_suspend function. Do you agree with this as well or is there
>> another option?
>
> Yes, the power domain should just be handling this transparently.

Alright, thanks for your confirmation. Let's see how this works out then.

Kind regards
Ulf Hansson

WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Russell King <linux@arm.linux.org.uk>,
	Grant Likely <grant.likely@secretlab.ca>,
	Linus Walleij <linus.walleij@linaro.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	"spi-devel-general@lists.sourceforge.net" 
	<spi-devel-general@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support
Date: Fri, 13 Apr 2012 11:54:21 +0200	[thread overview]
Message-ID: <4F87F7CD.4000004@stericsson.com> (raw)
In-Reply-To: <20120413091828.GJ3168@opensource.wolfsonmicro.com>

On 04/13/2012 11:18 AM, Mark Brown wrote:
> On Fri, Apr 13, 2012 at 11:03:56AM +0200, Ulf Hansson wrote:
>
>> But, how should those amba drivers that implements runtime PM
>> support be able to switch of the vcore regulator during normal
>> suspend? In normal suspend case we can not use
>
> A generic AMBA driver should have no idea about the implementation of
> the particular SoC that it's integrated on to.  This applies even more
> to system suspend (where drivers can generally just assume that they
> will loose all power normally) than it does to runtime suspend.
>
>> pm_runtime_put/pm_runtime_put_sync to trigger the power domain
>> runtime functions to switch of vcore. This is kind of more generic
>> problem when dealing with power domains, but as said this patch will
>> have consequences.
>
> The power domain gets callbacks on the system suspend path too and can
> do whatever is sensible there.
>
>> As far as I can see, the power domain must then implement a
>> suspend_noirq function to make sure same things is done as for the
>> runtime_suspend function. Do you agree with this as well or is there
>> another option?
>
> Yes, the power domain should just be handling this transparently.

Alright, thanks for your confirmation. Let's see how this works out then.

Kind regards
Ulf Hansson

  parent reply	other threads:[~2012-04-13  9:54 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-01 18:58 [PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support Mark Brown
2012-04-01 18:58 ` Mark Brown
2012-04-06  7:49 ` Shawn Guo
2012-04-06  7:49   ` Shawn Guo
     [not found]   ` <20120406074942.GO7264-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-04-10  8:31     ` Russell King - ARM Linux
2012-04-10  8:31       ` Russell King - ARM Linux
2012-04-10  8:31       ` Russell King - ARM Linux
2012-04-10  8:35       ` Mark Brown
2012-04-10  8:35         ` Mark Brown
     [not found]         ` <20120410083543.GC3149-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-04-10  8:47           ` Russell King - ARM Linux
2012-04-10  8:47             ` Russell King - ARM Linux
2012-04-10  8:47             ` Russell King - ARM Linux
     [not found]             ` <20120410084702.GM24211-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-04-10  8:58               ` Shawn Guo
2012-04-10  8:58                 ` Shawn Guo
2012-04-10  8:58                 ` Shawn Guo
     [not found] ` <1333306720-28344-1-git-send-email-broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-04-01 19:22   ` Linus Walleij
2012-04-01 19:22     ` Linus Walleij
2012-04-01 19:22     ` Linus Walleij
     [not found]     ` <CACRpkdYRStgKo_e-4kZKA-V-OoMiV21jRS3R4g1Cq+4c+4=iQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-04-01 19:39       ` Rabin Vincent
2012-04-01 19:39         ` Rabin Vincent
2012-04-01 19:39         ` Rabin Vincent
     [not found]         ` <CAH+eYFC+q4xFuSdRBkO9nb0XZWU4pQ_yCyinMy2X3ds9WQd1kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-04-01 22:39           ` Linus Walleij
2012-04-01 22:39             ` Linus Walleij
2012-04-01 22:39             ` Linus Walleij
2012-04-02 10:14             ` Mark Brown
2012-04-02 10:14               ` Mark Brown
2012-04-02 10:43               ` Russell King - ARM Linux
2012-04-02 10:43                 ` Russell King - ARM Linux
2012-04-02 11:34                 ` Mark Brown
2012-04-02 11:34                   ` Mark Brown
     [not found]                   ` <20120402113413.GA7560-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-04-02 16:57                     ` Russell King - ARM Linux
2012-04-02 16:57                       ` Russell King - ARM Linux
2012-04-02 16:57                       ` Russell King - ARM Linux
2012-04-02 17:19                       ` Mark Brown
2012-04-02 17:19                         ` Mark Brown
     [not found]                 ` <20120402104357.GB24211-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2012-04-02 15:52                   ` Linus Walleij
2012-04-02 15:52                     ` Linus Walleij
2012-04-02 15:52                     ` Linus Walleij
2012-04-01 21:27     ` Mark Brown
2012-04-01 21:27       ` Mark Brown
2012-04-01 22:33       ` Linus Walleij
2012-04-01 22:33         ` Linus Walleij
2012-04-02 10:41         ` Mark Brown
2012-04-02 10:41           ` Mark Brown
2012-04-06 18:12   ` Rob Herring
2012-04-06 18:12     ` Rob Herring
2012-04-06 18:12     ` Rob Herring
2012-04-13  9:03 ` Ulf Hansson
2012-04-13  9:03   ` Ulf Hansson
2012-04-13  9:18   ` Mark Brown
2012-04-13  9:18     ` Mark Brown
     [not found]     ` <20120413091828.GJ3168-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-04-13  9:54       ` Ulf Hansson [this message]
2012-04-13  9:54         ` Ulf Hansson
2012-04-13  9:54         ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F87F7CD.4000004@stericsson.com \
    --to=ulf.hansson-0is4wlfg1ojsueelwk9/pw@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.