All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux PM <linux-pm@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Simon Horman <horms@verge.net.au>,
	Niklas Soderlund <niklas.soderlund+renesas@ragnatech.se>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-gpio@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag
Date: Fri, 5 Jan 2018 10:16:53 +0100	[thread overview]
Message-ID: <CAMuHMdVBBnH2REi4RP6N6S5PaCgrwFteHXPRtnr9jPwtUbx_qA@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0iphV9w6wQy2uQ=wW3HEC+eK4ZnS8fBE-GFuESjXM4PCQ@mail.gmail.com>

Hi Rafael,

On Sun, Dec 31, 2017 at 12:47 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Sun, Dec 31, 2017 at 10:22 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sun, Dec 31, 2017 at 1:56 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>> From: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>
>>>> Changes in v2: [By Ulf Hansson]
>>>>         - I have picked up the series from Geert [1] and converted it into use
>>>>         the WAKEUP_PATH driver PM flag. This includes some minor changes to each
>>>>         patch and updates to the changelogs.
>>>>         - An important note, the WAKEUP_PATH driver PM flag is introduced in a
>>>>         separate series [2], not yet applied, so @subject series depends on it.
>>>>         - One more note, two of the patches has a checkpatch error, however I
>>>>         did not fix them, becuase I think that should be done separate.
>>>>
>>>> [1]
>>>> https://lkml.org/lkml/2017/11/9/382
>>>> [2]
>>>> https://marc.info/?l=linux-pm&m=151454744124661&w=2
>>>>
>>>> More information below, picked from Geert's previous cover letter.
>>>>
>>>> Kind regards
>>>> Uffe
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> If an interrupt controller in a Renesas ARM SoC is part of a Clock
>>>> Domain, and it is part of the wakeup path, it must be kept active during
>>>> system suspend.
>>>>
>>>> Currently this is handled in all interrupt controller drivers by
>>>> explicitly increasing the use count of the module clock when the device
>>>> is part of the wakeup path.  However, this explicit clock handling is
>>>> merely a workaround for a failure to properly communicate wakeup
>>>> information to the device core.
>>>>
>>>> Hence this series fixes the affected drivers by setting the devices'
>>>> power.wakeup_path fields instead, to indicate they are part of the
>>>> wakeup path.  Depending on the PM Domain's active_wakeup configuration,
>>>> the genpd core code will keep the device enabled (and the clock running)
>>>> during system suspend when needed.
>>>
>>> However, there is a convention, documented in the kerneldoc comment of
>>> device_init_wakeup(), by which devices participating in system wakeup
>>> "passively" (like USB controllers and hubs) are expected to have it
>>> enabled by default.
>>>
>>> If that convention was followed by the devices in question here, the
>>> wakeup_path bit would be set for them and no other code changes would
>>> be necessary.  So is there any reason for not following it?
>>
>> Yes there is.  The need to stay enabled during system suspend depends
>> on the consumer of the interrupt. It is controlled by the consumer using
>> the irq_chip.irq_set_wake() callback at runtime, and may change at runtime.
>>
>> If the wakeup_path flag is always set, the interrupt controller will
>> never be suspended during system suspend, and thus waste power.
>
> OK
>
> For IRQ chips in particular, I think, you don't need add new fields to
> struct dev_pm_info to make it work.
>
> In ->suspend (or ->suspend_late, which may be better) you can check
> the IRQD_WAKEUP_STATE flag of the irq_desc associated with the pin.
> If that is set, you can simply set power.wakeup_path for the device
> and that will make genpd skip it.  Wouldn't that work?

The irq_desc is per pin, while suspend is called per platform device, which
contains one or more irq_chips, each serving one or more pins.
So checking for IRQD_WAKEUP_STATE means looping over all irq_descs
associated to the platform device.

Which made me realize {gpio_rcar,irqc,intc_irqpin}_priv.wakeup_path should
not be a flag, but a counter. Currently it works by luck, as we never have
two independent wake-up sources being routed through the same irqchip.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

      reply	other threads:[~2018-01-05  9:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-29 13:31 [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag Ulf Hansson
2017-12-29 13:31 ` [PATCH v2 1/3] irqchip/renesas-intc-irqpin: " Ulf Hansson
2017-12-31  0:58   ` Rafael J. Wysocki
2017-12-29 13:31 ` [PATCH v2 2/3] irqchip/renesas-irqc: " Ulf Hansson
2017-12-29 13:31 ` [PATCH v2 3/3] gpio: rcar: " Ulf Hansson
2018-01-02  9:27   ` Linus Walleij
2018-01-02  9:37     ` Geert Uytterhoeven
2018-01-02 10:26       ` Rafael J. Wysocki
2018-01-02 10:32   ` Rafael J. Wysocki
2018-01-02 10:44     ` Geert Uytterhoeven
2018-01-02 10:48       ` Rafael J. Wysocki
2018-01-02 12:53         ` Ulf Hansson
2018-01-02 13:53           ` Geert Uytterhoeven
2018-01-02 15:41             ` Ulf Hansson
2018-01-02 13:02       ` Ulf Hansson
2018-01-02 13:57         ` Geert Uytterhoeven
2017-12-31  0:56 ` [PATCH v2 0/3] renesas: irqchip: " Rafael J. Wysocki
2017-12-31  9:22   ` Geert Uytterhoeven
2017-12-31 11:47     ` Rafael J. Wysocki
2018-01-05  9:16       ` Geert Uytterhoeven [this message]

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=CAMuHMdVBBnH2REi4RP6N6S5PaCgrwFteHXPRtnr9jPwtUbx_qA@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=geert+renesas@glider.be \
    --cc=horms@verge.net.au \
    --cc=jason@lakedaemon.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --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 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.