mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Dmitry Torokhov <dtor@google.com>,
	Eric Caruso <ejcaruso@google.com>,
	linux-kernel@vger.kernel.org, Benson Leung <bleung@google.com>
Subject: Re: irq mask swapping during suspend/resume
Date: Sun, 21 Sep 2014 02:48:30 +0200	[thread overview]
Message-ID: <2213339.XxHo9Gxm0z@vostro.rjw.lan> (raw)
In-Reply-To: <alpine.DEB.2.10.1409181326140.4206@nanos>

On Thursday, September 18, 2014 01:32:06 PM Thomas Gleixner wrote:
> On Wed, 17 Sep 2014, Dmitry Torokhov wrote:
> > Hi Thomas,
> > 
> > On Wednesday, September 17, 2014 12:05:42 PM Thomas Gleixner wrote:
> > > On Tue, 16 Sep 2014, Eric Caruso wrote:
> > > > We would like to be able to set different irq masks for triggers during
> > > > normal operation and for waking up the system. For example, while a laptop
> > > > is awake, closing the lid and opening the lid should both fire an
> > > > interrupt, but when the system is asleep, we would like to stay asleep
> > > > when
> > > > closing the lid.
> > > > 
> > > > We are thinking about stashing the irq mask used specifically for waking
> > > > the system up in the irq_desc struct, and then swapping it during
> > > > enable_irq_wake and disable_irq_wake calls. Devices that do not specify a
> > > > different wake mask will use their normal trigger mask for both
> > > > situations.
> > > > 
> > > > Is this acceptable?
> > > 
> > > Not really. Why should irq_desc provide storage for random
> > > configurations and bind them to some random system state?
> > > 
> > > What's wrong with calling
> > > 
> > >        irq_set_type(irq, B);
> > >        enable_irq_wake(irq);
> > > 
> > >        disable_irq_wake(irq);
> > >        irq_set_type(irq, A);
> > 
> > The desire is to avoid doing it in [every] driver but rather have it done
> > centrally by device/PM core. It does not have to be irq_desc though,
> > maybe you can suggest a better place for it (aside of the individual driver
> > code that is)?
> 
> Well, if it should be done by the device/pm core then you want to
> store that information in the device related data structure. 
> 
> struct dev_pm_info might be the right place for it, but that's up to
> Rafael.
> 
> So driver would set
> 
>    dev->power.update_wakeirq_type = true;
>    dev->power.irq_type_normal = IRQ_TYPE_EDGE_BOTH;
>    dev->power.irq_type_sleep = IRQ_TYPE_EDGE_LOW;
> 
> And the dev/PM core can issue the calls on suspend/resume.

So I'd rather put that into the struct wakeup_source pointed to by
the wakeup pointer in struct dev_pm_info.  That would give us a mapping
between wakeup source objects and wakeup interrupts and which would make
a fair amount of sense in my view.

Then, we could simply walk the list of wakeup source objects before
suspend_device_irqs() and call enable_irq_wake() etc. for all of the
interrupts in question without drivers having to worry about that.
We also could save the current IRQ type for them at that point and
restore it during resume.

Of course, that would require some changes to wakeup_source_create()
and friends, but is probably worth doing.

Still, before we start making those changes, here's a bunch of questions
to answer:

(1) Say a wakeup interrupt is shared between two drivers and one of them
    asks for a different "IRQ type for sleep" than the other one.  How are
    we going to resolve such conflicts?

(2) Can platforms place restrictions on the IRQ type to be used with a given
    line?  If so, how do we handle situations in which the requested
    "IRQ type for sleep" is different from what the given line can use?
    Do we need to resolve that at the struct wakeup_source creation time or
    can we do that later (during suspend?) and how?

Rafael


  reply	other threads:[~2014-09-21  0:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAA9CXT07f01KW4UeoPPy4k1NM6qfxdtsOQXXSPjTKx7mG_v7Rw@mail.gmail.com>
2014-09-17 17:35 ` Fwd: " Eric Caruso
2014-09-17 19:05 ` Thomas Gleixner
2014-09-17 20:05   ` Dmitry Torokhov
2014-09-18 20:32     ` Thomas Gleixner
2014-09-21  0:48       ` Rafael J. Wysocki [this message]
2014-09-26 16:58         ` Eric Caruso
2014-09-26 21:39           ` Rafael J. Wysocki
2014-09-26 21:47             ` Rafael J. Wysocki
2014-09-29 22:43         ` Thomas Gleixner

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=2213339.XxHo9Gxm0z@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=bleung@google.com \
    --cc=dtor@google.com \
    --cc=ejcaruso@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®