linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: linux-acpi@vger.kernel.org, ibm-acpi@hmh.eng.br,
	ibm-acpi-devel@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 2/2] thinkpad_acpi: Hook volume events
Date: Wed, 5 May 2010 14:20:30 +0100	[thread overview]
Message-ID: <20100505132030.GA24372@srcf.ucam.org> (raw)
In-Reply-To: <20100505113004.GA19480@khazad-dum.debian.net>

On Wed, May 05, 2010 at 08:30:05AM -0300, Henrique de Moraes Holschuh wrote:

> The idea is sound, but it would be probably cleaner to do it only on those
> thinkpads which need it.  I don't like the idea of handling duplicate
> notifications, and the logic depends entirely on nothing messing with the
> mixer state behind our backs, I'd prefer to rely on it just when strictly
> required.

In this case the notification is purely at the ALSA level, so there's no 
harm caused by duplicate notifications.

> Also, UCMS is called for a number of reasons.  It would be best to filter
> based on the UCMS parameter before doing an expensive PC CMOS RAM read or EC
> read.  We will be dealing with a finite number of thinkpads anyway.

Passing the parameter is... difficult. That would involve rather more 
surgery to the ACPI core, since the parameters are core-internal objects 
at this point. It's an obvious feature though, so I'll look into it some 
more.

> On the same note, we need to be called *after* the UCMS method completes,
> otherwise, we will have to schedule delayed work.  I didn't study your ACPI
> patch enough to know whether this happens, but that detail is not clear from
> the description.

The call is made after executing the original method, yes.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2010-05-05 13:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-03 20:02 [PATCH 1/2] acpi: Provide interface for driver notification on method call Matthew Garrett
2010-05-03 20:03 ` [PATCH 2/2] thinkpad_acpi: Hook volume events Matthew Garrett
2010-05-05 11:30   ` Henrique de Moraes Holschuh
2010-05-05 13:20     ` Matthew Garrett [this message]
2010-05-06  3:02       ` Henrique de Moraes Holschuh
     [not found]         ` <20100506030239.GB19265-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2010-05-06 12:47           ` Matthew Garrett

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=20100505132030.GA24372@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=hmh@hmh.eng.br \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=ibm-acpi@hmh.eng.br \
    --cc=linux-acpi@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.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).