From: Rodolfo Giometti <giometti@linux.it>
To: Clark Williams <williams@redhat.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Battery status
Date: Fri, 22 Jul 2005 17:34:53 +0200 [thread overview]
Message-ID: <20050722153453.GI21044@enneenne.com> (raw)
In-Reply-To: <1122045924.10743.16.camel@riff>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Fri, Jul 22, 2005 at 10:25:24AM -0500, Clark Williams wrote:
> /me goes and actually *looks* at the acpi driver(s)
Ok. I see! :)
> I would recommend writing a completely separate driver that just
> provides the hook(s) to get to battery and any other info you want to
> provide. I did it on another platform (can't seem to find that code
> though) mainly to use the /proc/acpi/event interface and receive button
> presses and things like that. Something like a fake-acpi.c that various
> platform folks could use to translate their events into the acpi
> interface.
Yes, just file «arch/arm/kernel/apm.c» does regarding APM.
> That's kinda hokey now that I actually wrote it down and looked at it.
> Maybe what we need to do is put together a framework somewhat like the
> way acpi presents state information, but not called acpi (wouldn't want
> someone thinking that we'd ported the acpi interpreter to MIPS :). I'm
> not even sure if it should go into /proc or /sys.
>
> I just liked the fact that the event interface and the status interfaces
> were presented in somewhat logical fashion to user space, such that a
> shell script could be used to gather information or manipulate the state
> (e.g. 'echo 3 >/proc/acpi/sleep' to suspend to RAM).
Yes.
> Gah. Sorry, you were asking for an answer and I turned this into a
> design discussion. My opinion: if you're in a hurry, write a simple
Nonono. It's very interesting what you are saying!
> driver that presents a /proc interface to get to battery information.
Ok. Currently I have some time to spend on it... do you have any
suggestions about I can start developing it in the good way? :)
Thanks a lot,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@linux.it
Linux Device Driver giometti@enneenne.com
Embedded Systems home page: giometti.enneenne.com
UNIX programming phone: +39 349 2432127
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-22 15:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 14:22 Battery status Rodolfo Giometti
2005-07-22 14:53 ` Clark Williams
2005-07-22 15:14 ` Rodolfo Giometti
2005-07-22 15:25 ` Clark Williams
2005-07-22 15:34 ` Rodolfo Giometti [this message]
2005-07-22 19:08 ` Clark Williams
2005-07-23 12:17 ` Rodolfo Giometti
2005-07-22 19:17 ` Ralf Baechle
2005-07-22 21:10 ` Clark Williams
2005-07-22 21:23 ` Ralf Baechle
2005-07-22 22:07 ` Clark Williams
2005-07-22 22:16 ` Ralf Baechle
2005-07-22 23:14 ` Alan Cox
2005-07-25 12:00 ` Maciej W. Rozycki
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=20050722153453.GI21044@enneenne.com \
--to=giometti@linux.it \
--cc=linux-mips@linux-mips.org \
--cc=williams@redhat.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.