linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Jon Hunter <jonathanh@nvidia.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Soren Brinkmann <soren.brinkmann@xilinx.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [RFC PATCH V2 3/8] genirq: Add runtime power management support for IRQ chips
Date: Thu, 17 Dec 2015 14:19:48 +0100	[thread overview]
Message-ID: <CACRpkdZXBPQv0ftZJEyE_Q7X_nTpY=3Cd_PTCnK-nHMyqmmBqg@mail.gmail.com> (raw)
In-Reply-To: <1450349309-8107-4-git-send-email-jonathanh@nvidia.com>

On Thu, Dec 17, 2015 at 11:48 AM, Jon Hunter <jonathanh@nvidia.com> wrote:

(Adding Rafael and linux-pm to To: list)

> Some IRQ chips may be located in a power domain outside of the CPU
> subsystem and hence will require device specific runtime power management.
> In order to support such IRQ chips, add a pointer for a device structure
> to the irq_chip structure, and if this pointer is populated by the IRQ
> chip driver and the flag CHIP_HAS_RPM is set, then the pm_runtime_get/put
> APIs for this chip will be called when an IRQ is requested/freed,
> respectively.
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>

Overall I like what you're trying to do. This will enable e.g. I2C
GPIO supplying expanders to power down if none of its lines are
used for IRQs. (Read below on the suspend() case for even
better stuff we can do!)

(...)
> @@ -307,6 +307,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
>  /**
>   * struct irq_chip - hardware interrupt chip descriptor
>   *
> + * @dev:               pointer to associated device
(...)
>  struct irq_chip {
> +       struct device   *dev;

In struct gpio_chip I just this merge window have to merge a gigantic
patch renaming this from "dev" to "parent" because we need to add
a *real* struct device dev; to gpio_chip.

So for the advent that we may in the future need a real struct device
inside irq_chip, name this .parent already today, please.

> +/* Inline functions for support of irq chips that require runtime pm */
> +static inline int chip_pm_get(struct irq_desc *desc)
> +{
> +       int retval = 0;
> +
> +       if (desc->irq_data.chip->dev &&
> +           desc->irq_data.chip->flags & IRQCHIP_HAS_RPM)
> +               retval = pm_runtime_get_sync(desc->irq_data.chip->dev);
> +
> +       return (retval < 0) ? retval : 0;
> +}

That is boiling all PM upward into the platform_device or whatever
it is containing this. But we're not just in it for runtime_pm_suspend()
and runtime_pm_resume(). We also have regular suspend() and
resume(). And ideally that should be handled by the same
callbacks.

First: what if the device contain any wakeup-flagged IRQs?
I think there is something missing here. The suspend() usecase
is not handled by this patch, but we need to think about that
here as well. I think irqchips on GPIO expanders (for example)
should be powered down on suspend() *unless* one or more of
its IRQs is flagged as wakeup, and in that case it should
*not* be powered down, instead it should just mask all
non-wakeup IRQs and restore them on resume().

Second: it's soo easy to get something wrong here. It'd be good
if the kernel was helpful. What about something like:

if (desc->irq_data.chip->dev) {
    if (desc->irq_data.chip->flags & IRQCHIP_HAS_RPM)
           retval = pm_runtime_get_sync(desc->irq_data.chip->dev)
    else if (pm_runtime_enabled(desc->irq_data.chip->dev))
           dev_warn_once(desc->irq_data.chip->dev, "irqchip not
flagged for RPM but has runtime PM enabled! weird.\n");
}

As I see it, a device that supplies an irqchip, has runtime PM but
is *NOT* setting IRQCHIP_HAS_RPM just *have* to be looked
at in detail, and deserve to have this littering its dmesg so we can
fix it. It just makes no real sense. It more sounds like a recepie for
missing interrupts otherwise.

Yours,
Linus Walleij

  reply	other threads:[~2015-12-17 13:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 10:48 [RFC PATCH V2 0/8] Add support for Tegra210 AGIC Jon Hunter
2015-12-17 10:48 ` [RFC PATCH V2 1/8] irqdomain: Ensure type settings match for an existing mapping Jon Hunter
2015-12-17 13:16   ` Linus Walleij
2015-12-18 10:10     ` Jon Hunter
2015-12-22  9:58       ` Linus Walleij
2015-12-22 10:00         ` Linus Walleij
2015-12-22 11:27           ` Jon Hunter
2015-12-22 11:31           ` Grygorii Strashko
2015-12-17 10:48 ` [RFC PATCH V2 2/8] irqdomain: Don't set type when mapping an IRQ Jon Hunter
2015-12-17 12:18   ` Linus Walleij
2015-12-22 11:18   ` Grygorii Strashko
2015-12-22 11:56     ` Jon Hunter
2016-03-18  9:16       ` Geert Uytterhoeven
2015-12-17 10:48 ` [RFC PATCH V2 3/8] genirq: Add runtime power management support for IRQ chips Jon Hunter
2015-12-17 13:19   ` Linus Walleij [this message]
2015-12-18 10:20     ` Jon Hunter
2016-01-12 18:40   ` Grygorii Strashko
2016-01-12 21:43     ` Sören Brinkmann
2016-01-18 14:47   ` Ulf Hansson
2016-01-19 10:43     ` Jon Hunter
2016-01-20 15:30       ` Thomas Gleixner
2016-01-21  8:38         ` Jon Hunter
2016-01-21 12:40         ` Ulf Hansson
2016-01-21 19:51           ` Thomas Gleixner
2016-01-22 11:08             ` Ulf Hansson
2016-01-26 17:17               ` Thomas Gleixner
2016-02-05 14:37             ` Linus Walleij
2016-03-18 13:57               ` Grygorii Strashko
2015-12-17 10:48 ` [RFC PATCH V2 4/8] irqchip/gic: Don't initialise chip if mapping IO space fails Jon Hunter
2015-12-17 13:21   ` Linus Walleij
2015-12-17 10:48 ` [RFC PATCH V2 5/8] irqchip/gic: Return an error if GIC initialisation fails Jon Hunter
2015-12-17 13:26   ` Linus Walleij
2015-12-18 10:24     ` Jon Hunter
2015-12-17 10:48 ` [RFC PATCH V2 6/8] irqchip/gic: Assign irqchip dynamically Jon Hunter
2015-12-17 11:00   ` Marc Zyngier
2015-12-18 10:26     ` Jon Hunter
2015-12-17 10:48 ` [RFC PATCH V2 7/8] irqchip/gic: Prepare for adding platform driver Jon Hunter
2015-12-17 10:48 ` [RFC PATCH V2 8/8] irqchip/gic: Add support for tegra AGIC interrupt controller Jon Hunter
2015-12-17 10:58   ` Jon Hunter
2015-12-17 13:32   ` Linus Walleij
2015-12-18 10:44     ` Jon Hunter
2015-12-22 10:03       ` Linus Walleij

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='CACRpkdZXBPQv0ftZJEyE_Q7X_nTpY=3Cd_PTCnK-nHMyqmmBqg@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=geert@linux-m68k.org \
    --cc=grygorii.strashko@ti.com \
    --cc=jason@lakedaemon.net \
    --cc=jiang.liu@linux.intel.com \
    --cc=jonathanh@nvidia.com \
    --cc=khilman@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=soren.brinkmann@xilinx.com \
    --cc=swarren@wwwdotorg.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=ulf.hansson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).