All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Magnus Damm <magnus.damm@gmail.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Jason Cooper <jason@lakedaemon.net>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support
Date: Fri, 08 May 2015 20:26:06 +0000	[thread overview]
Message-ID: <7hmw1ehl41.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAMuHMdWtUYoFWWfijFbQCv6Z-phZW2XN+F5n1zfqbZMFGjM+Bg@mail.gmail.com> (Geert Uytterhoeven's message of "Thu, 23 Apr 2015 19:49:59 +0200")

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Thu, Apr 23, 2015 at 4:44 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 23 Apr 2015, Geert Uytterhoeven wrote:
>>> >> I'm afraid you can't call pm_runtime_get_sync() from these methods, as
>>> >> they may be called from interrupt context.
>>> >
>>> > Ouch. I know the clock framework has prepare/enable separated with
>>> > context, but with the irqchip callbacks I suppose no such separation
>>>
>>> It's not the clock operations, but the pm_runtime operations that cannot be
>>> called from interrupt context.
>>
>> In fact the pm_runtime operations _can_ be called from interrupt
>> context, provided the driver has first invoked pm_runtime_irq_safe().
>> Of course, this requires that none of the runtime-PM callback routines
>> ever sleep or perform a blocking operation.
>>
>> This is all explained in Documentation/power/runtime_pm.txt (search for
>> "irq_safe").
>
> Perhaps that can help. We'll have to give it a try...
>
> I've always found this a bit strange when PM Domains are involved:
> pm_runtime_irq_safe(dev) applies to device dev, while the actual callbacks
> belong to the PM Domain code (the device's driver doesn't have any).

Currently PM domains don't support IRQ-safe devices very well.  Any
irq_safe devices will prevent the entire PM domain from ever powering
off.  There is some on-going work for this but it requires reworking the
genpd locking a bit.

Kevin


WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Magnus Damm <magnus.damm@gmail.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Jason Cooper <jason@lakedaemon.net>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support
Date: Fri, 08 May 2015 13:26:06 -0700	[thread overview]
Message-ID: <7hmw1ehl41.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAMuHMdWtUYoFWWfijFbQCv6Z-phZW2XN+F5n1zfqbZMFGjM+Bg@mail.gmail.com> (Geert Uytterhoeven's message of "Thu, 23 Apr 2015 19:49:59 +0200")

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Thu, Apr 23, 2015 at 4:44 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 23 Apr 2015, Geert Uytterhoeven wrote:
>>> >> I'm afraid you can't call pm_runtime_get_sync() from these methods, as
>>> >> they may be called from interrupt context.
>>> >
>>> > Ouch. I know the clock framework has prepare/enable separated with
>>> > context, but with the irqchip callbacks I suppose no such separation
>>>
>>> It's not the clock operations, but the pm_runtime operations that cannot be
>>> called from interrupt context.
>>
>> In fact the pm_runtime operations _can_ be called from interrupt
>> context, provided the driver has first invoked pm_runtime_irq_safe().
>> Of course, this requires that none of the runtime-PM callback routines
>> ever sleep or perform a blocking operation.
>>
>> This is all explained in Documentation/power/runtime_pm.txt (search for
>> "irq_safe").
>
> Perhaps that can help. We'll have to give it a try...
>
> I've always found this a bit strange when PM Domains are involved:
> pm_runtime_irq_safe(dev) applies to device dev, while the actual callbacks
> belong to the PM Domain code (the device's driver doesn't have any).

Currently PM domains don't support IRQ-safe devices very well.  Any
irq_safe devices will prevent the entire PM domain from ever powering
off.  There is some on-going work for this but it requires reworking the
genpd locking a bit.

Kevin


WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Magnus Damm <magnus.damm@gmail.com>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	Jason Cooper <jason@lakedaemon.net>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support
Date: Fri, 08 May 2015 13:26:06 -0700	[thread overview]
Message-ID: <7hmw1ehl41.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAMuHMdWtUYoFWWfijFbQCv6Z-phZW2XN+F5n1zfqbZMFGjM+Bg@mail.gmail.com> (Geert Uytterhoeven's message of "Thu, 23 Apr 2015 19:49:59 +0200")

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Thu, Apr 23, 2015 at 4:44 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 23 Apr 2015, Geert Uytterhoeven wrote:
>>> >> I'm afraid you can't call pm_runtime_get_sync() from these methods, as
>>> >> they may be called from interrupt context.
>>> >
>>> > Ouch. I know the clock framework has prepare/enable separated with
>>> > context, but with the irqchip callbacks I suppose no such separation
>>>
>>> It's not the clock operations, but the pm_runtime operations that cannot be
>>> called from interrupt context.
>>
>> In fact the pm_runtime operations _can_ be called from interrupt
>> context, provided the driver has first invoked pm_runtime_irq_safe().
>> Of course, this requires that none of the runtime-PM callback routines
>> ever sleep or perform a blocking operation.
>>
>> This is all explained in Documentation/power/runtime_pm.txt (search for
>> "irq_safe").
>
> Perhaps that can help. We'll have to give it a try...
>
> I've always found this a bit strange when PM Domains are involved:
> pm_runtime_irq_safe(dev) applies to device dev, while the actual callbacks
> belong to the PM Domain code (the device's driver doesn't have any).

Currently PM domains don't support IRQ-safe devices very well.  Any
irq_safe devices will prevent the entire PM domain from ever powering
off.  There is some on-going work for this but it requires reworking the
genpd locking a bit.

Kevin

  reply	other threads:[~2015-05-08 20:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 14:59 [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support Magnus Damm
2015-04-21 15:01 ` Magnus Damm
2015-04-21 14:59 ` [PATCH/RFC 01/03] irqchip: renesas-irqc: Add irq_enable() and irq_disable() Magnus Damm
2015-04-21 15:01   ` Magnus Damm
2015-04-21 15:01 ` [PATCH/RFC 02/03] irqchip: renesas-irqc: Add fine grained Runtime PM code Magnus Damm
2015-04-21 15:01   ` Magnus Damm
2015-04-21 15:01 ` [PATCH/RFC 03/03] irqchip: renesas-irqc: Rely on Runtime PM for wakeup Magnus Damm
2015-04-21 15:01   ` Magnus Damm
2015-04-21 17:56 ` [PATCH/RFC 00/03] irqchip: renesas-irqc: Fine grained Runtime PM support Geert Uytterhoeven
2015-04-21 17:56   ` Geert Uytterhoeven
2015-04-23  8:10   ` Magnus Damm
2015-04-23  8:10     ` Magnus Damm
2015-04-23  9:51     ` Geert Uytterhoeven
2015-04-23  9:51       ` Geert Uytterhoeven
2015-04-23 14:44       ` Alan Stern
2015-04-23 14:44         ` Alan Stern
2015-04-23 17:49         ` Geert Uytterhoeven
2015-04-23 17:49           ` Geert Uytterhoeven
2015-05-08 20:26           ` Kevin Hilman [this message]
2015-05-08 20:26             ` Kevin Hilman
2015-05-08 20:26             ` Kevin Hilman

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=7hmw1ehl41.fsf@deeprootsystems.com \
    --to=khilman@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=horms@verge.net.au \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    /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.