Battery status

Battery status

[Rodolfo Giometti]

Hello,

I'd like to implement a way to allow userspace to read battery status
(or percentage).  I notice this port of APM interface for ARM
architecture «arch/arm/kernel/apm.c» and I think I can use comething
similar... what do you think about that?

Do someone know a better way to resolve this problem into MIPS
subtree?

Thanks,

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

Re: Battery status

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Fri, 2005-07-22 at 16:22 +0200, Rodolfo Giometti wrote:
> Hello,
> 
> I'd like to implement a way to allow userspace to read battery status
> (or percentage).  I notice this port of APM interface for ARM
> architecture «arch/arm/kernel/apm.c» and I think I can use comething
> similar... what do you think about that?

You might want to look at how acpi is presented in the /proc interface.
You could hook your battery status routines into the acpi entries:

	/proc/acpi/battery/BAT0/{alarm,info,status} 

Just a thought.

Clark

-- 
Clark Williams <williams@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Battery status

[Rodolfo Giometti]

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

On Fri, Jul 22, 2005 at 09:53:56AM -0500, Clark Williams wrote:
> You might want to look at how acpi is presented in the /proc interface.
> You could hook your battery status routines into the acpi entries:
> 
> 	/proc/acpi/battery/BAT0/{alarm,info,status} 

I see... but in «drivers/acpi/Kconfig» I notice that this driver
depends on «IA64 || X86». Do you think I can activate it even for MIPS
arch? :-o

Thanks,

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 --]

Re: Battery status

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Fri, 2005-07-22 at 17:14 +0200, Rodolfo Giometti wrote:
> On Fri, Jul 22, 2005 at 09:53:56AM -0500, Clark Williams wrote:
> > You might want to look at how acpi is presented in the /proc interface.
> > You could hook your battery status routines into the acpi entries:
> > 
> > 	/proc/acpi/battery/BAT0/{alarm,info,status} 
> 
> I see... but in «drivers/acpi/Kconfig» I notice that this driver
> depends on «IA64 || X86». Do you think I can activate it even for MIPS
> arch? :-o

/me goes and actually *looks* at the acpi driver(s)

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. 

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). 

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
driver that presents a /proc interface to get to battery information. 

Clark

-- 
Clark Williams <williams@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Battery status

[Rodolfo Giometti]

[-- 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 --]

Re: Battery status

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Fri, 2005-07-22 at 17:34 +0200, Rodolfo Giometti wrote:
> > 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!
> 

Ok, just remember: you asked for it! :)

> > 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? :)

I would start out deciding where the user-space interface would live. If
it were me, I'd probably create a /proc entry called <myplatform> (where
<myplatform> == whatever mips platform you're using, e.g. malta4kc),
then put proc entries for whatevery you're interested in in there. For
example, I'd do battery like this:

	/proc/malta4kc/battery/{info,status}

So that if you cat the info entry, you'd get the make, model, capacity,
etc. If you cat the state entry, you'll get remaining charge, charging
state, discharge rate, etc. Anyway, that's good enough to start with and
if later you want to make it more generic, you can get more opinions on
where it should live in the filesystem.

Then, I'd go look at some driver modules that manage /proc entries (like
the acpi stuff). To start with I'd put a skeleton in place that
responded with fixed values, then write up some underlying routines to
actually grab stuff from the battery in response to a read from
the /proc entry.

What platform are you doing this for?

Clark

-- 
Clark Williams <williams@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Battery status

[Ralf Baechle]

On Fri, Jul 22, 2005 at 09:53:56AM -0500, Clark Williams wrote:

> > I'd like to implement a way to allow userspace to read battery status
> > (or percentage).  I notice this port of APM interface for ARM
> > architecture «arch/arm/kernel/apm.c» and I think I can use comething
> > similar... what do you think about that?
> 
> You might want to look at how acpi is presented in the /proc interface.
> You could hook your battery status routines into the acpi entries:
> 
> 	/proc/acpi/battery/BAT0/{alarm,info,status} 
> 
> Just a thought.

Forget it.  One of the great advantages of MIPS is that Intel has ACPI.
On the open Richter scale for stupidity ACPI in computing is a 9.8.

  Ralf

Re: Battery status

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

On Fri, 2005-07-22 at 15:17 -0400, Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 09:53:56AM -0500, Clark Williams wrote:
> 
> > > I'd like to implement a way to allow userspace to read battery status
> > > (or percentage).  I notice this port of APM interface for ARM
> > > architecture «arch/arm/kernel/apm.c» and I think I can use comething
> > > similar... what do you think about that?
> > 
> > You might want to look at how acpi is presented in the /proc interface.
> > You could hook your battery status routines into the acpi entries:
> > 
> > 	/proc/acpi/battery/BAT0/{alarm,info,status} 
> > 
> > Just a thought.
> 
> Forget it.  One of the great advantages of MIPS is that Intel has ACPI.
> On the open Richter scale for stupidity ACPI in computing is a 9.8.

I never said that I liked ACPI, just that I liked the /proc interface.
I'm not really a fan of putting an interpreter into the system
firmware...

Clark

-- 
Clark Williams <williams@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Battery status

[Ralf Baechle]

On Fri, Jul 22, 2005 at 04:10:16PM -0500, Clark Williams wrote:

> > Forget it.  One of the great advantages of MIPS is that Intel has ACPI.
> > On the open Richter scale for stupidity ACPI in computing is a 9.8.
> 
> I never said that I liked ACPI, just that I liked the /proc interface.
> I'm not really a fan of putting an interpreter into the system
> firmware...

Okay.  I was assuming of somebody says ACPI he must mean ACPI ...

  Ralf

Re: Battery status

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Fri, 2005-07-22 at 17:23 -0400, Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 04:10:16PM -0500, Clark Williams wrote:
> 
> > > Forget it.  One of the great advantages of MIPS is that Intel has ACPI.
> > > On the open Richter scale for stupidity ACPI in computing is a 9.8.
> > 
> > I never said that I liked ACPI, just that I liked the /proc interface.
> > I'm not really a fan of putting an interpreter into the system
> > firmware...
> 
> Okay.  I was assuming of somebody says ACPI he must mean ACPI ...

Heh. You and David Woodhouse both go nuclear when someone says ACPI :)

Clark

-- 
Clark Williams <williams@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Battery status

[Ralf Baechle]

On Fri, Jul 22, 2005 at 05:07:58PM -0500, Clark Williams wrote:

> > > > Forget it.  One of the great advantages of MIPS is that Intel has ACPI.
> > > > On the open Richter scale for stupidity ACPI in computing is a 9.8.
> > > 
> > > I never said that I liked ACPI, just that I liked the /proc interface.
> > > I'm not really a fan of putting an interpreter into the system
> > > firmware...
> > 
> > Okay.  I was assuming of somebody says ACPI he must mean ACPI ...
> 
> Heh. You and David Woodhouse both go nuclear when someone says ACPI :)

Well, and on Monday Linus said about ACPI BIOS writers in front of 80
kernel developers and an Intel guy on stage "BIOS writers are morons".
Nobody did object and 30s later that was /topic on the #kernel irc
channel ...

  Ralf

Re: Battery status

[Alan Cox]

On Gwe, 2005-07-22 at 18:16 -0400, Ralf Baechle wrote:
> Well, and on Monday Linus said about ACPI BIOS writers in front of 80
> kernel developers and an Intel guy on stage "BIOS writers are morons".
> Nobody did object and 30s later that was /topic on the #kernel irc
> channel ...

That would be because the BIOS writers don't get invited. From some of
the BIOS people I've talked to I'd say that

a) They are not morons they just work in ridiculous situations and
timescales
b) They don't neccessarily like ACPI either
c) Linus attitude is not helpful

What I will say from the non x86 end of things is that ACPI is vastly
inferior IMHO to things like OpenFirmware, but its Intel and Intel don't
seem to like standards they didn't invent.

Alan

Re: Battery status

[Rodolfo Giometti]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

On Fri, Jul 22, 2005 at 02:08:05PM -0500, Clark Williams wrote:
> I would start out deciding where the user-space interface would live. If
> it were me, I'd probably create a /proc entry called <myplatform> (where
> <myplatform> == whatever mips platform you're using, e.g. malta4kc),
> then put proc entries for whatevery you're interested in in there. For
> example, I'd do battery like this:
> 
> 	/proc/malta4kc/battery/{info,status}

But, doing like this you break userland compatibility... I'd like use
already written code for battery management, not write new one. :)

> So that if you cat the info entry, you'd get the make, model, capacity,
> etc. If you cat the state entry, you'll get remaining charge, charging
> state, discharge rate, etc. Anyway, that's good enough to start with and
> if later you want to make it more generic, you can get more opinions on
> where it should live in the filesystem.

I see. However I think is better implement «standard» files like:

   /proc/acpi/battery/BATT/{alarm, info, state}

> Then, I'd go look at some driver modules that manage /proc entries (like
> the acpi stuff). To start with I'd put a skeleton in place that
> responded with fixed values, then write up some underlying routines to
> actually grab stuff from the battery in response to a read from
> the /proc entry.
> 
> What platform are you doing this for?

A custum board based on Alchemy Au1100.

However I've already ported the file «arch/arm/kernel/apm.c» for non
i386 architectures and it seems working good. :) Even if it implements
APM features.

Now I'll do some tests with userland code (GPE) and after that I'll
consider if I have to start with ACPI also.

Thanks a lot for your suggestion! Hope to send you a patch as soon as
possible.

Ciao,

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 --]

Re: Battery status

[Maciej W. Rozycki]

On Fri, 22 Jul 2005, Clark Williams wrote:

> > Okay.  I was assuming of somebody says ACPI he must mean ACPI ...
> 
> Heh. You and David Woodhouse both go nuclear when someone says ACPI :)

 Please add me to the list, too. ;-)

  Maciej