mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jaya Kumar" <jayakumar.acpi@gmail.com>
To: "Yu, Luming" <luming.yu@intel.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.15.3 1/1] ACPI: Atlas ACPI driver
Date: Wed, 8 Mar 2006 16:53:11 +0800	[thread overview]
Message-ID: <756b48450603080053q3a6e5dccu4e351cf4891d0fb@mail.gmail.com> (raw)
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B22AB1A@pdsmsx403>

On 3/8/06, Yu, Luming <luming.yu@intel.com> wrote:
>
> I know this user-defined region needs address space handler, but your
> address space handler below  is so weird that make me doubt
> the correctness.  The example of address space handler is:
> ec.c : acpi_ec_space_handler
>

As you suggested, I looked at the ec case:

845         if ((address > 0xFF) || !value || !handler_context)
846                 return_VALUE(AE_BAD_PARAMETER);
847
848         if (bit_width != 8 && acpi_strict) {
849                 printk(KERN_WARNING PREFIX
850                        "acpi_ec_space_handler: bit_width should be 8\n");
851                 return_VALUE(AE_BAD_PARAMETER);
852         }
853

I don't do any of above parameter checking in the atlas button handler
because the only parameter that is used is "address". That's what I
handoff to bus_generate_event. In my case, and unlike the ec case,
there is no embedded controller to read to get more info. To be
specific, on the board, when button 2 is pressed, I get address=1, if
button 3, I get address=2 and so on. Hence, as you can imagine, the
code in the atlas button handler below:

+	if (function == ACPI_WRITE)
+		status = acpi_bus_generate_event(dev, 0x80, address);

is a lot simpler than the ec case where they have to read stuff from
the controller as well as handle multiple bytes of reads.

856       next_byte:
857         switch (function) {
858         case ACPI_READ:
859                 temp = 0;
860                 result = acpi_ec_read(ec, (u8) address, (u32 *) & temp);
861                 break;

So to conclude, I'm not certain in what way the atlas button handler
code is weird. If you could help elaborate on what changes you would
like to see in that code, I'd be happy to change it as per your
desires.

> I suggest LCD support in hotkey.c like:
> http://bugzilla.kernel.org/attachment.cgi?id=6843&action=view
>
>
> Config userspace acpi daemon to respond events by evoking
> LCD._BCM with command:
>        echo -n xx > /sys/hotkey/brightness.

Ok, I think maybe I sort of see what you are saying and I'll take a
look at it when I have some time.

You are suggesting that I should try to get hotkey support working
because the hotkey driver may somehow evaluate _BCM methods to affect
brightness and then to have a userspace app that is triggered by the
ASIM button support thru acpi/event which then writes to the hotkey
driver through hotkey/brightness to then go and evaluate the _BCM
method to affect the LCD brightness.

I hope I've understood what you are saying.

Thanks,
jayakumar

  reply	other threads:[~2006-03-08  8:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08  7:44 Yu, Luming
2006-03-08  8:53 ` Jaya Kumar [this message]
2006-03-13  6:38 ` Jaya Kumar
  -- strict thread matches above, loose matches on Subject: below --
2006-03-13 13:16 Yu, Luming
2006-03-08  6:17 Yu, Luming
2006-03-08  7:11 ` Jaya Kumar
2006-03-07  8:52 Yu, Luming
2006-03-07 16:09 ` Jaya Kumar
2006-03-06 13:50 Yu, Luming
2006-03-07  1:50 ` Jaya Kumar
     [not found] <AcY1+QTZumb9d6e3RHms9ocp4LswwgAtmORQ>
2006-02-21  6:34 ` Yu, Luming
2006-03-03  8:16   ` Jaya Kumar
2006-02-20  8:26 Yu, Luming
2006-02-20  8:37 ` Jaya Kumar
2006-02-20  2:13 jayakumar.acpi
2006-02-20 10:26 ` Matthew Garrett
2006-02-20 10:49   ` Jaya Kumar
2006-02-20 11:01     ` Matthew Garrett
2006-02-20 11:25       ` Jaya Kumar
2006-02-20 11:28         ` 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=756b48450603080053q3a6e5dccu4e351cf4891d0fb@mail.gmail.com \
    --to=jayakumar.acpi@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luming.yu@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

all inboxes | Powered by JetHome®