Andrey Borzenkov | 12 Oct 14:18

[PATCH RFC] provide information whether requested firmware is bult-in

As indicated by several threads on lkml, currently the only safe way
to reload external firmware in resume method is to cache it in memory.
In this case if firmware was already built in, we just create useless
copy. The patch suggests framework which can be used to return information
whether firmware was loaded dynamically or already available in memory.
Requestor can check it to decide whether local copy is required.

Alternative would be request_cached_firwmare() function to manage
cache in one place.  

Comments? Is there any other reliable way to ensure firmware can be
loaded on resume?

-andrey

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index c9c92b0..525561a 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -415,6 +415,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 		       name);
 		firmware->size = builtin->size;
 		firmware->data = builtin->data;
+		firmware->flags |= FW_FL_BUILTIN;
 		return 0;
 	}

@@ -491,13 +492,8 @@ release_firmware(const struct firmware *fw)
 	struct builtin_fw *builtin;

(Continue reading)

Rafael J. Wysocki | 6 Oct 00:51

[PATCH -next] PM: Simplify the new suspend/hibernation framework for devices

Hi Greg,

I promised at the KS that I would simplify the new suspend/hibernation
framework for devices to avoid the confusion with two types of PM
operations and pointers to PM operations from too many places.

The appended patch is intended for this purpose.  Unfortunately, I can't
split it into subsystem-related patches, because compilation would be broken
between them.

The patch applies to linux-next, but it's trivial to make it apply to the
mainline.  It's been compiled on x86 (both 32-bit and 64-bit) and tested
on hp nx6325, doesn't appear to break anything.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw <at> sisk.pl>

PM: Simplify the new suspend/hibernation framework for devices

Following the discussion at the Kernel Summit, simplify the new
device PM framework by merging 'struct pm_ops' and
'struct pm_ext_ops' and removing pointers to 'struct pm_ext_ops'
from 'struct platform_driver' and 'struct pci_driver'.

After this change, the suspend/hibernation callbacks will only
reside in 'struct device_driver' as well as at the bus type/
device class/device type level.  Accordingly, PCI and platform
(Continue reading)

Rafael J. Wysocki | 4 Oct 19:25

2.6.27-rc8-git7: Reported regressions from 2.6.26

This message contains a list of some regressions from 2.6.26, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.26, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-10-04      181       41          33
  2008-09-27      173       35          28
  2008-09-21      169       45          36
  2008-09-15      163       46          32
  2008-09-12      163       51          38
  2008-09-07      150       43          33
  2008-08-30      135       48          36
  2008-08-23      122       48          40
  2008-08-16      103       47          37
  2008-08-10       80       52          31
  2008-08-02       47       31          20

Unresolved regressions
----------------------
(Continue reading)

Rafael J. Wysocki | 4 Oct 00:04

[PATCH] ACPI Suspend: Enable ACPI during resume if SCI_EN is not set

From: Rafael J. Wysocki <rjw <at> sisk.pl>

ACPI Suspend: Enable ACPI during resume if SCI_EN is not set

On some machines, like for example MSI Wind U100, the BIOS doesn't
enable ACPI before returning control to the OS, which sometimes
causes resume to fail.  This is against the ACPI specification,
which clearly states that "When the platform is waking from an S1, S2
or S3 state, OSPM assumes the hardware is already in the ACPI mode
and will not issue an ACPI_ENABLE", but it won't hurt to check the
SCI_EN bit and enable ACPI during resume from S3 if this bit is not
set.

Fortunately, we already have acpi_enable() for that, so use it in the
resume code path, before executing _BFS, in analogy with the
resume-from-hibernation code path.

NOTE: We aren't supposed to set SCI_EN directly, because it's owned
by the hardware.

Signed-off-by: Rafael J. Wysocki <rjw <at> sisk.pl>
---
 drivers/acpi/sleep/main.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6/drivers/acpi/sleep/main.c
@@ -200,6 +200,8 @@ static int acpi_suspend_enter(suspend_st
(Continue reading)

Rafael J. Wysocki | 2 Oct 23:37

[PATCH] sky2: Fix recent WOL regression

From: Rafael J. Wysocki <rjw <at> sisk.pl>

sky2: Fix recent WOL regression

Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
sky2_set_wol() (this fixes a regression from 2.6.26 on the Tino's
machine).

Remove an open-coded reference to the standard PCI PM registers that
is not used any more.

Signed-off-by: Rafael J. Wysocki <rjw <at> sisk.pl>
Reported-by: Tino Keitel <tino.keitel <at> gmx.de>
---

 drivers/net/sky2.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/net/sky2.c
===================================================================
--- linux-2.6.orig/drivers/net/sky2.c
+++ linux-2.6/drivers/net/sky2.c
@@ -3034,7 +3034,8 @@ static int sky2_set_wol(struct net_devic
 	struct sky2_port *sky2 = netdev_priv(dev);
 	struct sky2_hw *hw = sky2->hw;

-	if (wol->wolopts & ~sky2_wol_supported(sky2->hw))
+	if ((wol->wolopts & ~sky2_wol_supported(sky2->hw))
(Continue reading)

Kevin Hilman | 1 Oct 12:46

[PATCH] CPUidle: increment state counter for state actually entered

Currently, the count for state that the governor chooses is always
incremented after the 'state_enter' hook is called.  However, the
target's enter hook may choose a different state based on BM activity
or other factors.

This patch does the accounting use 'dev->last_state' state instead of
the governor-chosen state.  If the target's enter_idle hook enters a
different state than it was asked, it should update dev->last_state.

Signed-off-by: Kevin Hilman <khilman <at> deeprootsystems.com>
---
 drivers/cpuidle/cpuidle.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 5ce07b5..c1294f5 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -67,10 +67,10 @@ static void cpuidle_idle_call(void)
 	target_state = &dev->states[next_state];

 	/* enter the state and update stats */
-	dev->last_residency = target_state->enter(dev, target_state);
 	dev->last_state = target_state;
-	target_state->time += (unsigned long long)dev->last_residency;
-	target_state->usage++;
+	dev->last_residency = target_state->enter(dev, target_state);
+	dev->last_state->time += (unsigned long long)dev->last_residency;
+	dev->last_state->usage++;

(Continue reading)

Francesco VIRLINZI | 30 Sep 09:23

Need help on Suspend on RAM

Hi all
I'm working on Suspend on RAM on kernel 2.6.23.17 on a Sh4 based platform.
The suspend on RAM seems really working.
But it I suspend the board more then 3/4 times than the system doesn't 
resume the user space
 but via JTAG I see the kernel is running.

I enabled CONFIG_DETECT_SOFTLOCKUP and the kernel prints:

|BUG: soft lockup detected on CPU#0|

Moreover I installed the patch suggested in http://lwn.net/Articles/287024/
and it seems the kernel is running in:
-   run_timer_softirq

and doing some other test I can confirm the kernel is really there...

In the board there is no real RTC... All the 'time' is based on the 
system timer
 and between suspend/resume the timer is really stopped.

Do you have some suggestion?

Regards
Ciao
 Francesco
Venkatesh Pallipadi | 30 Sep 00:21

[patch 0/2] cpuidle: Time accounting fix

As noted in PM minisummit notes here
http://lwn.net/Articles/292447/

Richard Woodruff <r-woodruff2 <at> ti.com> reported a bug
"the CPUIDLE bug that if target is avoided due to BM activity the original
target state is still accounted the time."

Following provides a mechanism to fix the problem for all drivers and fixes
the problem for acpi cpuidle driver.

--

-- 

Frans Pop | 28 Sep 21:46

sdhci: Loads of scary messages during suspend/resume with SD card inserted

My HP 2510p has an SD card slot and a few days ago I bought one to be able
to add support for SD cards in the Debian Installer.

Whilst playing with it, I found the following messages in my logs during
suspend. At the time the card was inserted, but nothing on it was mounted.

There also seems to be a problem while resuming, especially:
mmc mmc0:8879: parent mmc0 should not be sleeping
More context at the bottom of the mail.

From lspci -vvv:
02:06.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 20
        Region 0: Memory at e0102000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci

02:06.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc

Cheers,
FJP

(Continue reading)

Rafael J. Wysocki | 27 Sep 17:53

2.6.27-rc7-git5: Reported regressions from 2.6.26

This message contains a list of some regressions from 2.6.26, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.26, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-09-27      173       35          28

Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11643
Subject		: ALSA sound/core/pcm_native.c:1947: BUG? (err &gt;= 0)
Submitter	: sangu <sangu.gnome <at> gmail.com>
Date		: 2008-09-24 16:51 (4 days old)

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=11634
Subject		: Sometime my laptop is dead on resume from ram
Submitter	: Romano Giannetti <romano.giannetti <at> gmail.com>
Date		: 2008-09-24 01:12 (4 days old)
(Continue reading)

Rafael J. Wysocki | 26 Sep 22:20

ACPI: Make /proc/acpi/wakeup interface handle PCI devices (again)

Len,

I think we should do this in .27.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw <at> sisk.pl>

ACPI: Make /proc/acpi/wakeup interface handle PCI devices (again)

Make the ACPI /proc/acpi/wakeup interface set the appropriate
wake-up bits of physical devices corresponding to the ACPI
devices and make those bits be set initially for devices that are
enabled to wake up by default.  This is needed to restore the
previous behavior for the PCI devices that were previously handled
correctly with the help of the /proc/acpi/wakeup interface.

Signed-off-by: Rafael J. Wysocki <rjw <at> sisk.pl>
---
 drivers/acpi/glue.c       |    5 ++++-
 drivers/acpi/sleep/proc.c |   10 ++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/acpi/sleep/proc.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/proc.c
+++ linux-2.6/drivers/acpi/sleep/proc.c
@@ -377,6 +377,14 @@ acpi_system_wakeup_device_seq_show(struc
(Continue reading)


Gmane