Re: apmd and other archs

Re: apmd and other archs

[Michael Schmitz]

> > Linux-PPC (basically the Apple computers, any other Linux/PPC-subset
> > using it ?) uses the PMU, and pmud for power management. I don't think
> > that anybody wants to write an APM support for Power Macs (not me
> > anyway).
>
> Not APM support exactly... simply support for the same interface.  Just like
> powermacs have totally different sound systems and still use /dev/dsp.
> /proc/apm and /dev/apm_bios are so simple that it should be easy to convince
> any power management system to provide those API's.

The info logged to /proc/apm is currently logged to /etc/power/apm. I have
no idea what /dev/apm does aside from providing that log info, and I have
no clue what /dev/apm_bios does, either. There should be no major problems
duplicating the pmu logging code in the kernel, and interfacing that with
some apm glue code, assuming the apm interface is reasonably architecture
independent. I just don't see a good reason to change from pmud to apmd,
if that's what you're suggesting.

CC: to linuxppc-dev where this discussion really should be.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Avery Pennarun]

On Thu, Nov 23, 2000 at 09:47:13AM +0100, Michael Schmitz wrote:

> > Not APM support exactly... simply support for the same interface.  Just
> > like powermacs have totally different sound systems and still use
> > /dev/dsp.
> > /proc/apm and /dev/apm_bios are so simple that it should be easy to convince
> > any power management system to provide those API's.
>
> The info logged to /proc/apm is currently logged to /etc/power/apm. I have

Is this a typo?  Why is status information in /etc?

> no idea what /dev/apm does aside from providing that log info, and I have
> no clue what /dev/apm_bios does, either. There should be no major problems

The /dev device selects true for read() when a power event happens (such as
a user suspend request or battery status change) and can be written to allow
a user process to initiate a system suspend.

> independent. I just don't see a good reason to change from pmud to apmd,
> if that's what you're suggesting.

It's always better, IMHO, to keep Linux userspace as similar as possible
between different architectures.  If pmud has features that apmd doesn't
have, or vice versa, I would rather merge them than keep them separate.  In
the process, we might as well work on making the kernel interfaces similar
too.  That's the whole _point_ of the kernel.

Have fun,

Avery

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michel Dänzer]

Avery Pennarun wrote:

> > > Not APM support exactly... simply support for the same interface.  Just
> > > like powermacs have totally different sound systems and still use
> > > /dev/dsp.
> > > /proc/apm and /dev/apm_bios are so simple that it should be easy to
> > > convince any power management system to provide those API's.
> >
> > The info logged to /proc/apm is currently logged to /etc/power/apm. I have
>
> Is this a typo?  Why is status information in /etc?

Because it's from pmud, which can't create /proc entries.


> > independent. I just don't see a good reason to change from pmud to apmd,
> > if that's what you're suggesting.
>
> It's always better, IMHO, to keep Linux userspace as similar as possible
> between different architectures.  If pmud has features that apmd doesn't
> have, or vice versa, I would rather merge them than keep them separate.  In
> the process, we might as well work on making the kernel interfaces similar
> too.  That's the whole _point_ of the kernel.

I agree there.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Avery Pennarun]

On Thu, Nov 23, 2000 at 11:40:15AM +0100, Michel Dänzer wrote:

> > > > /proc/apm and /dev/apm_bios are so simple that it should be easy to
> > > > convince any power management system to provide those API's.
> > >
> > > The info logged to /proc/apm is currently logged to /etc/power/apm. I
> >
> > Is this a typo?  Why is status information in /etc?
>
> Because it's from pmud, which can't create /proc entries.

Then it should go in /var, I think.  We have standards for this stuff.
(FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and
/usr too, while I'm at it)... and this sounds like it would prevent me from
doing so.

Thanks,

Avery


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> > > > The info logged to /proc/apm is currently logged to /etc/power/apm. I
> > >
> > > Is this a typo?  Why is status information in /etc?
> >
> > Because it's from pmud, which can't create /proc entries.
>
> Then it should go in /var, I think.  We have standards for this stuff.
> (FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and

Granted. pmud was first packaged for LinuxPPC which is rpm based and cares
about FHS about as much as RedHat does. I'll look for a better place to
stick the fifo.

Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Avery Pennarun]

On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:

> Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)

Symlink it to /proc/mounts, of course. :)

/etc/mtab has always been evil, and not just because it's in the wrong
directory.  It's about equivalent to the "route" or "ipchains" commands
keeping track of what _they_ thought the kernel settings were, and then if
you tried to list the routes or firewall rules, they would just cat the
file.  Yuck.

Have fun,

Avery

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:
>
> > Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
>
> Symlink it to /proc/mounts, of course. :)

Good answer. I'd have used a symlink to some writeable directory on the
root fs, mainly because using /proc all over the place tends to confuse
Unix admins with no Linux experience. Let's not fall into the Solaris trap
(you are in a maze of twisty little config files, all different from the
rest of Unix').

> /etc/mtab has always been evil, and not just because it's in the wrong
> directory.  It's about equivalent to the "route" or "ipchains" commands
> keeping track of what _they_ thought the kernel settings were, and then if
> you tried to list the routes or firewall rules, they would just cat the
> file.  Yuck.

It's not elegant, more something of a historic wart ... Unix is full of
that :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Thu, 23 Nov 2000, Michael Schmitz wrote:

>
> > On Thu, Nov 23, 2000 at 12:15:32PM +0100, Michael Schmitz wrote:
> >
> > > Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
> >
> > Symlink it to /proc/mounts, of course. :)
>
> Good answer. I'd have used a symlink to some writeable directory on the
> root fs, mainly because using /proc all over the place tends to confuse
> Unix admins with no Linux experience. Let's not fall into the Solaris trap
> (you are in a maze of twisty little config files, all different from the
> rest of Unix').

At boot, before the first mount command executes, there may be _no_
writable directory and there may be none for a while, and you have the
problem of having an existing non-empty /etc/mtab (or equivalent) from a
non-clean shutdown which you would have to erase before the first mount is
done (adding another funky option to mount). Unless you make some kind of
ramdisk compulsory, which might not be bad idea after all with current
memory sizes.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> > Good answer. I'd have used a symlink to some writeable directory on the
> > root fs, mainly because using /proc all over the place tends to confuse
> > Unix admins with no Linux experience. Let's not fall into the Solaris trap
> > (you are in a maze of twisty little config files, all different from the
> > rest of Unix').
>
> At boot, before the first mount command executes, there may be _no_
> writable directory and there may be none for a while, and you have the
> problem of having an existing non-empty /etc/mtab (or equivalent) from a

The init scripts of all distributions but SuSE handle this just fine
(mount -n). At least SuSE seems to mount the root fs rw from the start,
which causes all sorts of pain if you want to boot into a RedHat system
using the SuSE rescue disk. No idea how SuSE copes with readonly root fs.

Anyway, this wasn't the issue initially. It seems /proc/apm should be
doable on PPC for programs that don't use apmlib, and the apmlib glue code
takes care of the others.

> non-clean shutdown which you would have to erase before the first mount is
> done (adding another funky option to mount). Unless you make some kind of
> ramdisk compulsory, which might not be bad idea after all with current
> memory sizes.

Yeah, like Linux will never run on my old 4 MB Mac anyway.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Thu, 23 Nov 2000, Michael Schmitz wrote:

> The init scripts of all distributions but SuSE handle this just fine
> (mount -n). At least SuSE seems to mount the root fs rw from the start,
> which causes all sorts of pain if you want to boot into a RedHat system
> using the SuSE rescue disk. No idea how SuSE copes with readonly root fs.

Yes, but read my previous posts. I consider the -n and -f mount options to
be a kludge. There is a chicken and egg problem and the workaround is a
kludge. The list of mounted file systems should be maintained by the
kernel IMHO, since the kernel has to know them in any case.

Mouting root read/write too early is even worse. That's no problem
since Suse waits for root fs to be checked before remounting rw. But Suse
has otehr problems when you want to maximize sharing on diskless systems
(init scripts in /sbin for one).

> > non-clean shutdown which you would have to erase before the first mount is
> > done (adding another funky option to mount). Unless you make some kind of
> > ramdisk compulsory, which might not be bad idea after all with current
> > memory sizes.
>
> Yeah, like Linux will never run on my old 4 MB Mac anyway.

BTW: what is the minimum RAM to run Liunx/PPC these days ? My smallest
(quasi embedded) machines have 16Mb and I hope to keep these running for
at least 5 to 7 more years.


	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Takashi Oe]

On 11/24/00 8:23 AM, Gabriel Paubert wrote:

[...]
> BTW: what is the minimum RAM to run Liunx/PPC these days ? My smallest
> (quasi embedded) machines have 16Mb and I hope to keep these running for
> at least 5 to 7 more years.

2.4.x runs reasonably well on a 8Mb machine here.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Olaf Hering]

On Thu, Nov 23, Michael Schmitz wrote:

> The init scripts of all distributions but SuSE handle this just fine
> (mount -n). At least SuSE seems to mount the root fs rw from the start,
> which causes all sorts of pain if you want to boot into a RedHat system
> using the SuSE rescue disk. No idea how SuSE copes with readonly root fs.

It doesnt work per default, some guys did some hacks to the boot scripts
to have a readonly root fs.
Well, but most users want to story something on their hard drives so it
doesnt work per default. Have a look at support.suse.de, there is (proably)
some info about readonly root.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> > using the SuSE rescue disk. No idea how SuSE copes with readonly root fs.
>
> It doesnt work per default, some guys did some hacks to the boot scripts
> to have a readonly root fs.
> Well, but most users want to story something on their hard drives so it

Everybody seems to use hard disks for storage these days, but some sort of
agreement to have the kernel initially mount root readonly evolved
nonetheless (at least four years ago the kernel default mount option was
changed). It's just about convenience and checking the root fs every time
on boot.

> doesnt work per default. Have a look at support.suse.de, there is (proably)
> some info about readonly root.

I'll take a look there.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Thu, 23 Nov 2000, Avery Pennarun wrote:

> Then it should go in /var, I think.  We have standards for this stuff.
> (FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and
> /usr too, while I'm at it)... and this sounds like it would prevent me from
> doing so.

On Thu, 23 Nov 2000, Michael Schmitz wrote:

> Granted. pmud was first packaged for LinuxPPC which is rpm based and cares
> about FHS about as much as RedHat does. I'll look for a better place to
> stick the fifo.
>
> Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)
>
> 	Michael

I agree that power management status/log should go to /var. On the other
hand /etc has to be on the root fs for several reasons (/etc/inittab among
others is quite important): IOW you don't use a separate mount point for
/etc unless you want to play dirty tricks with init.

Of cuorse there is a precedent for modifying /etc: /etc/mtab, but
admittedly for good reasons. mount also puts lock files in /etc and has to
have these funky option (-n and -f) to work around the chicken and egg
problem of initial read only root filesystem mount by the kernel. Once you
have these option I don't see any reason not to have /var/mtab instead for
example but maybe I miss something.

Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
should be able to link /etc/mtab to /proc/mounts but it raises a lot of
problems and does not work satifactorily in my experience.

I have a setup of a lot of different diskless machines which share
basically everything: /usr and /home on the same mount point, and almost
all files in the root directories are hardlinked, except for files in
/etc and /var, where it turned out to be impossible (and I don't mind an
additional megabyte or so of disk space per diskless system, it's still
about 99.9% shared).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Tony Mantler]

At 5:37 AM -0600 11/23/2000, Gabriel Paubert wrote:
[...]
>I agree that power management status/log should go to /var. On the other
>hand /etc has to be on the root fs for several reasons (/etc/inittab among
>others is quite important): IOW you don't use a separate mount point for
>/etc unless you want to play dirty tricks with init.
>
>Of cuorse there is a precedent for modifying /etc: /etc/mtab, but
>admittedly for good reasons. mount also puts lock files in /etc and has to
>have these funky option (-n and -f) to work around the chicken and egg
>problem of initial read only root filesystem mount by the kernel. Once you
>have these option I don't see any reason not to have /var/mtab instead for
>example but maybe I miss something.
>
>Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
>should be able to link /etc/mtab to /proc/mounts but it raises a lot of
>problems and does not work satifactorily in my experience.
[...]

I think technically the /proc filesystem is optional. Requiring /proc for
mount to function gives you another fun chicken + egg of how the heck do
you then mount /proc on startup? ;)

At the risk of drifting way off topic, it might be worth looking at
rewriting mount and fellow /etc/mtab users to just never need to use a file
like /etc/mtab. I can particularily recall a few times where a stale,
unwritable /etc/mtab made some system reconfiguration and/or system
recovery about 5 times more annoying than it needed to be.

30 years of unix tradition be damned, /etc/mtab sucks.


As for pmud, why not use a socket interface for everything? Using loopback
tcp  in one place and a file in another place seems a bit silly to me.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Thu, 23 Nov 2000, Tony Mantler wrote:

> >Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
> >should be able to link /etc/mtab to /proc/mounts but it raises a lot of
> >problems and does not work satifactorily in my experience.
> [...]
>
> I think technically the /proc filesystem is optional. Requiring /proc for
> mount to function gives you another fun chicken + egg of how the heck do
> you then mount /proc on startup? ;)

Because mount stats /etc/mtab and does not touch it if it finds that it is
a symlink. But this has still problem, I just can't remember which ones. I
know that I thought it would be great and had to go back to the standard
/etc/mtab.

Indeed proc is optional, but in practice it has become a necessary evil.
Most systems won't boot without it, hey most init scripts now have a look
at /proc/cmdline and whatnots. Ugly as hell...

> At the risk of drifting way off topic, it might be worth looking at
> rewriting mount and fellow /etc/mtab users to just never need to use a file
> like /etc/mtab. I can particularily recall a few times where a stale,
> unwritable /etc/mtab made some system reconfiguration and/or system
> recovery about 5 times more annoying than it needed to be.
>
> 30 years of unix tradition be damned, /etc/mtab sucks.

Indeed.

	Cheers,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Adrian Cox]

Gabriel Paubert wrote:
> Because mount stats /etc/mtab and does not touch it if it finds that it is
> a symlink. But this has still problem, I just can't remember which ones. I
> know that I thought it would be great and had to go back to the standard
> /etc/mtab.

See http://www.xss.co.at/sysinfo/mounts.html

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Thu, 23 Nov 2000, Adrian Cox wrote:

>
> Gabriel Paubert wrote:
> > Because mount stats /etc/mtab and does not touch it if it finds that it is
> > a symlink. But this has still problem, I just can't remember which ones. I
> > know that I thought it would be great and had to go back to the standard
> > /etc/mtab.
>
> See http://www.xss.co.at/sysinfo/mounts.html

Thanks for the pointer. Now that I see it, I remember that the major
problem I had on the diskless machines was that /proc/mounts did not have
enough information, especially for the root mount point when it is an NFS
mount. The root mount point always appears as /dev/root BTW.

	Thanks,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Josh Huber]

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

On Thu, Nov 23, 2000 at 11:40:15AM +0100, Michel wrote:
> Avery Pennarun wrote:
>
> > Is this a typo?  Why is status information in /etc?
>
> Because it's from pmud, which can't create /proc entries.

I think his problem was with the fact that it's in /etc, when it
should be in /var.

> > It's always better, IMHO, to keep Linux userspace as similar as possible
> > between different architectures.  If pmud has features that apmd doesn't
> > have, or vice versa, I would rather merge them than keep them separate.  In
> > the process, we might as well work on making the kernel interfaces similar
> > too.  That's the whole _point_ of the kernel.
>
> I agree there.

Yes, I've thought this would be a good idea for a while
now...Definately think it's a good idea. hmm...

--
Josh Huber                                   | huber@debian.org |
                                             | Debian Developer |
1024D/6B21489A 61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: apmd and other archs

[Michael Schmitz]

> > The info logged to /proc/apm is currently logged to /etc/power/apm. I have
>
> Is this a typo?  Why is status information in /etc?

Because user space pmud can't create /proc/ entries?

> > no idea what /dev/apm does aside from providing that log info, and I have
> > no clue what /dev/apm_bios does, either. There should be no major problems
>
> The /dev device selects true for read() when a power event happens (such as
> a user suspend request or battery status change) and can be written to allow
> a user process to initiate a system suspend.

We use a TCP port on the loopback interface for that.

> > independent. I just don't see a good reason to change from pmud to
apmd,
> > if that's what you're suggesting.
>
> It's always better, IMHO, to keep Linux userspace as similar as possible

Granted, if that doesn't place a high burden on the kernel code. I thought
'keep it simple, stupid' was the kernel motto?

> between different architectures.  If pmud has features that apmd doesn't
> have, or vice versa, I would rather merge them than keep them separate.  In
> the process, we might as well work on making the kernel interfaces similar
> too.  That's the whole _point_ of the kernel.

I beg to differ. The whole point of the kernel is to separate critical
code and architecture dependant things from user space. It's not about
making interfaces as similar as possible. If the hardware is sufficiently
different, a different kernel interface is OK. That's why no one
implemented a VGA compatibility layer in the kernel for PPC, m68k and a
few other archs.

It all boils down to: how generic is the apm interface?

Side note: I only maintain the Debian package of pmud. The pmud author is
Stephan Leemburg <stephan@jvc.nl>.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Hadess]

Quoting Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>:

> > > The info logged to /proc/apm is currently logged to /etc/power/apm.
> I have
> >
> > Is this a typo?  Why is status information in /etc?
>
> Because user space pmud can't create /proc/ entries?
>
> > > no idea what /dev/apm does aside from providing that log info, and I
> have
> > > no clue what /dev/apm_bios does, either. There should be no major
> problems
> >
> > The /dev device selects true for read() when a power event happens
> (such as
> > a user suspend request or battery status change) and can be written to
> allow
> > a user process to initiate a system suspend.
>
> We use a TCP port on the loopback interface for that.
>
> > > independent. I just don't see a good reason to change from pmud to
> apmd,
> > > if that's what you're suggesting.
> >
> > It's always better, IMHO, to keep Linux userspace as similar as
> possible
>
> Granted, if that doesn't place a high burden on the kernel code. I
> thought
> 'keep it simple, stupid' was the kernel motto?
>
> > between different architectures.  If pmud has features that apmd
> doesn't
> > have, or vice versa, I would rather merge them than keep them
> separate.  In
> > the process, we might as well work on making the kernel interfaces
> similar
> > too.  That's the whole _point_ of the kernel.
>
> I beg to differ. The whole point of the kernel is to separate critical
> code and architecture dependant things from user space. It's not about
> making interfaces as similar as possible. If the hardware is
> sufficiently
> different, a different kernel interface is OK. That's why no one
> implemented a VGA compatibility layer in the kernel for PPC, m68k and a
> few other archs.
>
> It all boils down to: how generic is the apm interface?

Hi,

Seems like I missed a good part of the discussion... First reason I wanted apmd
marked as x86 only, is because it is useless _now_ on power-pc. We have a PMU,
not an APM BIOS (ugh!), we have pmud not apmd. What is the point compiling it
for powerpc if it's not working and will probably never ?

We have here a big fat hardware difference. A PMU's a PMU, and an APM BIOS's an
APM BIOS. I'm now working (with help from Joseph Garcia) on an APM library for
PMUD. It hides PMUD from the libapm-using battery applets. I posted last week a
first "socket" version that uses the TCP socket on the loopback interface to get
its information. And I could compile some programs from the apmd distribution
and battstat with it.

I'm working right now on 1) Debugging socket version, 2) Implementing a version
getting its info from /etc/power/apm (soon to be moved, better tell Stephan I
guess), 3) Implement the rest of the functions from the apm library (like sleep
and everything...)

IMHO, an apm interface in the kernel would be "evil", that's a (simple)
userspace job.

Cheers

/Hadess
http://hadess.net

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> We have here a big fat hardware difference. A PMU's a PMU, and an APM BIOS's an
> APM BIOS. I'm now working (with help from Joseph Garcia) on an APM library for
> PMUD. It hides PMUD from the libapm-using battery applets. I posted last week a
> first "socket" version that uses the TCP socket on the loopback interface to get
> its information. And I could compile some programs from the apmd distribution
> and battstat with it.

Glad you mention it again - I didn't follow up on that on the spot and had
already forgotten this.

It seems this apm-pmud glue library would solve our problem in user space
entirely (except for apps that directly cat /proc/apm). The battery status
commands to the PMU are sent via /dev/adb and I'm not sure how this can
be safely done from kernel code.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> It seems this apm-pmud glue library would solve our problem in user space
> entirely (except for apps that directly cat /proc/apm). The battery status
> commands to the PMU are sent via /dev/adb and I'm not sure how this can
> be safely done from kernel code.

My contribution to kernel bloat ... untested except on Lombard, the 3400
code needs testing and perhaps some work. Overall the code looks pretty
ugly, take it as a proof of concept only and improve as desired. Patch is
against 2.2.18-stable, the proc_register probably needs changing for 2.4.

Result: The vanilla gnome battery_applet now works for me (TM).

	Michael

--- include/linux/proc_fs.h.org	Sun Nov 26 23:05:16 2000
+++ include/linux/proc_fs.h	Sun Nov 26 23:05:40 2000
@@ -50,6 +50,7 @@
 	PROC_PARPORT,
 	PROC_PPC_HTAB,
 	PROC_STRAM,
+	PROC_APM,
 	PROC_SOUND,
 	PROC_MTRR, /* whether enabled or not */
 	PROC_FS
--- drivers/macintosh/via-pmu.c.org	Thu Nov 23 21:23:58 2000
+++ drivers/macintosh/via-pmu.c	Mon Nov 27 14:18:49 2000
@@ -21,6 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/delay.h>
 #include <linux/sched.h>
+#include <linux/proc_fs.h>
 #include <linux/miscdevice.h>
 #include <linux/blkdev.h>
 #include <linux/pci.h>
@@ -135,6 +136,7 @@
 static int pmu_set_backlight_enable(int on, int level, void* data);
 #ifdef CONFIG_PMAC_PBOOK
 static void pmu_pass_intr(unsigned char *data, int len);
+static int pmu_get_proc_info(char *buf, char **start, off_t fpos, int length, int dummy);
 #endif

 static struct adb_controller	pmu_controller = {
@@ -331,6 +333,15 @@
 	} while (pmu_state != idle);
 }

+int pmu_get_proc_info(char *, char **, off_t, int, int);
+
+static struct proc_dir_entry proc_apm_info = {
+	PROC_APM, 3, "apm",
+	S_IFREG | S_IRUGO, 1, 0, 0,
+	0, &proc_array_inode_operations,
+	pmu_get_proc_info
+};
+
 static int __openfirmware
 init_pmu()
 {
@@ -372,6 +383,9 @@
 			pmu_poll();
 	}

+#ifdef CONFIG_PMAC_PBOOK
+	proc_register(&proc_root, &proc_apm_info);
+#endif
 	return 1;
 }

@@ -1911,6 +1925,247 @@
 {
 	if (via)
 		misc_register(&pmu_device);
+}
+
+#define APM_CRITICAL		10
+#define APM_LOW			30
+
+static char			driver_version[] = "1.13";	/* no spaces */
+
+static int
+pmu_get_proc_info(char *buf, char **start, off_t fpos, int length, int dummy)
+{
+	char *		p;
+	unsigned short  battery_status = 0xff;
+	unsigned short  battery_flag   = 0xff;
+	int		percentage     = -1;
+	int             time_units     = -1;
+	char            *units         = "?";
+	unsigned short  fake_apm_bios_info_version = (1<<8);
+	unsigned short  fake_apm_bios_info_flags   = 0x0a;
+	int charging, timeleft;
+	int pwr, vb, i, j, len=0, cnt=0;
+
+	struct adb_request req;
+
+	if (vias == NULL)
+		return 0;
+
+	if (pmu_kind == PMU_KEYLARGO_BASED)
+		return 0;
+
+	/*
+	 * The following code has been adapted from the pmud source by Stephan Leemburg.
+	 * It's a bit lengthy and could perhaps be shortened. 3400 code needs testing.
+	 */
+	if (pmu_kind == PMU_OHARE_BASED) {
+		/* 3400: use extended battery request (6b) */
+
+		int pcharge, charge=0;
+		int current=0;
+		int lrange[] = {   0,  275,  850, 1680, 2325,
+				2765, 3160, 3500, 3830, 4115,
+				4360, 4585, 4795, 4990, 5170,
+				5340, 5510, 5710, 5930, 6150,
+				6370, 6500
+				};
+
+		/* assemble request */
+		req.nbytes = 1;
+		req.done = NULL;
+		req.data[0] = PMU_BATTERY_STATE;
+		memset(&req.reply[0], 0, sizeof(req.reply));
+		req.reply_len = 0;
+		req.reply_expected = 1;
+
+		if (pmu_queue_request(&req) != 0) {
+			printk(KERN_ERR "pmu_get_battery_info: pmu_queue_request failed\n");
+			return 0;
+		}
+
+		while (!req.complete)
+			pmu_poll();
+
+		if (!req.reply_len) {
+			printk(KERN_ERR "pmu_get_battery_info: no reply\n");
+			return 0;
+		}
+#ifdef DEBUG_APM
+		printk("pmu_getinfo: reply len %d, data: ", req.reply_len);
+		for (i=0; i<req.reply_len; i++)
+			printk("%x ", req.reply[i]);
+		printk("\n");
+#endif
+		pwr = req.reply[0] & 1;			/* AC indicator */
+		charging = req.reply[0] & 2;
+		vb = (req.reply[1] << 8) + req.reply[2];	/* battery voltage */
+
+		if (!pwr) {
+			if (req.reply[5] > 200)
+		    		vb += ((req.reply[5] - 200) * 15) / 100;
+		} else if (charging)
+			vb -= 10;
+
+		i = (330 - vb) / 10;
+		j = (330 - vb);
+
+		if (i <= 0)
+			charge = 0;
+		else if (i >= 21)
+			charge = 6500;
+		else
+			charge = ((lrange[i+1]-lrange[i])*(j-(10*i))+10*lrange[i])/10;
+		charge = (10000 - charge / 65) / 100;
+
+		if (req.reply[0]&0x40) {
+			pcharge = (req.reply[6] << 8) + req.reply[7];//pcharge
+			if (pcharge > 6500)
+				pcharge = 6500;
+			pcharge = (10000 - pcharge / 65) / 100;
+			if (pcharge < charge)
+				charge = pcharge;
+		}
+		current=req.reply[5];
+		if (!pwr && (current > 0))
+			timeleft = (int)((charge * 274) / current) * 60;
+
+		percentage = charge;
+		if (percentage > 100)
+			percentage = 100;
+	} else {
+		/* wallstreet/lombard, use smart battery request (6f) */
+
+		signed short batt[5], batt1, batt2;
+		unsigned char par;
+		int charge, current, ndata;
+
+		pwr = 0;
+		charge = current = 0;
+		batt1 = batt2 = 0;
+
+		for (i = 0; i < 2; ++i) {
+			par = i + 1;
+
+			/* assemble request */
+			req.nbytes = 2;
+			req.done = NULL;
+			req.data[0] = PMU_SMART_BATT;
+			req.data[1] = par;
+			memset(&req.reply[0], 0, sizeof(req.reply));
+			req.reply_len = 0;
+			req.reply_expected = 1;
+			if (pmu_queue_request(&req) != 0) {
+				printk(KERN_ERR "pmu_get_battery_info: pmu_queue_request failed\n");
+				return 0;
+			}
+
+			while (!req.complete)
+				pmu_poll();
+
+			if (!req.reply_len) {
+				printk(KERN_ERR "pmu_get_battery_info: no reply\n");
+				return 0;
+			}
+#ifdef DEBUG_APM
+			printk("pmu_getinfo (%d): reply len %d, data: ", par, req.reply_len);
+			for (ii=0; ii<req.reply_len; ii++)
+				printk("%x ", req.reply[ii]);
+			printk("\n");
+#endif
+			/* PMU sent length byte; clear */
+			ndata        = req.reply[0];
+			req.reply[0] = 0;
+			memset(&batt[0], 0, sizeof(batt));
+			memcpy(&batt[0], &req.reply[0], req.reply_len);
+#ifdef DEBUG_APM
+			if (ndata > 0) {
+				printk("pmu_getinfo (%d): batt[] = ", par);
+				for (ii=0; ii<ndata; ii++)
+					printk("%d ", batt[ii]);
+				printk("\n");
+			}
+#endif
+			pwr |= batt[0] & 1;
+
+			if (batt[0] & 4) {
+				/* battery present */
+				charge += batt[1];
+				current += batt[3];
+				if (!i) {
+					batt1 = batt[1];
+					batt2 = batt[2];
+				} else {
+					batt1 += batt[1];
+					batt2 += batt[2];
+				}
+				percentage  = batt1 * 100;
+				percentage /= batt2 ? batt2 : 1;
+#ifdef DEBUG_APM
+				printk("pmu_getinfo: battery %d batt1 %d batt2 %d current %d\n",
+					par, batt[1], batt[2], batt[3]);
+#endif
+			}
+		}
+		/* charging flag valid and charging battery? */
+		charging = batt[0] & 0x02;
+		if (current < 0)
+			timeleft = charge * 3552 / -current;
+	}
+
+	/* compile apm pseudo info */
+	time_units = pwr ? 0 : timeleft;
+	units="sec";
+	if (timeleft > 600) {
+		time_units /= 60;
+		units = "min";
+	}
+	if (percentage <= APM_CRITICAL) {
+		battery_status = 0x02;
+		battery_flag  = 0x04;
+	} else if (percentage <= APM_LOW) {
+		battery_status = 0x01;
+		battery_flag  = 0x02;
+	} else {
+		battery_status = 0x00;
+		battery_flag  = 0x01;
+	}
+	if (charging) {
+		battery_status = 0x03;
+		battery_flag  |= 0x08;
+	}
+
+	/* Arguments, with symbols from linux/apm_bios.h. See arch/i386/kernel/apm.c */
+
+	p = buf;
+	len += sprintf(p, "%s %d.%d 0x%02x 0x%02x 0x%02x 0x%02x %d%% %d %s\n",
+		     driver_version,
+		     (fake_apm_bios_info_version >> 8) & 0xff,
+		     fake_apm_bios_info_version & 0xff,
+		     fake_apm_bios_info_flags,
+		     pwr,
+		     battery_status,
+		     battery_flag,
+		     percentage,
+		     time_units,
+		     units);
+
+	if (len >= fpos) {
+		if (start && !*start) {
+			*start = buf + fpos;
+			cnt = len - fpos;
+		} else {
+			cnt += len;
+		}
+	}
+	return (length > cnt) ? cnt : length;
+}
+
+/* wrapper for hardcoding proc entry in fs/proc/array.c */
+int get_pmuinfo(char *buf)
+{
+	if (pmu_kind == PMU_UNKNOWN)
+		return 0;
+	return pmu_get_proc_info(buf, NULL, 0, 256, 0);
 }
 #endif /* CONFIG_PMAC_PBOOK */


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Benjamin Herrenschmidt]

>My contribution to kernel bloat ... untested except on Lombard, the 3400
>code needs testing and perhaps some work. Overall the code looks pretty
>ugly, take it as a proof of concept only and improve as desired. Patch is
>against 2.2.18-stable, the proc_register probably needs changing for 2.4.
>
>Result: The vanilla gnome battery_applet now works for me (TM).

A better way would be to have the via-pmu driver asynchronously (via
a timer) poll for state change and update some static status datas.
This way, on core99, we can just disable the polling timer and rely
on automatic notifications done by the hw. The /proc interface would
then just output the last status.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> >Result: The vanilla gnome battery_applet now works for me (TM).
>
> A better way would be to have the via-pmu driver asynchronously (via
> a timer) poll for state change and update some static status datas.
> This way, on core99, we can just disable the polling timer and rely
> on automatic notifications done by the hw. The /proc interface would
> then just output the last status.

Just as fine. What routine is processing the automatic notification, and
what does the data format look like? I guess /dev/pmu will have to return
buffered data as well on core99?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Michael Schmitz]

> My contribution to kernel bloat ... untested except on Lombard, the 3400

Followup: I forgot the following little patch to pmu.h. Paul, BenH, can we
please get this into the kernel source?

	Michael

--- include/asm/pmu.h.org	Fri Nov 24 14:25:38 2000
+++ include/asm/pmu.h	Fri Nov 24 14:25:21 2000
@@ -23,6 +23,7 @@
 #define PMU_GET_VOLBUTTON	0x48	/* get volume up/down position */
 #define PMU_PCEJECT		0x4c	/* eject PC-card from slot */
 #define PMU_BATTERY_STATE	0x6b	/* report battery state etc. */
+#define PMU_SMART_BATT		0x6f	/* report smart battery state */
 #define PMU_SET_INTR_MASK	0x70	/* set PMU interrupt mask */
 #define PMU_INT_ACK		0x78	/* read interrupt bits */
 #define PMU_SHUTDOWN		0x7e	/* turn power off */
@@ -32,6 +33,7 @@
 #define PMU_GET_BRIGHTBUTTON	0xd9	/* report brightness up/down pos */
 #define PMU_GET_COVER		0xdc	/* report cover open/closed */
 #define PMU_SYSTEM_READY	0xdf	/* tell PMU we are awake */
+#define PMU_GET_VERSION		0xea	/* get pmu firmware version # */

 /* Bits to use with the PMU_POWER_CTRL0 command */
 #define PMU_POW0_ON		0x80	/* OR this to power ON the device */


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Benjamin Herrenschmidt]

>Hi,
>
>Seems like I missed a good part of the discussion... First reason I
>wanted apmd
>marked as x86 only, is because it is useless _now_ on power-pc. We have
a PMU,
>not an APM BIOS (ugh!), we have pmud not apmd. What is the point compiling it
>for powerpc if it's not working and will probably never ?

Don't mix PowerPC and PowerMac. PowerMacs rely on pmud. But PReP and CHRP
machines can be more PC-like that you'd like them to in some cases :)
They don't really have an apm bios, but who knows... They certainly don't
have a PMU and don't use pmud.

I've been told there's an IBM PReP thinkpad out there. What does this box
use for power management ? It's own mecanism ?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Bastien Nocera]

Quoting Benjamin Herrenschmidt <bh40@calva.net>:

> >Hi,
> >
> >Seems like I missed a good part of the discussion... First reason I
> >wanted apmd
> >marked as x86 only, is because it is useless _now_ on power-pc. We have
> a PMU,
> >not an APM BIOS (ugh!), we have pmud not apmd. What is the point
> compiling it
> >for powerpc if it's not working and will probably never ?
>
> Don't mix PowerPC and PowerMac. PowerMacs rely on pmud. But PReP and

I try not to...

> CHRP
> machines can be more PC-like that you'd like them to in some cases :)
> They don't really have an apm bios, but who knows... They certainly
> don't
> have a PMU and don't use pmud.
>
> I've been told there's an IBM PReP thinkpad out there. What does this
> box
> use for power management ? It's own mecanism ?

So, I made the incorrect assumption that the only PowerPC laptops out there were
Apple's. Blamme.

I have one question: desktops need to use the PMU for sleep as well, don't they
? Does pmud work on a desktop ? It would be nice if pmud was used as a gateway
between user-land applications (like a little sleep application, or a battery
monitor), and the kernel, in fact the PMU device.
AFAIK, apmd already does that, and apps (should) rely on libapm to avoid changes
on the underlying kernel.

We need at some point to make a decision. Right now we have:
1) PMU, handled by the kernel
2) pmud, giving a pseudo APM interface
3) apps using this pseudo interface

or
2) pmud, giving a PMU interface
3) apps using the directly the PMU

What I was trying to do with this libapm4pmud was:
2) pmud, giving a PMU interface
3) libapm sitting on top of pmud (either via the pmu or the apm interface)
4) Any application using libapm

What has been talked in this thread was:
2) having a /proc interface in the kernel for apm compatibility. I don't think
this is a good idea. Transforming data of this kind could be done in user-land
(like in a library).
1) APM interface for everything directly in the kernel. No good for me either.
The APM interface on PCs is pretty simple because you have the hardware (well
the BIOS) that gives away all the proper information. This is not the way to go,
like it's been said, Linux/PowerMac doesn't have a VGA emulation in the kernel,
so why an APM ?

I still think a libapm library for power macs is the way to go. If some day
somebody proves me wrong by providing an APM interface to the kernel, you'd just
have to recompile your application.
What I'd like to change is pmud to use a FIFO or a Unix Socket for advertising
its status, the TCP socket is just damn slow. Remove the apm interface. Use the
libapm library or directly the PMU interface. I like the idea of an event queue
for the newer Macs, APM already behaves like that, better than polling the
interface every second.

My 2 pennies.

/Bastien Nocera
http://hadess.net

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Benjamin Herrenschmidt]

>> Not APM support exactly... simply support for the same interface.
Just like
>> powermacs have totally different sound systems and still use /dev/dsp.
>> /proc/apm and /dev/apm_bios are so simple that it should be easy to
convince
>> any power management system to provide those API's.
>
>The info logged to /proc/apm is currently logged to /etc/power/apm. I have
>no idea what /dev/apm does aside from providing that log info, and I have
>no clue what /dev/apm_bios does, either. There should be no major problems
>duplicating the pmu logging code in the kernel, and interfacing that with
>some apm glue code, assuming the apm interface is reasonably architecture
>independent. I just don't see a good reason to change from pmud to apmd,
>if that's what you're suggesting.

At least one reason: the current pmud does continuous polling of the PMU
via /dev/pmu. On newer (core99) machines, the PMU itself will send
messages to the CPU when any environement info change (battery status,
lid closed, ...). We currently don't use this feature and so end up
communicating with the PMU more than we would really need.

We can "fix" that by either having the PMU driver on core99 continuously
send those infos via /dev/pmu without explicit request. It may also be
interesting to replace this by a kernel thread. That would allow more
flexibility in communicating with userland (things like signaling
processes that asked for it to be notified of a sleep request, etc...).

One other issue we have with sleep is that we need to prevent the kernel
to do a bunch of thigns while going to sleep. scheduling from within the
sleep ioctl is dangerous, but will happen occasionally, especially when
sleeping & waking up the IDE layer.

I beleive it should be possible to hack the scheduler so that only our
sleep thread gets scheduled at all (disabling scheduling on the main CPU
and freezing other CPUs in sleep loops) during the sleep & wakeup process.

Any better ideas ?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:

> We can "fix" that by either having the PMU driver on core99 continuously
> send those infos via /dev/pmu without explicit request. It may also be
> interesting to replace this by a kernel thread. That would allow more
> flexibility in communicating with userland (things like signaling
> processes that asked for it to be notified of a sleep request, etc...).

Could the recently added keventd thread be used for this? I don't like the
idea of adding kernel threads just for one thing. One kernel thread for
all relatively slow operations which may need a process context is
reasonable however.

> One other issue we have with sleep is that we need to prevent the kernel
> to do a bunch of thigns while going to sleep. scheduling from within the
> sleep ioctl is dangerous, but will happen occasionally, especially when
> sleeping & waking up the IDE layer.
>
> I beleive it should be possible to hack the scheduler so that only our
> sleep thread gets scheduled at all (disabling scheduling on the main CPU
> and freezing other CPUs in sleep loops) during the sleep & wakeup process.
>
> Any better ideas ?

No, I thought the deep sleep modes were only for laptops which are not SMP
unless I missed some recent Apple announcement ;-). Do SMP G4 truly
require complex power management ?

BTW: I dislike any idea of playing with the scheduler.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Benjamin Herrenschmidt]

>Could the recently added keventd thread be used for this? I don't like the
>idea of adding kernel threads just for one thing. One kernel thread for
>all relatively slow operations which may need a process context is
>reasonable however.

I'll investigate.

>No, I thought the deep sleep modes were only for laptops which are not SMP
>unless I missed some recent Apple announcement ;-). Do SMP G4 truly
>require complex power management ?

Yup. Almost all Apple recent machines can do power management in various
ways. Some can deep sleep (not only portables), all can switch off power
to some PCI devices & ASICs, some support turning off the CPU...

>BTW: I dislike any idea of playing with the scheduler.

Me too. The problem is that the IDE layer will always schedule if you do
something more complex that setting a few registers. scheduling in the
middle of putting things to sleep is bad, except is drivers that have
already been put to sleep can cope with it by just blocking userland IOs
or returning errors.

For other CPUs, I beleive we can go with a cross-CPU function call, the
called function putting the other CPU in a spin-loop. My problem with
that is that it happens all at interrupt time, which may not be the best
place to put the CPU to sleep. Maybe I can manage to schedule a bottom
half or soemthing like that.

Apple's code is smarter in that sense that they can apparently easily
turn CPUs on/off (putting them in sleep loops when they are off), causing
all processes to migrate to the still running CPU. However, AFAIK, their
current Darwin kernel cannot sleep on SMP machines properly neither yet.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:

> Yup. Almost all Apple recent machines can do power management in various
> ways. Some can deep sleep (not only portables), all can switch off power
> to some PCI devices & ASICs, some support turning off the CPU...

Ok, I don't see very much the point of saving fractions of watt on a
desktop but...

> >BTW: I dislike any idea of playing with the scheduler.
>
> Me too. The problem is that the IDE layer will always schedule if you do
> something more complex that setting a few registers. scheduling in the
> middle of putting things to sleep is bad, except is drivers that have
> already been put to sleep can cope with it by just blocking userland IOs
> or returning errors.

Returning errors to user mode looks like a bad idea, it should be
absolutely transparent to applications.

> For other CPUs, I beleive we can go with a cross-CPU function call, the
> called function putting the other CPU in a spin-loop. My problem with
> that is that it happens all at interrupt time, which may not be the best
> place to put the CPU to sleep. Maybe I can manage to schedule a bottom
> half or soemthing like that.

I'm lost. Can't power management be done by the idle task ? There is one
per CPU but it can't handle signala AFAIR. After all power management
seems better handled by a task which never does I/O and whose only purpose
is to sleep...

> Apple's code is smarter in that sense that they can apparently easily
> turn CPUs on/off (putting them in sleep loops when they are off), causing
> all processes to migrate to the still running CPU. However, AFAIK, their
> current Darwin kernel cannot sleep on SMP machines properly neither yet.

What do you call a sleep loop ?

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Benjamin Herrenschmidt]

>Ok, I don't see very much the point of saving fractions of watt on a
>desktop but...

It can be more than fraction of watts when you put it all together, especially
in deep sleep. And multiply that by the number of machines out there...

Also, the Cube is sensitive to heat problems, having some power
management (and CPU temp control, but that's another issue) helps.

>Returning errors to user mode looks like a bad idea, it should be
>absolutely transparent to applications.

Well, that depends. I prefer blocking them, definitely, but that may not
always be possible.
Some things can just not be handled this way. We cannot, for example,
afford to schedule (or even printk) after the video driver have put the
chip to sleep. That's why we have these ordering rules x86 lacks, so that
we can sleep this driver very late in the sleep process, and wake it up
first. In the case of SMP boxes, we would have needed to put the other
CPUs to sleep before that point.

>I'm lost. Can't power management be done by the idle task ? There is one
>per CPU but it can't handle signala AFAIR. After all power management
>seems better handled by a task which never does I/O and whose only purpose
>is to sleep...

That could be done this way too. Are there any guarantees that the idle
task will run at all, however, if a process is using all the available
CPU time ? If we need all processors to stop scheduling userland code and
wait in a sleep loop (not doze nor nap in this case), we need to have a
way to let the idle task know that we need it to enter this special sleep
stage ASAP. It will have to flush all caches properly and go to sleep. On
some boxes, the CPU(s) will be shut down and revived via ROM hooks.

>What do you call a sleep loop ?

An infinite loop where the CPU goes to sleep mode. It exists via an
external reset or CPU shut down.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Geert Uytterhoeven]

On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
> >Ok, I don't see very much the point of saving fractions of watt on a
> >desktop but...
>
> It can be more than fraction of watts when you put it all together, especially
> in deep sleep. And multiply that by the number of machines out there...
>
> Also, the Cube is sensitive to heat problems, having some power
> management (and CPU temp control, but that's another issue) helps.

That's what I call `solving hardware problems by software'. Gives some bonus
points in the old Hackers' Test :-)

> >I'm lost. Can't power management be done by the idle task ? There is one
> >per CPU but it can't handle signala AFAIR. After all power management
> >seems better handled by a task which never does I/O and whose only purpose
> >is to sleep...
>
> That could be done this way too. Are there any guarantees that the idle
> task will run at all, however, if a process is using all the available
> CPU time ? If we need all processors to stop scheduling userland code and
> wait in a sleep loop (not doze nor nap in this case), we need to have a
> way to let the idle task know that we need it to enter this special sleep
> stage ASAP. It will have to flush all caches properly and go to sleep. On
> some boxes, the CPU(s) will be shut down and revived via ROM hooks.
>
> >What do you call a sleep loop ?
>
> An infinite loop where the CPU goes to sleep mode. It exists via an
> external reset or CPU shut down.

What about putting all CPUs except one to sleep at night?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: apmd and other archs

[Gabriel Paubert]

On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:

> >Ok, I don't see very much the point of saving fractions of watt on a
> >desktop but...
>
> It can be more than fraction of watts when you put it all together, especially
> in deep sleep. And multiply that by the number of machines out there...

Don't worry. Intel and M$ contribute much more to global warming :-)

> Also, the Cube is sensitive to heat problems, having some power
> management (and CPU temp control, but that's another issue) helps.

Ok, style over substance. Remind me to never buy a cube...

>
> >Returning errors to user mode looks like a bad idea, it should be
> >absolutely transparent to applications.
>
> Well, that depends. I prefer blocking them, definitely, but that may not
> always be possible.
> Some things can just not be handled this way. We cannot, for example,
> afford to schedule (or even printk) after the video driver have put the
> chip to sleep. That's why we have these ordering rules x86 lacks, so that
> we can sleep this driver very late in the sleep process, and wake it up
> first. In the case of SMP boxes, we would have needed to put the other
> CPUs to sleep before that point.
>
> >I'm lost. Can't power management be done by the idle task ? There is one
> >per CPU but it can't handle signala AFAIR. After all power management
> >seems better handled by a task which never does I/O and whose only purpose
> >is to sleep...
>
> That could be done this way too. Are there any guarantees that the idle
> task will run at all, however, if a process is using all the available
> CPU time ? If we need all processors to stop scheduling userland code and
> wait in a sleep loop (not doze nor nap in this case), we need to have a
> way to let the idle task know that we need it to enter this special sleep
> stage ASAP. It will have to flush all caches properly and go to sleep. On
> some boxes, the CPU(s) will be shut down and revived via ROM hooks.

I believe the idle task blocks all signals, but once in the idle task you
can check for pending signals (signal_pending(current)) which would be a
way to communicate with it. It might be necessary to raise the priority of
the idle task when you send it a signal (and set need_resched to schedule
asap). The idle task would lower its own priority later when exiting from
sleep. This might be a way to provide a known clean context for power
management (and there is one idle task per processor as I said earlier).
The scheduler should not need any change. Of course raising the priority
of the idle task may seem strange, but when you risk overheating, it's
urgent to become idle...

BTW: I don't want to ever enter sleep state on my machines, a stopped
timebase would be a catastrophe when you need accurate timestamps. Nap and
doze are still ok, currently only the first level is entered. I'm not even
sure it's worth going to the second level on machines which have a
continuous stream of interrupts at >100Hz, flushing and reloading the
cache at this rate is probably not a power saving measure when the active
part of the memory fits in the L2 cache.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/