Subject: Re: power management and idle detection on non-x86
To: Garrett D'Amore <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 05/08/2006 12:25:14
-----BEGIN PGP SIGNED MESSAGE-----
> On one system, the backlight is managed via an LPC chip that takes
> commands over an embedded RS232 port. NetBSD isn't likely to be ported
> to that system, but that system *is* likely to be used as a template
> new platforms to which a NetBSD port would be useful.
That's exactly how you control backlight on both the sparcbook and
(most) Apple *books - you send commands to some sort of microcontroller
over a serial interface ( tctrl on the sparcbook, PMU/Cuda on Macs )
>>> Now, policy needs to be set in userland.
>> Of course. But it shouldn't depend on something like X and it should
>> probably work reasonably without userland intervention.
> Hmmm.... mixed feelings here. I like the powerd approach, where
> scripts, etc. can be used. But I think it is also useful for kernel
> entities to be able to both register to receive events (e.g. flush data
> to non-volatile storage, etc.), and to be able to inject or trigger
I was thinking about timeouts here, not anything complex. I'm not
proposing to implement sleep or anything like that without powerd. The
kernel should just signal 'extended idle' and related events without
anyone having to tell it so.
>> Yeah, X wants to know when we're going to sleep / wake up so it can do
>> its voodoo with the graphics chip(s). I think something like that is
>> in place already but probably linux-specific.
> There's a bunch of Linux power management crapola in the video drivers.
> Sleep/wake is "especially" interesting, because some of these video
> parts have unique initialization considerations. When running Xwsfb on
> non-PC hardware, we might need the underlying wsdisplay to do the
I'd feel a lot more comfortable with this stuff in the kernel. But this
would require that the kernel knows what kind of video mode X
programmed which isn't quite feasible right now, mainly because we
don't have specific kernel drivers for all video chipsets, at least not
on x86 and macppc. On the sparcbook it would be almost trivial though -
all we need is a bunch of ioctl()s to program video modes.
>>>>> So, before I'm wasting my time inventing the wheel the 5th time -
>>>>> do we have something like this somewhere in the kernel? Should it
>>>>> integrated with powerd? What about powerd vs. apmd? Their scopes
>>>>> to overlap quite a bit.
>>>> apmd is dead; the future is powerd.
>> Ok, that's what my sparcbook is running.
> Looking at powerd, it looks like the way to go. But I cannot find any
> really useful on kernel APIs. The powerd manual page references ACPI
> man pages. (I guess there is the powerhook(9) man info...)
Look at the stuff in dev/sysmon/ - so far you can register certain
event sources with the events themselves ending up in powerd or if
there's no powerd running it will attempt to Do The Right Thing on its
own ( like initiating a shutdown when the power button is pressed )
This would need to be extended. In tctrl ( arch/sparc/dev/tctrl.c ) I'm
sending events about the lid switch, the power button and the AC
adaptor ( connected or not ).
Which reminds me - just to check if shutdown on low battery works
properly I pulled the sparcbook's plug yesterday. It started bitching
about low batter almost immediately ( the battery is old but some
friend refreshed the cells a while ago ) - and continued doing so for
almost an hour. Then it powered off. Apparently it shut down cleanly
since filesystems didn't need checking. I wonder what triggers the low
power event, maybe the microcontroller expects more than 12v from the
So, should we emulate ACPI on non-x86 to make life easier? I had a
short look at dev/acpi/ and I do't think I could provide all the data
an ACPI battery would. The microcontroller only gives me a voltage,
some estimated charge level and I can control wether to charge the
battery or not.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----