Advice on APM-EMU reunion

Advice on APM-EMU reunion

[Rodolfo Giometti]

Hello,

some months ago I sent to the MIPS and ARM mail lists a patch to unify
the several APM emulation codes adding a new dedicated directory so it
can be used to put there the per board specific code avoiding code
duplications (see files ./arch/arm/kernel/apm.c,
./arch/mips/kernel/apm.c and ./arch/sh/kernel/apm.c that are almost
the same).

The patch is here
"http://www.linux-mips.org/archives/linux-mips/2006-07/msg00144.html"
and it has been lost in the deep space...

The target is to remove the files ./arch/{arm,mips,sh}/kernel/apm.c
and to add files drivers/apm-emu/{Kconfig,Makefile,apm-emu.c}.

Now I try on this list in order to have some advice if this could be a
good idea and what about if I add a new class "apm_emu" on the sysfs
support with proper registrations functions.

Thanks in advance,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

Re: Advice on APM-EMU reunion

[Richard Purdie]

On Tue, 2007-01-30 at 00:07 +0100, Rodolfo Giometti wrote:
> Now I try on this list in order to have some advice if this could be a
> good idea and what about if I add a new class "apm_emu" on the sysfs
> support with proper registrations functions.

I'm not sure this is a good idea. As you're creating a new interface,
why not create something new/improved without the problems that
confining yourself to APM emulation brings?

Regards,

Richard

Re: Advice on APM-EMU reunion

[Rodolfo Giometti]

On Mon, Jan 29, 2007 at 11:53:46PM +0000, Richard Purdie wrote:

> I'm not sure this is a good idea. As you're creating a new interface,
> why not create something new/improved without the problems that
> confining yourself to APM emulation brings?

Because several applications (and expecially in embedded systems) use
that interface. However adding a sysfs support I try to define a new
(and most versatile) interface.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

Re: Advice on APM-EMU reunion

[Paul Mundt]

On Tue, Jan 30, 2007 at 12:07:56AM +0100, Rodolfo Giometti wrote:
> some months ago I sent to the MIPS and ARM mail lists a patch to unify
> the several APM emulation codes adding a new dedicated directory so it
> can be used to put there the per board specific code avoiding code
> duplications (see files ./arch/arm/kernel/apm.c,
> ./arch/mips/kernel/apm.c and ./arch/sh/kernel/apm.c that are almost
> the same).
> 
> The patch is here
> "http://www.linux-mips.org/archives/linux-mips/2006-07/msg00144.html"
> and it has been lost in the deep space...
> 
Not quite, the rationale for it being dropped was here:

http://article.gmane.org/gmane.linux.kernel/485831

However, it has since been reposted:

http://article.gmane.org/gmane.linux.kernel/485833
http://article.gmane.org/gmane.linux.kernel/485834
http://article.gmane.org/gmane.linux.kernel/485835
http://article.gmane.org/gmane.linux.kernel/485837

and merged back in to -mm. This is all post 2.6.20 stuff, though..

Re: Advice on APM-EMU reunion

[Ralf Baechle]

On Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote:

> http://article.gmane.org/gmane.linux.kernel/485831
> 
> However, it has since been reposted:
> 
> http://article.gmane.org/gmane.linux.kernel/485833
> http://article.gmane.org/gmane.linux.kernel/485834
> http://article.gmane.org/gmane.linux.kernel/485835
> http://article.gmane.org/gmane.linux.kernel/485837
> 
> and merged back in to -mm. This is all post 2.6.20 stuff, though..

Not quite.  I had asked Rudolfo to unify the two copies of APM who then
went silent, so I went and my own thing until Rudolfo eventually
reappeared with his own patch.  So all the recent discussion was about
my patch.

  Ralf

Advice on battery support [was: Advice on APM-EMU reunion]

[Rodolfo Giometti]

On Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote:

> However, it has since been reposted:
> 
> http://article.gmane.org/gmane.linux.kernel/485833
> http://article.gmane.org/gmane.linux.kernel/485834
> http://article.gmane.org/gmane.linux.kernel/485835
> http://article.gmane.org/gmane.linux.kernel/485837
> 
> and merged back in to -mm. This is all post 2.6.20 stuff, though..

Ok, starting from these patches I'd like to add a "battery support" to
the kernel.

What I suppose to do is a new class with a proper methods useful to
collect several info on battery status, such as get_ac_line_status()
get_battery_status(), get_battery_flags(),
get_remaining_battery_life() and so on.

The output will be APM-like into file "/proc/apm" (one line per
battery, or just the "main"/first one?) so that existing applications
continue to work and under sysfs into "/sysfs/class/battery".

Is it sane? :)

Thanks in advance,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@enneenne.com
Linux Device Driver                             giometti@gnudd.com
Embedded Systems                     		giometti@linux.it
UNIX programming                     phone:     +39 349 2432127

Re: Advice on battery support [was: Advice on APM-EMU reunion]

[Matt Reimer]

On 2/1/07, Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> Ok, starting from these patches I'd like to add a "battery support" to
> the kernel.
>
> What I suppose to do is a new class with a proper methods useful to
> collect several info on battery status, such as get_ac_line_status()
> get_battery_status(), get_battery_flags(),
> get_remaining_battery_life() and so on.

Wasn't there recently a big discussion on lkml about a battery class?

Matt

[PATCH 1/1] APM-EMULATION: apm_get_power_status() should be NULL on init [was: Advice on battery support]

[Rodolfo Giometti]

APM-EMULATION: apm_get_power_status() should be NULL on init.

Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>

---

If the function apm_get_info() do like this:

   static int apm_get_info(char *buf, char **start, off_t fpos, int length)
   {
           struct apm_power_info info;
           char *units;
           int ret;

           info.ac_line_status = 0xff;
           info.battery_status = 0xff;
           info.battery_flag   = 0xff;
           info.battery_life   = -1;
           info.time           = -1;
           info.units          = -1;

           if (apm_get_power_status)
                   apm_get_power_status(&info);
   ...

we shouldn't set:

   static void __apm_get_power_status(struct apm_power_info *info)
   {
   }

   void (*apm_get_power_status)(struct apm_power_info *) = __apm_get_power_status;

otherwise the check is not needed. Furthermore setting the function to
NULL signals that the apm-emulation layer is not already assigned (I
found this very useful for my apm-emulation battery_class support).

Re: Advice on battery support [was: Advice on APM-EMU reunion]

[Pavel Machek]

Hi!

> > However, it has since been reposted:
> > 
> > http://article.gmane.org/gmane.linux.kernel/485833
> > http://article.gmane.org/gmane.linux.kernel/485834
> > http://article.gmane.org/gmane.linux.kernel/485835
> > http://article.gmane.org/gmane.linux.kernel/485837
> > 
> > and merged back in to -mm. This is all post 2.6.20 stuff, though..
> 
> Ok, starting from these patches I'd like to add a "battery support" to
> the kernel.
> 
> What I suppose to do is a new class with a proper methods useful to
> collect several info on battery status, such as get_ac_line_status()
> get_battery_status(), get_battery_flags(),
> get_remaining_battery_life() and so on.
> 
> The output will be APM-like into file "/proc/apm" (one line per
> battery, or just the "main"/first one?) so that existing applications
> continue to work and under sysfs into "/sysfs/class/battery".
> 
> Is it sane? :)

Yep. Notice that designing /sysfs/class/battery is not going to be
easy, and that some work was already done in context of olpc
project. Search the mailing lists...
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html