All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Moore, Robert" <robert.moore@intel.com>, Len Brown <lenb@kernel.org>
Cc: Matthew Garrett <mjg@redhat.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	pm list <linux-pm@lists.linux-foundation.org>
Subject: [Update] Re: [RFC][PATCH 0/3] Introduce GPE refcounting (was: Re: Recent GPE patches - some questions.)
Date: Sun, 7 Feb 2010 12:56:35 +0100	[thread overview]
Message-ID: <201002071256.35998.rjw@sisk.pl> (raw)
In-Reply-To: <201002070317.47029.rjw@sisk.pl>

On Sunday 07 February 2010, Rafael J. Wysocki wrote:
> On Sunday 07 February 2010, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Wednesday 03 February 2010, Moore, Robert wrote:
> > > Matthew, 
> > > 
> > > Thanks for your response to my questions.
> > > 
> > > I've been thinking about these interfaces:
> > > 
> > > acpi_ref_runtime_gpe
> > > acpi_ref_wakeup_gpe
> > > acpi_unref_runtime_gpe
> > > acpi_unref_wakeup_gpe
> > > 
> > > While I understand the need for the reference counting mechanism, it is a
> > > good idea to support the shared GPEs, I think it may be simpler and cleaner
> > > to simply not directly expose this mechanism to GPE users.
> > 
> > Well, it already is exposed to the users and in a way that doesn't look very
> > clean to me.  Namely, to enable a wakeup GPE for run time, the caller needs to
> > set its type to ACPI_GPE_TYPE_WAKE_RUN before calling acpi_enable_gpe(),
> > while with the Matthew's interface the only thing the caller would need to do
> > would be calling acpi_ref_runtime_gpe().
> > 
> > > I'm suggesting that we add the reference counting mechanism to the existing
> > > AcpiEnableGpe and AcpiDisableGpe interfaces and update their descriptions.
> > > We already hide the differences between wake, run, and wake-run GPEs behind
> > > these interfaces.
> > 
> > Not really, as I said above.
> > 
> > Moreover, we need two reference counters, because there are cases when a
> > GPE should be enabled for wakeup and not enabled for run time and vice versa.
> > 
> > > Adding the reference count semantic to these interfaces changes their
> > > behavior in a fairly simple way:
> > > 
> > > Support for shared GPEs:
> > > AcpiEnableGpe: For a given GPE, it is actually enabled only on the first call.
> > > AcpiDisableGpe: For a given GPE, it is actually disabled only on the last call.
> > 
> > I suppose you mean acpi_enable_gpe() and acpi_disable_gpe().
> > 
> > That wouldn't work, because sometimes we need to actually hardware-disable
> > GPEs and hardware-enable them regardless of the refcount mechanism, like for
> > example in the EC suspend and resume routines.
> > 
> > That said, if you are afraid that the new interface may be cumbersome for the
> > callers, I think we can introduce just two callbacks,
> > 
> > acpi_get_gpe()
> > acpi_put_gpe()
> > 
> > taking 3 arguments each, where the two first arguments are like for the
> > Matthew's callbacks and the third argument is a mask of two bits:
> > 
> > ACPI_GPE_TYPE_WAKE
> > ACPI_GPE_TYPE_RUNTIME
> > 
> > that will tell the callback whether to use the wakeup or runtime counter for
> > reference counting (if called with ACPI_GPE_TYPE_WAKE_RUN, both
> > reference counters will be modified at the same time).
> > 
> > Please tell me what you think.
> 
> For easier reference, I reworked the Matthew's patches to implement the above
> idea.

I noticed that patch [2/3] was actually wrong, because it added the GPE
refcounting to drivers/acpi/wakeup.c:acpi_[enable|disable]_wakeup_device(),
while in fact it should have added it to
drivers/acpi/sleep.c:acpi_pm_device_sleep_wake().

Moreover, patch [3/3] did not really enable the wakeup GPEs after they had been
disabled by acpi_disable_all_gpes().

I fixed the two patches and added explanatory comments to patch [1/3].

Updated patches follow, comments welcome.

Rafael


  parent reply	other threads:[~2010-02-07 12:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 20:30 Recent GPE patches - some questions Moore, Robert
2010-02-01 22:36 ` Matthew Garrett
2010-02-02 23:02   ` Moore, Robert
2010-02-06 23:31     ` Rafael J. Wysocki
2010-02-07  2:17       ` [RFC][PATCH 0/3] Introduce GPE refcounting (was: Re: Recent GPE patches - some questions.) Rafael J. Wysocki
2010-02-07  2:22         ` [RFC][PATCH 1/3] ACPI: Add infrastructure for refcounting GPE consumers Rafael J. Wysocki
2010-02-07  2:23         ` [RFC][PATCH 2/3] ACPI: Modify GPE consumers to use GPE refcounting Rafael J. Wysocki
2010-02-07  2:24         ` [RFC][PATCH 3/3] ACPI: Remove old GPE API and transition code entirely to new one Rafael J. Wysocki
2010-02-07 11:56         ` Rafael J. Wysocki [this message]
2010-02-07 11:58           ` [Update][RFC][PATCH 1/3] ACPI: Add infrastructure for refcounting GPE consumers Rafael J. Wysocki
2010-02-07 11:58           ` Rafael J. Wysocki
2010-02-07 11:58           ` [Update][RFC][PATCH 2/3] ACPI: Modify GPE consumers to use GPE refcounting Rafael J. Wysocki
2010-02-07 11:58           ` Rafael J. Wysocki
2010-02-07 11:59           ` [Update][RFC][PATCH 3/3] ACPI: Remove old GPE API and transition code entirely to new one Rafael J. Wysocki
2010-02-07 11:59           ` Rafael J. Wysocki
2010-02-07 11:56         ` [Update] Re: [RFC][PATCH 0/3] Introduce GPE refcounting (was: Re: Recent GPE patches - some questions.) Rafael J. Wysocki
2010-02-10 21:29         ` Maxim Levitsky
2010-02-10 21:36           ` Rafael J. Wysocki
2010-02-11 17:36             ` Maxim Levitsky
2010-02-11 20:34               ` Rafael J. Wysocki
2010-02-13 16:08                 ` Maxim Levitsky
2010-02-14  2:24                   ` Rafael J. Wysocki
2010-02-10 21:36       ` Recent GPE patches - some questions Moore, Robert
2010-02-11 22:51         ` [PATCH] ACPI: Use GPE reference counting to support shared GPEs (was: Re: Recent GPE patches - some questions.) Rafael J. Wysocki
2010-02-11 22:51         ` Rafael J. Wysocki

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=201002071256.35998.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=jbarnes@virtuousgeek.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mjg@redhat.com \
    --cc=robert.moore@intel.com \
    /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.