From: Pavel Machek <pavel@suse.cz>
To: Stefan Seyfried <seife@suse.de>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
linux-pm@lists.osdl.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] [1/3] Generic in-kernel AC status
Date: Fri, 10 Feb 2006 14:46:38 +0100 [thread overview]
Message-ID: <20060210134638.GA5109@elf.ucw.cz> (raw)
In-Reply-To: <20060210123259.GB18577@suse.de>
On Pá 10-02-06 13:32:59, Stefan Seyfried wrote:
> On Fri, Feb 10, 2006 at 01:19:13PM +0100, Pavel Machek wrote:
> > On Pá 10-02-06 09:06:43, Stefan Seyfried wrote:
>
> > > Ok. Maybe i am not seeing the point. But why do we need this in the kernel?
> > > Can't we handles this easily in userspace?
> >
> > Some kernel parts need to now: for example powernow-k8: some
>
> we can tell them from userspace.
No, because battery will explode if you do not slow cpu down fast
enough. And it would be extremely ugly.
Right now, interfaces we have are:
/proc/apm -- to get AC/DC info on APM
/proc/acpi/ac_adapter/*/state -- to get in on ACPI
...then we have...
in-kernel interface to get AC/DC info on APM, and in-kernel interface
to get AC/DC info on ACPI (powernow-k8 needs it). Brightness needs to
use those interfaces, too.
With your proposed solution, we'd have to add
/proc/powernow_k8/you_are_on_ac and /proc/backlight/you_are_on_ac and
..., or something, along with daemon to poll /proc/apm and
/proc/acpi/*/*/state (and whatever else embedded machines do), and
feed it back to kernel.
That's clearly wrong thing to do. So Matthew patch is actually
cleanup. It should allow us to kill special interfaces and have
something like /sys/power/ac ... and not having to introduce special
interfaces for pn-k8, backlight and more.
(More responses in separate thread.)
> > frequencies are not allowed when you are running off battery. [Just
> > now it is solved by not allowing those frequencies at all unless ACPI
> > is available; quite an ugly solution.]
>
> And this is a reason to include it in the kernel?
> Pavel? Is it you? What have they done to you? ;-)
Frequency scaling is currently done in kernel, and this is "battery
blows up" issue.
> I mean - we are moving suspend and everything to userspace, so i wonder
> why this has to be in kernel.
Unless you want LZF, encryption, and graphical progress bar, suspend
goes to userspace. But AC/DC knowledge is actually neccessary for
kernel. You can live without it on most PCs (except powernow-k8
machines and notebooks that have braindamaged), but embedded platforms
definitely need it.
Pavel
--
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-02-10 13:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 12:57 [PATCH, RFC] [1/3] Generic in-kernel AC status Matthew Garrett
2006-02-08 13:03 ` [PATCH, RFC] [2/3] ACPI support for generic " Matthew Garrett
2006-02-08 13:04 ` [PATCH, RFC] [1/3] Generic " Matthew Garrett
2006-02-08 16:58 ` [linux-pm] " Greg KH
2006-02-08 17:08 ` Matthew Garrett
2006-02-08 17:16 ` [linux-pm] " Greg KH
2006-02-08 17:49 ` Matthew Garrett
2006-02-09 5:46 ` Greg KH
2006-02-09 8:53 ` Gabor Gombas
2006-02-10 12:21 ` Pavel Machek
2006-02-10 13:13 ` Gabor Gombas
2006-02-10 13:19 ` [linux-pm] " Matthew Garrett
2006-02-10 13:54 ` Pavel Machek
2006-02-10 13:56 ` Gabor Gombas
2006-02-08 22:25 ` Philipp Matthias Hahn
2006-02-10 12:21 ` Pavel Machek
2006-02-10 8:06 ` Stefan Seyfried
2006-02-10 12:19 ` Pavel Machek
2006-02-10 12:32 ` Stefan Seyfried
2006-02-10 13:46 ` Pavel Machek [this message]
2006-02-12 10:17 ` Jan Engelhardt
2006-02-12 11:27 ` Kyle Moffett
2006-02-14 17:44 ` Thomas Renninger
2006-02-14 20:17 ` Rafael J. Wysocki
2006-02-15 12:36 ` Thomas Renninger
2006-02-15 12:47 ` Matthew Garrett
2006-02-15 15:04 ` Thomas Renninger
2006-02-16 22:44 ` Pavel Machek
2006-02-16 22:39 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060210134638.GA5109@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mjg59@srcf.ucam.org \
--cc=seife@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox