public inbox for linux-acpi@vger.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: 20+ 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           ` [Update][RFC][PATCH 2/3] ACPI: Modify GPE consumers to use GPE refcounting 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-10 21:29         ` [RFC][PATCH 0/3] Introduce GPE refcounting (was: Re: Recent GPE patches - some questions.) 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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox