By the way, another longstanding bug in this /proc/acpi/... code is:
> @@ -336,11 +328,11 @@ acpi_system_write_alarm(struct file *fil
>* to the RTC area of memory.
>*/
> if (acpi_gbl_FADT.day_alarm)
> - CMOS_WRITE(day, acpi_gbl_FADT.day_alarm);
> + cmo
e the top bit set to "1" for some reason.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
Cc: Alessandro Zummo <[EMAIL PROTECTED]>
--- a/drivers/rtc/rtc-cmos.c2007-11-03 16:24:09.0 -0400
+++ b/drivers/rtc/rtc
On Sunday 04 November 2007, Rafael J. Wysocki wrote:
> On Sunday, 4 of November 2007, David Brownell wrote:
> >
> > So what's the status of this now ... are we back to having
> > the /sys/class/rtc/rtc0/wakealarm work with ACPI again
>
> Yes, it should work now.
Link input devices for ACPI buttons to their "physical" ACPI device node.
This way the /sys/class/input/*/device links are set up correctly, the
/proc/bus/input/devices "P: Phys=..." lines exist, and related oddness
need not appear.
Signed-off-by: David Brownell <[EMAIL P
On Tuesday 06 November 2007, Dmitry Torokhov wrote:
> Hi David,
>
> On Nov 6, 2007 3:07 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> > --- g26.orig/drivers/acpi/button.c 2007-11-04 11:47:40.0 -0800
> > +++ g26/drivers/acpi/button.c 2007-11-
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Well, we have the following test script in the userland suspend
> > package that is supposed to work right now:
> >
> > #!/bin/bash
> > date
> > cd /sys/class/rtc/rtc0
> > echo $(( $(
> > > shouldnt we provide a Kconfig way of replacing dev 10:135 with the
> > > new driver's 254:0 device? (while keeping all the current modes of
> > > operation as well, of course.) It's all supposed to be 100% ioctl
> > > ABI compatible with the old driver, right?
> >
> > It's not compatible
> > It'd need to have some NTP sync solution for RTC_LIB devices, but
> > ISTR the gentime stuff still assumes an update_persistent_clock()
> > that doesn't sleep ... and hence can't be used with I2C based RTCs.
>
> I still believe NTP sync stuff should be done outside of the kernel.
> given the me
On Wednesday 02 January 2008, Ingo Molnar wrote:
>
> then please provide a kernel config option for the new driver to take
> over 10:135 too. There's nothing worse to the adoption of new kernel
> features necessiating user-space attention. I've got several images of
> old distros that i dont wa
On Saturday 05 January 2008, Rafael J. Wysocki wrote:
> + * @open: Initialise a transition to given system sleep state.
> + [EMAIL PROTECTED]() is executed right prior to suspending devices. The
> information
> + * conveyed to the platform code by @open() should be disregarded by it
> as
> +
On Tuesday 08 January 2008, Len Brown wrote:
> FYI,
> I think we may have an issue here where the entire Linux suspend order
> is being proposed to change, when in fact the underlying issue
> may really be that USB is in D3 on S3 for this box when it is
> not supposed to be deeper below D1.
>
> ht
On Wednesday 09 January 2008, Alan Stern wrote:
>
> > > The USB autosuspend code affects only the controller's USB interface --
> > > it doesn't touch the PCI side. An autosuspended controller will remain
> > > in D0. Until somebody tries writing autosuspend code for PCI
> > > devices...
> >
>
Minor cleanups to acpi_pci_set_power_state(): use the ACPI and PCI
state symbols to make clear that a mapping is being done between PCI
and ACPI states, instead of using magic numbers. For paranoia's sake,
report any errors. Save five bytes (x86_64) too.
Signed-off-by: David Brownell &l
s, like OpenFirmware, could do the same thing to couple their
firmware tables to the rest of the system.
(Based on a patch from Zhang Rui. This version is modified to not
depend on the patch makig ACPI initialize driver model wakeup flags.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]
On Monday 25 February 2008, Zhang, Rui wrote:
> > + if (!ACPI_FAILURE(status)) {
> > + int ret;
> > +
> > + ret = sysfs_create_link(&dev->kobj, &acpi_dev->dev.kobj,
> > + "firmware_node");
> > + ret = sysfs_create_link(&a
On Monday 25 February 2008, Zhang, Rui wrote:
>
> On Tue, 2008-02-26 at 14:45 +0800, David Brownell wrote:
> > On Monday 25 February 2008, Zhang, Rui wrote:
> > > > + if (!ACPI_FAILURE(status)) {
> > > > + int ret;
> > > > +
>
This isn't quite the same as "how to handle the VIA quirks correctly",
but it does seem like the IRQ API should probably have a call to get
the IRQ trigger mode, just like it has ways to set it. I've seen
drivers that need to try multiple trigger modes before they find one
that will work on the ta
On Wednesday 20 September 2006 8:11 am, Moore, Robert wrote:
> Problem is to make one version of the code compile everywhere with no
> warnings.
Yes, and it's been solved in essentially all other parts of x86 kernels.
In fact, until somewhere in the 2.6.18 series it was solved for ACPI ...
-
To
On Tuesday 14 November 2006 11:48 pm, Len Brown wrote:
> On Wednesday 15 November 2006 02:03, David Brownell wrote:
> > dmesg reports to me stuff like
> >
> > ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for
> > [EmbeddedControl] [20060707]
>
On Wednesday 15 November 2006 6:48 am, Alexey Starikovskiy wrote:
> ec1.patch
>
>
> Always enable GPE after return from notify handler.
>
> From: Alexey Starikovskiy <[EMAIL PROTECTED]>
>
>
> ---
Yes, this seems to resolve the regression as well as Len's ec_intr=0 boot param.
IMO this shoul
On Wednesday 15 November 2006 1:56 pm, David Brownell wrote:
> On Wednesday 15 November 2006 6:48 am, Alexey Starikovskiy wrote:
> > ec1.patch
> >
> >
> > Always enable GPE after return from notify handler.
> >
> > From: Alexey Starikovskiy <[EMAIL PR
t reports 10-12 IRQs going to ACPI.
> Also, may be attached patch will help?
I'l give it a try next time I can reboot (presumably by this PM).
- Dave
>
> Regards,
> Alex.
>
> David Brownell wrote:
> > On Wednesday 15 November 2006 1:56 pm, David Brown
On Thursday 16 November 2006 8:23 am, Alexey Starikovskiy wrote:
> David Brownell wrote:
> > On Thursday 16 November 2006 7:41 am, Alexey Starikovskiy wrote:
> >
> >> Looks like either EC GPE or whole ACPI irq got disabled... Could you
> >> check that A
On Thursday 16 November 2006 7:41 am, Alexey Starikovskiy wrote:
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -467,8 +467,8 @@ static u32 acpi_ec_gpe_handler(void *dat
> status = acpi_os_execute(OSL_EC_BURST_HANDLER,
> acpi_ec_gpe_query, ec);
> }
> acpi_
On Thursday 16 November 2006 1:56 pm, Alexey Starikovskiy wrote:
> David,
>
> It looks like problem with recent changes to EC driver, so could you
> please try to revert those patches one-by-one in order to
> find problematic one... I'm attaching patches: ec_x1 is the first in
> series and ec_x7
On Thursday 16 November 2006 10:22 pm, David Brownell wrote:
> On Thursday 16 November 2006 7:41 am, Alexey Starikovskiy wrote:
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -467,8 +467,8 @@ static u32 acpi_ec_gpe_handler(void *dat
> >
> On Sat, 18 Nov 2006, Starikovskiy, Alexey Y wrote:
>
> > Or may be because it fixes all the current AMD-HP notebooks?
Whatever "it" is sure broke mine though... the one that's
currently on my lap! :)
Running right now with a patch reverting the update which
made trouble on Linus' machine, b
On Saturday 18 November 2006 11:05 am, David Brownell wrote:
>
> Running right now with a patch reverting the update which
> made trouble on Linus' machine, but without Alexey's two
> tweaks to the EC interrupt handler. So far so good, even
> after doing things wh
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
> +static struct subsys_attribute info_attr = {
> + .attr = {
> + .name = __stringify(info),
> + .mode = 0444,
> + },
> + .show = info_show,
> + .store = NULL,
> +};
Please don't expand __ATTR_RO(info)
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
> This patch set is against acpi-test sysfs branch, and will duplicate
> several ACPI procfs functions in sysfs.
> As struct subsystem power_subsys is referred and the interface under
> /sys/power/ is changed by this patch series,
> I wish to
On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
>
> Create /sys/power/alarm.
Urg. This doesn't work with the RTC framework, which accepts the reality
that some systems have multiple RTCs ... /sys/class/rtc/rtcN/alarm is a
much more appropriate location for that RTC's alarm.
(How to handle
On Saturday 06 January 2007 9:57 pm, Matthew Garrett wrote:
> On Sat, Jan 06, 2007 at 02:42:22PM -0800, David Brownell wrote:
> > On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
> > >
> > > Create /sys/power/alarm.
> >
> > Urg. This doesn't wo
On Saturday 06 January 2007 9:54 pm, Matthew Garrett wrote:
> On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
>
> > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > attribute. And that ACPI is finally going to start worki
way: not much can be done to prevent
one task from clobbering another task's alarm settings.
It differs from that file in that there's no in-kernel date parser.
Note that a few RTCs ignore rtc_wkalrm.enabled when setting alarms, or
aren'
On Monday 08 January 2007 3:36 am, Pavel Machek wrote:
>
> What about periodic alarms?
So far as I'm concerned they're not part of the API. The periodicity notion
of the alarm on PC RTCs is pretty bizarre if you look at it ... not portable
to much non-PC hardware (without extremely ugly hacks n
> > The FADT also exposes whether the RTC can wake from S4. You may have
> > noticed that my rtc-cmos patch #3 exported the relevant FADT info
> > to the RTC device using platform_data, but the S4 wake capability flag
> > isn't useful for anything on today's Linux.
>
> Isn't useful in what way? I
On Monday 08 January 2007 2:13 am, Zhang Rui wrote:
> Errr, I never met this multiple RTCs situation before and it's true
> that /sys/power/alarm can not handle multiple RTCs.
> I don't know why they are needed, maybe for the embedded system?
Yes.
> Could you provide me more details about this mu
On Monday 08 January 2007 12:43 pm, Matthew Garrett wrote:
> On Mon, Jan 08, 2007 at 12:39:08PM -0800, David Brownell wrote:
>
> > In that current API there's no way to tell anything at all about the
> > target system state inside a driver's suspend() method
On Monday 08 January 2007 3:40 am, Zhang Rui wrote:
>
> if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
> and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
> David's patches are merged. :)
One help there would be someone from the ACPI team signing off
On Wednesday 24 January 2007 8:14 pm, Len Brown wrote:
> On Sunday 07 January 2007 22:31, David Brownell wrote:
>
> > > However, I'm not entirely sure /how/ that integration should happen. If
> > > both the Linux driver and ACPI know how to enable wakeup for a devi
> > This adds a new "wakealarm" sysfs attribute to RTC class devices which
> > support alarm operations and are wakeup-capable:
> >
> > - It reads as either empty, or the scheduled alarm time as seconds
> >since the POSIX epoch. (That time may already have passed, since
> >nothing curren
On Wednesday 24 January 2007 7:28 pm, Len Brown wrote:
> >
> > The latest patches relevant to the RTC used by ACPI are:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=116802017116195&w=2
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044406838&w=2
> > http://marc.theaimsgroup
> > > I think we need to make /sys/power/state handle S1.
> > >
> > > There are two cases
> > >
> > > 1. Platform supports S1, but does not support S3.
> > >
> > > This is more common. You see this a lot on server-class machines.
> > >
> > > We could make "mem" simply mean S1 here b/c it is ef
On Thursday 25 January 2007 4:08 am, Pavel Machek wrote:
> On Wed 2007-01-24 21:28:13, Len Brown wrote:
> > On Monday 08 January 2007 08:13, Pavel Machek wrote:
> > > Hi!
> > >
> > > > This patch set is against acpi-test sysfs branch which already converts
> > > > ACPI to follow driver model. Now
On Thursday 25 January 2007 3:12 pm, Len Brown wrote:
> That's my point.
> What is the syntax to request "10-seconds into the future"?
See
http://lists.osdl.org/pipermail/linux-pm/2007-January/004459.html
and morph the first example ... it shows 45*60 seconds into the future.
Substitute "45*6
By the way ... in case I was unclear about this, this does need to _follow_ the
patch defining the rtc-cmos driver and its platform data. Which I'm sure it
does in the MM tree, as it does in my own patchsets. :)
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
t
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> It's a *device*, dammit. It should save and resume like one (probably as a
> system device). The "set_mode()" etc stuff is at a completely different
> (higher) conceptual level.
Agreed, except about "probably as a system device".
Last
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> >
> > Also, making HPET use the legacy mode seems like a step backwards.
> It is not 'legacy' mode,
> It is a legacy replacement mode.
Typo, sor
On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
>
> I won't disagree - it might well be much nicer to just show it in the
> "real" device tree. I'm not 100% sure where in the tree it would go,
> though. It should probably be "inside" the root entry, before any of the
> PCI buses.
Mi
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> When HPET is active it eats RTC IRQ,
Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
In the more sensible "Standard Mode"
On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> > > So the only way out is to emulate RTC using HPET,
> > > It is done this way in old rtc dri
On Friday 30 March 2007 5:21 pm, Johannes Berg wrote:
> Hm, another thing. The RTC alarm wakeup event, wouldn't that require
> programming the time too? And if so, should that be done through the
> power interface to it?
There's already a cross-platform interface to RTC wakeup alarms; no
new inte
On Friday 30 March 2007 5:18 pm, Johannes Berg wrote:
> On Fri, 2007-03-30 at 17:57 -0600, Jordan Crouse wrote:
> About different possible states: I think each of those can have
> different possible wakeup sources, ACPI can afaik go to S4 and still be
> able to configure the wakeup sources. So I s
On Friday 30 March 2007 4:57 pm, Jordan Crouse wrote:
> Hey all -
>
> I'm happy to report that the OLPC power management effort is proceeding
> nicely. We have suspend to RAM functional, and the system is resuming
> back to the framebuffer console.
Good to hear that. Now, if the same could be s
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
>
> Make them be at the top of the device tree by adding them earl
t characteristics than "when
device happened to enumerate" ... e.g. clocksources and clockevents
at a clearly defined point during suspend and resume.
This patch has a potential downside for devices that have multiple
power dependencies and which "just happened to work" before.
Sig
On Saturday 31 March 2007 11:16 am, Jordan Crouse wrote:
> On 31/03/07 09:52 -0700, David Brownell wrote:
> > You seem to be completely ignoring the /sys/devices//power/wakeup
> > event attributes. Why?
>
> Complete and total ignorance that they even existed. I gues
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute [EMAIL PROTECTED] from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resum
On Saturday 31 March 2007 6:01 pm, Jordan Crouse wrote:
> On 31/03/07 11:57 -0700, David Brownell wrote:
> > The other part is the platform code. On embedded hardware that's usually
> > just calling device_init_wakeup() before registering the platform devices,
> > and
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered. Prett
On Sunday 01 April 2007 9:56 am, Jordan Crouse wrote:
> A few of your comments made me wonder if I haven't been clear enough -
> despite this being an x86 platform, we are not using ACPI for power
> management, for a variety of reasons, including the fact that we have
> our own open source firmwar
On Monday 02 April 2007 9:55 am, Jordan Crouse wrote:
> On 01/04/07 17:28 -0700, David Brownell wrote:
> > > And so forth. Like the AT91, we enable the wakeup events prior to
> > > suspending. I'm willing to bet that other PM methods like ACPI
> > > co
On Monday 02 April 2007 3:23 am, Zhang Rui wrote:
> > > The only other issue then, is how we could define and manage wakeup events
> > > for events that aren't associated with specific devices, like power button
> > > and lid events. We'll need some way to control those somewhere in sysfs -
> > >
On Monday 02 April 2007 12:40 pm, Matthew Garrett wrote:
> On Mon, Apr 02, 2007 at 11:24:21AM -0700, David Brownell wrote:
>
> > I don't follow this at all. Most of the relevant devices have a PCI
> > device driver, not an ACPI device driver. Surely you aren't pr
, we need to be sure driver model nodes are properly hooked
up before we can get rid of this ACPI-only interface for wakeup events.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- g26.orig/drivers/acpi/sleep/proc.c 2007-04-03 16:27:22.0 -0700
+++ g26/drivers/acpi/sleep/pro
On Thursday 05 April 2007 2:26 am, Matthew Garrett wrote:
> On Tue, Apr 03, 2007 at 05:41:42PM -0700, David Brownell wrote:
> > This updates /proc/acpi/wakeup to be more informative, primarily by showing
> > the sysfs node associated with each wakeup-enabled device. Example:
>
On Thursday 05 April 2007 12:59 am, Zhang Rui wrote:
> On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
> > In that example, two devices don't actually exist (USB3, S139), one can't
> > issue wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and
Following are three patches for basic driver model wakeup flag support on
PCs. I think the first two are nearly mergable. The third previously broke
powerpc, so it's likely not yet mergeable ... the issue was arch-specific
differences in PCI initialization, someone else will need to solve them.
semantics of that call are enhanced so that support for PCI PME# is no
longer needed. It can now work for devices with "legacy PCI PM", when
platform support allows it. (That support would use some board-specific
signal for for the same purpose as PME#.)
Signed-off-by: David Browne
wakeup events for systems in the S0 state. That kind of runtime PM is
allowed by PCI and by common hardware (e.g. ICH6).
Includes a semi-related bugfix: the input devices for the ACPI buttons
weren't set up to link to the "physical" ACPI device node.
Signed-off-by: D
This patch teaches "pci_dev" about the driver model wakeup support, by
marking devices as supporting wakeup when the PME# capability is listed
in a PCI PM capability. Right now, few PCI drivers support wakeup events:
only USB hosts, and various network drivers.
A previous version of this patch br
On Thursday 05 April 2007 12:48 pm, David Brownell wrote:
>
> Now, I've not yet made time to test whether the results _work_ but they
> do look like they do the right thing. (So far I've had lousy luck seeing
> ACPI recover from wake events...)
Positive results to rep
On Thursday 05 April 2007 4:30 pm, Matthew Garrett wrote:
> On Thu, Apr 05, 2007 at 04:20:59PM -0700, David Brownell wrote:
>
> > Same thing with S3 ... except in that case the display was trashed; I
> > was able to ssh in, and switch the vt from raw console to X using the
>
On Friday 06 April 2007 2:36 am, Zhang Rui wrote:
> On Thu, 2007-04-05 at 03:58 -0700, David Brownell wrote:
> >
> > For wakeup devices, the main issue I've seen is with button devices.
> > In my limited set of test sytems, everything else is either PCI, PNP,
> >
On Friday 06 April 2007 10:01 pm, Greg KH wrote:
> Are you _sure_ you have a 1-to-1 relationship here? No multiple devices
> pointing to the same acpi node? Or the other way around? If so, you
> are going to have to change the name to be something more unique.
I've wondered that too. The shor
> On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote:
> > On Friday 06 April 2007 10:01 pm, Greg KH wrote:
> >
> > > Are you _sure_ you have a 1-to-1 relationship here? No multiple devices
> > > pointing to the same acpi node? Or the other way around? If s
On Saturday 07 April 2007 1:08 pm, David Brownell wrote:
> By adding a warning over this create-links patch, I found that the
> system in the $SUBJECT patch (and likely every ACPI system) has
> two different nodes that correspond to one ACPI node:
>
> /sys/devices/pci:
On Tuesday 10 April 2007 4:29 pm, David Brownell wrote:
> ... the appended
> patch goes on top of the previous pnpacpi patch, and should (nyet tested!)
> fix another place I saw that warning.
And here's a tested version. Curiouser and curiouser. I think the mapping
of ACPI t
longest alarm is just 24 hours. That will surprise anyone
trying to use those extended alarms.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
glue.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
--- g26.orig/drivers/acpi/glue.c2007-04-12 10:56:35.000
On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
> Hi!
>
> > > Are you _sure_ you have a 1-to-1 relationship here? No multiple devices
> > > pointing to the same acpi node? Or the other way around? If so, you
> > > are going to have to change the name to be something more unique.
> >
> > I
ACPI tables, that would
be nice too ...
- Dave
On Thursday 05 April 2007 12:48 pm, David Brownell wrote:
> Following are three patches for basic driver model wakeup flag support on
> PCs. I think the first two are nearly mergable. The third previously broke
> powerpc, so it&#x
On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
> On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
>
> > ...
> > > Assuming they all adopt that same "parallel tree" model, that seems
> > > like a good idea. The tools will likely need to unde
On Tuesday 17 April 2007 8:03 pm, Greg KH wrote:
> On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
> > Looks like the i8042 serial nodes will be bizarre too:
> >
> > /sys/devices/pnp0/00:09
> > ... touchpad's PNP node
> >
On Tuesday 17 April 2007 8:10 pm, Len Brown wrote:
> On Thursday 12 April 2007 17:14, David Brownell wrote:
> > --- g26.orig/drivers/acpi/glue.c2007-04-12 10:56:35.0 -0700
> > +++ g26/drivers/acpi/glue.c 2007-04-12 10:56:35.0 -0700
> > @@ -316,13 +316,19
On Wednesday 18 April 2007 2:51 am, Zhang Rui wrote:
> Hi, David,
>
> On Thu, 2007-04-05 at 12:48 -0700, David Brownell wrote:
> > Following are three patches for basic driver model wakeup flag support on
> > PCs. I think the first two are nearly mergable. The third previou
> > > > The patches are:
> > > >
> > > > - Define a platform_enable_wakeup() PM hook and use it with PCI. (This
> > > >might help OLPC with its non-RTC events...)
> > > >
> > > > - Make ACPI init and use driver model wakeup flags for the
> > > > (motherboard)
> > > >devices in its tab
On Monday 23 April 2007, Pavel Machek wrote:
> Hi!
>
> > static inline int device_suspend(pm_message_t state)
> > --- g26.orig/drivers/base/power/main.c 2007-04-04 13:03:33.0
> > -0700
> > +++ g26/drivers/base/power/main.c 2007-04-04 13:03:34.0 -0700
> > @@ -29,6 +29,9 @@
, and uses
the result appropriately.
Fix pci_choose_state() to finally behave sanely too.
Minor whitespace fixes.
Lightly tested -- STR only, with only USB affected by the new code.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/main.c | 29 +++-
driver
On Thursday 10 May 2007, Rafael J. Wysocki wrote:
> On Wednesday, 9 May 2007 21:22, David Brownell wrote:
> > Provide new ACPI method tracking the target system state, for use
> > during suspend() and other PM calls. It returns ACPI_STATE_S0
> > except during true suspend pat
On Monday 14 May 2007, Pavel Machek wrote:
> > --- g26.orig/drivers/acpi/sleep/main.c 2007-05-09 08:57:37.0
> > -0700
> > +++ g26/drivers/acpi/sleep/main.c 2007-05-09 08:58:33.0 -0700
> > @@ -35,6 +35,20 @@ static u32 acpi_suspend_states[] = {
> >
> > static int init_8259
On Saturday 19 May 2007, Mattia Dongili wrote:
> On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > On Fri, 18 May 2007 16:1
On Sunday 20 May 2007, Mattia Dongili wrote:
>
> $ cat /proc/acpi/wakeup
> DeviceS-state Status Sysfs node
> PWRBS4*enabled
> S1F0S4 disabled
> S1F1S4 disabled
> S1F2S4 disabled
> S1F3S4 disabled
> S1F4S4 disabled
> S1F5S
On Monday 21 May 2007, Bjorn Helgaas wrote:
> On Wednesday 09 May 2007 01:22:29 pm David Brownell wrote:
> > static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> > {
> > ...
> > + switch (state) {
> > + case PCI_D0:
> &g
On Monday 21 May 2007, Bjorn Helgaas wrote:
> On Monday 21 May 2007 11:55:54 am David Brownell wrote:
> > On Monday 21 May 2007, Bjorn Helgaas wrote:
> > > We had a bug[1] a while back where e1000 would suspend a device and
> > > call pci_power_state(), which used ACPI
On Sunday 27 May 2007, Matthew Garrett wrote:
> f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace
> interface to the CMOS alarm. This could previously be accessed via
> /proc/acpi/alarm ...
I was a bit surprised the ACPI team didn't have more comments on
that issue, myself.
On Sunday 27 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:39:11AM +0100, Matthew Garrett wrote:
>
> > but will disable /proc/acpi/wakeup. It'll also be impossible to load
> > CONFIG_RTC_CMOS because CONFIG_RTC has grabbed the io ports, so it's not
> > possible to use the new int
On Monday 28 May 2007, frank paulsen wrote:
> David Brownell <[EMAIL PROTECTED]> writes:
>
> > On Sunday 27 May 2007, Matthew Garrett wrote:
> >> f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace
> >> interface to the CMOS alarm. T
On Tuesday 19 June 2007, Marcelo Tosatti wrote:
>
> > Since OLPC isn't using ACPI, it can be more like embedded Linux,
> > and just Do The Right Thing ... create platform devices, etc. :)
>
> As you know we want user configuration of enabled wakeup events (unlike
> embedded platforms where this
On Wednesday 20 June 2007, Alan Stern wrote:
> On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
>
> Pardon me for asking what may be a dumb question. Why does ACPI (or
> anything else) need to know the target system state in order to decide
> how a device should be suspended or whether wakeup should
On Wednesday 20 June 2007, Rafael J. Wysocki wrote:
> On Wednesday, 20 June 2007 08:18, Shaohua Li wrote:
> > On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
> > > > Based on David's patch
> > > > http://marc.info/?l=linux-acpi&m=1
1 - 100 of 137 matches
Mail list logo
