[OLPC-devel] Re: Why ACPI DSDT tables?

[David Woodhouse]

On Mon, 2006-07-10 at 22:25 +0200, Stefan Reinauer wrote:
> * David Woodhouse <dwmw2 at infradead.org> [060710 21:18]:
> > > I hate writing new interfaces, but is it worth the pain of making
> > > ACPI work just so we don't have to do any work in the kernel to get
> > > the battery status? 
> > 
> > Definitely not. Even if we end up 'emulating' /proc/apm like everyone
> > else does, instead of taking this opportunity to fix the kernel<->user 
> > interface properly, it's better to do it with proper drivers.
> 
> What we want is a clean design. Ok, ACPI is not. Emulating /proc/apm is
> neither.

I agree.

> The kernel<->user interface is crap, as it is in fact a stripped down
> version of a very specific firmware<->kernel interface. We might not
> want to fix this problem in _this_ scope.

True. But if we're going to choose some crap to be compatible with, it
might as well be /proc/apm -- it's simple and there's plenty of examples
of that. I suppose we _could_ also emulate the battery stuff
in /proc/acpi instead of doing /proc/apm -- without going through the
whole ACPI/AML abomination.

> When we're looking at firmware<->kernel or rather hardware<->kernel if
> we omit acpi, it really does not matter too much where we settle the
> relevant code except for some implementational details.

Whoa. You weren't talking about {firmware,hardware}<->kernel above. You
were talking about kernel<->user.

I don't mind much about the kernel<->user interface. Ideally, we should
fix it and define a proper interface which APM, PMU, ACPI, as well as
the multitude of embedded boards with real driver can conform to. I'd
settle for emulating /proc/apm or /proc/acpi if we really have to,
though.

Now, context-switching to the entirely different topic of
hardware<->kernel interface. In the general case, the kernel runs
directly on hardware, rather than trusting firmware. Trusting firmware
is always a bad plan. Witness the shiny new i810 'modesetting' driver
which no longer uses the BIOS, for the latest example of such.

> I have been implementing a lot of ACPI in LinuxBIOS because there
> are setups that are simply impossible to boot with Linux otherwise.
> No hardware reason, just design of the code flow. Fixing the kernel
> would have exceeded any available resources (and probably made me a lot
> of enemies with all the untested boards out there)

You're talking about boards for which we have no documentation, because
manufacturers have deliberately hidden behind the interface which ACPI
allows -- and given us binary-only code which we have no option but to
use. That isn't strictly relevant to OLPC, where we _do_ have proper
hardware documentation and we can do Free Software on it entirely.

> So before we talk in big words of ACPI or no ACPI, what parts do we
> need from userspace:

Now you've gone back to talking about kernel<->user interface again. OK,
so switching back to that....

>  * cpu powerstates

cpufreq provides a userspace interface for this. But the Geode doesn't
really have a decent selection of CPU power states anyway.

>  * display powerstates

fbdev should handle this. When X makes use of it, it should do so
through fbdev.

>  * other parts of the system that can be powered down?

How is this currently handled? Through sysfs?

>  * poweroff, reboot, halt

The user interface for these is sys_reboot().

-- 
dwmw2