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: [email protected]
Linux Device Driver [email protected]
Embedded Systems [email protected]
UNIX programming phone: +39 349 2432127
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
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: [email protected]
Linux Device Driver [email protected]
Embedded Systems [email protected]
UNIX programming phone: +39 349 2432127
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..
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
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: [email protected]
Linux Device Driver [email protected]
Embedded Systems [email protected]
UNIX programming phone: +39 349 2432127
On 2/1/07, Rodolfo Giometti <[email protected]> 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
APM-EMULATION: apm_get_power_status() should be NULL on init.
Signed-off-by: Rodolfo Giometti <[email protected]>
---
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).
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