suspend to RAM on lifebook 7110

suspend to RAM on lifebook 7110

[Miroslav Ruda]

Hi,

 I'm installing opensuse 10.2 on Fujitsu Siemens Lifebook 7110 (intel
dual core, intel 965 chipset, intel 945 graphics chipset ...).
Most of hardware works fine, but I have some problems with suspend to
ram - suspend/resume using s2ram works fine, but display remains nearly 
black. I can see very hardly what's on display, but machine including
network works fine.

I have tested s2ram on Suse 2.6.18.2-23-default or vanila 2.6.19+swsusp2
with the same problems.

s2ram -i returns
This machine can be identified by:
    sys_vendor   = "FUJITSU SIEMENS"
    sys_product  = "LIFEBOOK S7110"
    sys_version  = " "
    bios_version = "Version 1.18 "

s2ram -f -a[0123] gives the same result, -s -p combinations doesn't work
too. Switching back to text console doesn't help. Using xset dpms force
off doesn't help too. The same problem I have both on text console and
using Xserver.

Do you have any idea what may be wrong? 

-- 
                  Mirek Ruda 

Re: suspend to RAM on lifebook 7110

[Stefan Seyfried]

Hi Miroslav,

i'm taking suspend-devel into cc:, maybe somebody there has an idea about
this, too.

On Thu, Dec 07, 2006 at 11:18:31PM +0100, Miroslav Ruda wrote:
> Hi,
> 
>  I'm installing opensuse 10.2 on Fujitsu Siemens Lifebook 7110 (intel
> dual core, intel 965 chipset, intel 945 graphics chipset ...).
> Most of hardware works fine, but I have some problems with suspend to
> ram - suspend/resume using s2ram works fine, but display remains nearly 
> black. I can see very hardly what's on display, but machine including
> network works fine.

So the graphics card is back up, it is really just the backlight that stays
off.

> I have tested s2ram on Suse 2.6.18.2-23-default or vanila 2.6.19+swsusp2
> with the same problems.
> 
> s2ram -i returns
> This machine can be identified by:
>     sys_vendor   = "FUJITSU SIEMENS"
>     sys_product  = "LIFEBOOK S7110"
>     sys_version  = " "
>     bios_version = "Version 1.18 "
> 
> s2ram -f -a[0123] gives the same result, -s -p combinations doesn't work
> too. Switching back to text console doesn't help. Using xset dpms force
> off doesn't help too. The same problem I have both on text console and
> using Xserver.

Does this machine have fn-keycombos for adjusting the screen brightness?
Try those. I have seen a FSC Q-series (?) that needed just one touch of
the brightness-up key to turn back on the light.

Once we realized this, we could also poke it via the ACPI video module
(just increase the brightness by one level, then decrease it again) and
this also switched the light back on.

Maybe also playing with the "switch internal/external display" key combo
might do something.

I am of course not sure that this also helps on your machine, but it might :-)

Good luck,

    Stefan

-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Frank Ursel]

On Mo, Dez 18, 2006 at 07:38:16 +0100, Stefan Seyfried wrote:
> So the graphics card is back up, it is really just the backlight that
> stays off.

> Does this machine have fn-keycombos for adjusting the screen
> brightness?  Try those. I have seen a FSC Q-series (?) that needed
> just one touch of the brightness-up key to turn back on the light.

Yes such fn-key combos exist, but on Kernel 2.6.18 and 2.6.19 they work
only with disabled acpi. So, i would like to test your hint, but i can't
:-(

> Maybe also playing with the "switch internal/external display" key
> combo might do something.

As far as i can see, this key combo does not bring back light on my FSC
S7110.

 Frank

Re: suspend to RAM on lifebook 7110

[Miroslav Ruda]

Stefan Seyfried wrote:
> Hi Miroslav,
> 
> i'm taking suspend-devel into cc:, maybe somebody there has an idea about
> this, too.
> 
> On Thu, Dec 07, 2006 at 11:18:31PM +0100, Miroslav Ruda wrote:
>> Hi,
>>
>>  I'm installing opensuse 10.2 on Fujitsu Siemens Lifebook 7110 (intel
>> dual core, intel 965 chipset, intel 945 graphics chipset ...).
>> Most of hardware works fine, but I have some problems with suspend to
>> ram - suspend/resume using s2ram works fine, but display remains nearly 
>> black. I can see very hardly what's on display, but machine including
>> network works fine.
> 
> So the graphics card is back up, it is really just the backlight that stays
> off.
> 
>> I have tested s2ram on Suse 2.6.18.2-23-default or vanila 2.6.19+swsusp2
>> with the same problems.
>>
>> s2ram -i returns
>> This machine can be identified by:
>>     sys_vendor   = "FUJITSU SIEMENS"
>>     sys_product  = "LIFEBOOK S7110"
>>     sys_version  = " "
>>     bios_version = "Version 1.18 "
>>
>> s2ram -f -a[0123] gives the same result, -s -p combinations doesn't work
>> too. Switching back to text console doesn't help. Using xset dpms force
>> off doesn't help too. The same problem I have both on text console and
>> using Xserver.
> 
> Does this machine have fn-keycombos for adjusting the screen brightness?
> Try those. I have seen a FSC Q-series (?) that needed just one touch of
> the brightness-up key to turn back on the light.
> 
> Once we realized this, we could also poke it via the ACPI video module
> (just increase the brightness by one level, then decrease it again) and
> this also switched the light back on.

Fn-brightness-down (really down, not up) helps me with the same problem 
on older Lifebook S7020 (i915 chipset). However, on Lifebok S7110 non of
Fn- keys or switching off/on display does the same trick :-(

              Miroslav Ruda

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Frank Ursel]

Hi,

> ram - suspend/resume using s2ram works fine, but display remains nearly 
> black. I can see very hardly what's on display, but machine including
> network works fine.

After resume the backlight remains off. All other stuff is working, but
whitout backlight its a bit hard to work :-) I have the same Lifebook
and for me the following is working very well:

Before i actually suspend the notebook, i write some data about the
graphic card on disk and on resume the data is written back to the
graphic card and everything works fine (I'm writing only the relevant
parts in here):

 # discover video card's ID
 ID=`lspci | grep VGA | awk '{ print $1 }' | sed -e 's@0000:@@' -e 's@:@/@'`

 # dump current data from the video card to the temporary file
 cat /proc/bus/pci/$ID > $TMP_FILE

 # suspend
 echo -n mem > /sys/power/state

 # restore video card data from the temporary file
 # on resume
 cat $TMP_FILE > /proc/bus/pci/$ID

Note: This works fine for me in a script, which is invoked by acpi on
      button-press. I'm using Debian/SID and i don't know where the right
      place for manipulation on Suse is. Maybe you need to tweek a bit
      ;-)

HTH,
Frank

Re: suspend to RAM on lifebook 7110

[Miroslav Ruda]

On Fri, Dec 08, 2006 at 01:33:58PM +0100, Frank Ursel wrote:
> Before i actually suspend the notebook, i write some data about the
> graphic card on disk and on resume the data is written back to the
> graphic card and everything works fine (I'm writing only the relevant
> parts in here):
> 
>  # discover video card's ID
>  ID=`lspci | grep VGA | awk '{ print $1 }' | sed -e 's@0000:@@' -e 's@:@/@'`
> 
>  # dump current data from the video card to the temporary file
>  cat /proc/bus/pci/$ID > $TMP_FILE
> 
>  # suspend
>  echo -n mem > /sys/power/state
> 
>  # restore video card data from the temporary file
>  # on resume
>  cat $TMP_FILE > /proc/bus/pci/$ID

Great, it works for me too.

> Note: This works fine for me in a script, which is invoked by acpi on
>       button-press. I'm using Debian/SID and i don't know where the right
>       place for manipulation on Suse is. Maybe you need to tweek a bit

Just for record (or others with the same problem :-), I'm using hibernate 
script from swsusp2 and there I was able to use
OnSuspend 80 /etc/hibernate/video.sh store
OnResume 80 /etc/hibernate/video.sh restore
into /etc/hibernate/ususpend-ram.conf script.

Or on Suse 10.2, pm-utils are used by default and it's easy to add call to 
this script to /etc/pm/hooks/ directory.

Thanks for your help.

-- 
                  Mirek Ruda 

Re: suspend to RAM on lifebook 7110

[Stefan Seyfried]

On Fri, Dec 08, 2006 at 10:13:08PM +0100, Miroslav Ruda wrote:
> On Fri, Dec 08, 2006 at 01:33:58PM +0100, Frank Ursel wrote:
> > Before i actually suspend the notebook, i write some data about the
> > graphic card on disk and on resume the data is written back to the
> > graphic card and everything works fine (I'm writing only the relevant
> > parts in here):
> > 
> >  # discover video card's ID
> >  ID=`lspci | grep VGA | awk '{ print $1 }' | sed -e 's@0000:@@' -e 's@:@/@'`
> > 
> >  # dump current data from the video card to the temporary file
> >  cat /proc/bus/pci/$ID > $TMP_FILE
> > 
> >  # suspend
> >  echo -n mem > /sys/power/state
> > 
> >  # restore video card data from the temporary file
> >  # on resume
> >  cat $TMP_FILE > /proc/bus/pci/$ID
> 
> Great, it works for me too.

OK. This is probably the same as the R50e entry in the whitelist:
        /* R50e needs not yet implemented save_video_pci_state :-(

I thought that this should somehow go away by the PCI bus suspend/resume
methods that somewhen back got merged by Greg K-H.
I still think that this belongs in the kernel and that we should not work
around this issue in s2ram. But maybe somebody who knows more about this
stuff can convince me otherwise. It should not be too hard :-)

> > Note: This works fine for me in a script, which is invoked by acpi on
> >       button-press. I'm using Debian/SID and i don't know where the right
> >       place for manipulation on Suse is. Maybe you need to tweek a bit
> 
> Just for record (or others with the same problem :-), I'm using hibernate 
> script from swsusp2 and there I was able to use
> OnSuspend 80 /etc/hibernate/video.sh store
> OnResume 80 /etc/hibernate/video.sh restore
> into /etc/hibernate/ususpend-ram.conf script.
> 
> Or on Suse 10.2, pm-utils are used by default and it's easy to add call to 
> this script to /etc/pm/hooks/ directory.

Yes, that's how it was intended to be. Easy and straightforward :-)

Best regards,

     Stefan

-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Matthew Garrett]

On Mon, Dec 18, 2006 at 07:51:36AM +0100, Stefan Seyfried wrote:

> I thought that this should somehow go away by the PCI bus suspend/resume
> methods that somewhen back got merged by Greg K-H.

The kernel will only save and restore the standardised PCI configuration 
registers - anything else needs to be handled by the specific device 
driver. Unfortunately, in the graphics hardware case, the closest thing 
to that is the framebuffer driver. Which we don't tend to use.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Stefan Seyfried]

Hi Matthew,

thanks for explaining this, i am obviously not too deep into that
PCI bus stuff :-)

On Mon, Dec 18, 2006 at 11:11:42AM +0000, Matthew Garrett wrote:
> On Mon, Dec 18, 2006 at 07:51:36AM +0100, Stefan Seyfried wrote:
> 
> > I thought that this should somehow go away by the PCI bus suspend/resume
> > methods that somewhen back got merged by Greg K-H.
> 
> The kernel will only save and restore the standardised PCI configuration 
> registers - anything else needs to be handled by the specific device 
> driver. Unfortunately, in the graphics hardware case, the closest thing 
> to that is the framebuffer driver. Which we don't tend to use.

So the question is: should we either
 - implement a minimal "graphics card PCI suspend resume" "driver" in the
   kernel that will do this even if no framebuffer is used, or
 - implement this as a workaround in userspace?

I mean - it is not rocket science to do it in s2ram, but it just seems
more correct (to me) to do it in the kernel, where the correct locking
and ordering is more or less guaranteed.

-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 
-
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

Re: suspend to RAM on lifebook 7110

[Matthew Garrett]

On Mon, Dec 18, 2006 at 12:29:16PM +0100, Stefan Seyfried wrote:
> So the question is: should we either
>  - implement a minimal "graphics card PCI suspend resume" "driver" in the
>    kernel that will do this even if no framebuffer is used, or

The long term aim is to implement a thin graphics card driver in the 
kernel, and then port framebuffer and DRM code to that. Doing it 
effectively requires knowing which PCI configuration registers are 
relevant for the hardware, which is possibly easier said than done.

>  - implement this as a workaround in userspace?

Might be easier for the moment, though I agree that it's less than 
ideal.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Stefan Seyfried]

On Mon, Dec 18, 2006 at 12:05:51PM +0000, Matthew Garrett wrote:
> On Mon, Dec 18, 2006 at 12:29:16PM +0100, Stefan Seyfried wrote:

> >  - implement this as a workaround in userspace?
> 
> Might be easier for the moment, though I agree that it's less than 
> ideal.

Ok, so how about that (compiled, not really tested. I tested the 
"save_vga_pci" by outputting to a file and comparing to /proc and sysfs),
but i have no hardware here that needs this:

Warning: watch out for my maybe creative usage of "*" and "&" and complain
if you find obvious errors ;-)

Index: s2ram.c
===================================================================
RCS file: /cvsroot/suspend/suspend/s2ram.c,v
retrieving revision 1.45
diff -u -p -r1.45 s2ram.c
--- s2ram.c	20 Sep 2006 16:23:51 -0000	1.45
+++ s2ram.c	18 Dec 2006 16:44:47 -0000
@@ -11,12 +11,16 @@
 #include <errno.h>
 #include <string.h>
 
+#include <pci/pci.h>
+
 #define S2RAM
 #include "vbetool/vbetool.h"
 #include "vt.h"
 #include "s2ram.h"
 
 static void *vbe_buffer;
+unsigned char vga_pci_state[256];
+struct pci_dev vga_dev;
 /* Flags set from whitelist */
 static int flags, vbe_mode = -1;
 char bios_version[1024], sys_vendor[1024], sys_product[1024], sys_version[1024];
@@ -36,6 +40,7 @@ char bios_version[1024], sys_vendor[1024
 #define UNSURE      0x20	/* unverified entries from acpi-support 0.59 */
 #define NOFB        0x40	/* must not use a frame buffer */
 #define VBE_MODE    0x80	/* machine needs "vbetool vbemode get / set" */
+#define PCI_SAVE   0x100	/* we need to save the VGA PCI registers */
 
 #include "whitelist.c"
 
@@ -67,14 +72,15 @@ void machine_known(int i)
 	       "    bios_version = '%s'\n", i,
 	       whitelist[i].sys_vendor, whitelist[i].sys_product,
 	       whitelist[i].sys_version, whitelist[i].bios_version);
-	printf("Fixes: 0x%x  %s%s%s%s%s%s%s\n", flags,
+	printf("Fixes: 0x%x  %s%s%s%s%s%s%s%s\n", flags,
 	       (flags & VBE_SAVE) ? "VBE_SAVE " : "",
 	       (flags & VBE_POST) ? "VBE_POST " : "",
 	       (flags & VBE_MODE) ? "VBE_MODE " : "",
 	       (flags & RADEON_OFF) ? "RADEON_OFF " : "",
 	       (flags & S3_BIOS) ? "S3_BIOS " : "",
 	       (flags & S3_MODE) ? "S3_MODE " : "",
-	       (flags & NOFB) ? "NOFB " : "");
+	       (flags & NOFB) ? "NOFB " : "",
+	       (flags & PCI_SAVE) ? "PCI_SAVE " : "");
 	if (flags & UNSURE)
 		printf("Machine is in the whitelist but perhaps using "
 		       "vbetool unnecessarily.\n"
@@ -143,6 +149,35 @@ int s2ram_check(int id)
 	return ret;
 }
 
+struct pci_dev find_vga(void)
+{
+	struct pci_access *pacc;
+	struct pci_dev *dev;
+
+	pacc = pci_alloc();	/* Get the pci_access structure */
+	pci_init(pacc);		/* Initialize the PCI library */
+	pci_scan_bus(pacc);	/* We want to get the list of devices */
+
+	for (dev=pacc->devices; dev; dev=dev->next) {
+		pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_CLASS);
+		if (dev->device_class == 0x300)
+			break;
+	}
+	pci_cleanup(pacc);
+
+	return *dev;
+}
+
+void save_vga_pci(struct pci_dev dev)
+{
+	pci_read_block(&dev, 0, vga_pci_state, 256);
+}
+
+void restore_vga_pci(struct pci_dev dev)
+{
+	pci_write_block(&dev, 0, vga_pci_state, 256);
+}
+
 /* warning: we have to be on a text console when calling this */
 int s2ram_hacks(void)
 {
@@ -171,6 +206,12 @@ int s2ram_hacks(void)
 		printf("Calling radeon_cmd_light(0)\n");
 		radeon_cmd_light(0);
 	}
+	if (flags & PCI_SAVE) {
+		vga_dev = find_vga();
+		printf("saving PCI config of device %02x:%02x.%d\n",
+			 vga_dev.bus, vga_dev.dev, vga_dev.func);
+		save_vga_pci(vga_dev);
+	}
 
 	return 0;
 }
@@ -216,6 +257,11 @@ int s2ram_do(void)
 
 void s2ram_resume(void)
 {
+	if (flags & PCI_SAVE) {
+		printf("saving PCI config of device %02x:%02x.%d\n",
+			 vga_dev.bus, vga_dev.dev, vga_dev.func);
+		restore_vga_pci(vga_dev);
+	}
 	// FIXME: can we call vbetool_init() multiple times without cleaning up?
 	if (flags & VBE_POST) {
 		vbetool_init();
@@ -260,6 +306,7 @@ static void usage(void)
 	       "    -a, --acpi_sleep: set the acpi_sleep parameter before "
 				       "suspend\n"
 	       "                      1=s3_bios, 2=s3_mode, 3=both\n"
+	       "    -v, --pci_save:   save the PCI config space for the VGA card.\n"
 	       "\n");
 	exit(1);
 }
@@ -278,10 +325,11 @@ int main(int argc, char *argv[])
 		{ "radeontool",	no_argument,		NULL, 'r'},
 		{ "identify",	no_argument,		NULL, 'i'},
 		{ "acpi_sleep",	required_argument,	NULL, 'a'},
+		{ "pci_save",	no_argument,		NULL, 'v'},
 		{ NULL,		0,			NULL,  0 }
 	};
 
-	while ((i = getopt_long(argc, argv, "nhfspmria:", options, NULL)) != -1) {
+	while ((i = getopt_long(argc, argv, "nhfspmriva:", options, NULL)) != -1) {
 		switch (i) {
 		case 'h':
 			usage();
@@ -311,6 +359,9 @@ int main(int argc, char *argv[])
 		case 'a':
 			flags |= (atoi(optarg) & (S3_BIOS | S3_MODE));
 			break;
+		case 'v':
+			flags |= PCI_SAVE;
+			break;
 		default:
 			usage();
 			break;

-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Rafael J. Wysocki]

On Monday, 18 December 2006 18:48, Stefan Seyfried wrote:
> On Mon, Dec 18, 2006 at 12:05:51PM +0000, Matthew Garrett wrote:
> > On Mon, Dec 18, 2006 at 12:29:16PM +0100, Stefan Seyfried wrote:
> 
> > >  - implement this as a workaround in userspace?
> > 
> > Might be easier for the moment, though I agree that it's less than 
> > ideal.
> 
> Ok, so how about that (compiled, not really tested. I tested the 
> "save_vga_pci" by outputting to a file and comparing to /proc and sysfs),
> but i have no hardware here that needs this:
> 
> Warning: watch out for my maybe creative usage of "*" and "&" and complain
> if you find obvious errors ;-)
> 
> Index: s2ram.c
> ===================================================================
> RCS file: /cvsroot/suspend/suspend/s2ram.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 s2ram.c
> --- s2ram.c	20 Sep 2006 16:23:51 -0000	1.45
> +++ s2ram.c	18 Dec 2006 16:44:47 -0000
> @@ -11,12 +11,16 @@
>  #include <errno.h>
>  #include <string.h>
>  
> +#include <pci/pci.h>
> +
>  #define S2RAM
>  #include "vbetool/vbetool.h"
>  #include "vt.h"
>  #include "s2ram.h"
>  
>  static void *vbe_buffer;
> +unsigned char vga_pci_state[256];
> +struct pci_dev vga_dev;
>  /* Flags set from whitelist */
>  static int flags, vbe_mode = -1;
>  char bios_version[1024], sys_vendor[1024], sys_product[1024], sys_version[1024];
> @@ -36,6 +40,7 @@ char bios_version[1024], sys_vendor[1024
>  #define UNSURE      0x20	/* unverified entries from acpi-support 0.59 */
>  #define NOFB        0x40	/* must not use a frame buffer */
>  #define VBE_MODE    0x80	/* machine needs "vbetool vbemode get / set" */
> +#define PCI_SAVE   0x100	/* we need to save the VGA PCI registers */
>  
>  #include "whitelist.c"
>  
> @@ -67,14 +72,15 @@ void machine_known(int i)
>  	       "    bios_version = '%s'\n", i,
>  	       whitelist[i].sys_vendor, whitelist[i].sys_product,
>  	       whitelist[i].sys_version, whitelist[i].bios_version);
> -	printf("Fixes: 0x%x  %s%s%s%s%s%s%s\n", flags,
> +	printf("Fixes: 0x%x  %s%s%s%s%s%s%s%s\n", flags,
>  	       (flags & VBE_SAVE) ? "VBE_SAVE " : "",
>  	       (flags & VBE_POST) ? "VBE_POST " : "",
>  	       (flags & VBE_MODE) ? "VBE_MODE " : "",
>  	       (flags & RADEON_OFF) ? "RADEON_OFF " : "",
>  	       (flags & S3_BIOS) ? "S3_BIOS " : "",
>  	       (flags & S3_MODE) ? "S3_MODE " : "",
> -	       (flags & NOFB) ? "NOFB " : "");
> +	       (flags & NOFB) ? "NOFB " : "",
> +	       (flags & PCI_SAVE) ? "PCI_SAVE " : "");
>  	if (flags & UNSURE)
>  		printf("Machine is in the whitelist but perhaps using "
>  		       "vbetool unnecessarily.\n"
> @@ -143,6 +149,35 @@ int s2ram_check(int id)
>  	return ret;
>  }
>  
> +struct pci_dev find_vga(void)
> +{
> +	struct pci_access *pacc;
> +	struct pci_dev *dev;
> +
> +	pacc = pci_alloc();	/* Get the pci_access structure */
> +	pci_init(pacc);		/* Initialize the PCI library */
> +	pci_scan_bus(pacc);	/* We want to get the list of devices */
> +
> +	for (dev=pacc->devices; dev; dev=dev->next) {
> +		pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_CLASS);
> +		if (dev->device_class == 0x300)
> +			break;
> +	}
> +	pci_cleanup(pacc);
> +
> +	return *dev;
> +}

Hm, I'd rather return the pointer (eg. so that the structure can be freed).

> +
> +void save_vga_pci(struct pci_dev dev)

A pointer here?

> +{
> +	pci_read_block(&dev, 0, vga_pci_state, 256);
> +}
> +
> +void restore_vga_pci(struct pci_dev dev)

And here?

> +{
> +	pci_write_block(&dev, 0, vga_pci_state, 256);
> +}
> +
>  /* warning: we have to be on a text console when calling this */
>  int s2ram_hacks(void)
>  {
> @@ -171,6 +206,12 @@ int s2ram_hacks(void)
>  		printf("Calling radeon_cmd_light(0)\n");
>  		radeon_cmd_light(0);
>  	}
> +	if (flags & PCI_SAVE) {
> +		vga_dev = find_vga();

Could vga_dev be a pointer?

> +		printf("saving PCI config of device %02x:%02x.%d\n",
> +			 vga_dev.bus, vga_dev.dev, vga_dev.func);
> +		save_vga_pci(vga_dev);
> +	}
>  
>  	return 0;
>  }
> @@ -216,6 +257,11 @@ int s2ram_do(void)
>  
>  void s2ram_resume(void)
>  {
> +	if (flags & PCI_SAVE) {
> +		printf("saving PCI config of device %02x:%02x.%d\n",
> +			 vga_dev.bus, vga_dev.dev, vga_dev.func);
> +		restore_vga_pci(vga_dev);
> +	}
>  	// FIXME: can we call vbetool_init() multiple times without cleaning up?
>  	if (flags & VBE_POST) {
>  		vbetool_init();
> @@ -260,6 +306,7 @@ static void usage(void)
>  	       "    -a, --acpi_sleep: set the acpi_sleep parameter before "
>  				       "suspend\n"
>  	       "                      1=s3_bios, 2=s3_mode, 3=both\n"
> +	       "    -v, --pci_save:   save the PCI config space for the VGA card.\n"
>  	       "\n");
>  	exit(1);
>  }
> @@ -278,10 +325,11 @@ int main(int argc, char *argv[])
>  		{ "radeontool",	no_argument,		NULL, 'r'},
>  		{ "identify",	no_argument,		NULL, 'i'},
>  		{ "acpi_sleep",	required_argument,	NULL, 'a'},
> +		{ "pci_save",	no_argument,		NULL, 'v'},
>  		{ NULL,		0,			NULL,  0 }
>  	};
>  
> -	while ((i = getopt_long(argc, argv, "nhfspmria:", options, NULL)) != -1) {
> +	while ((i = getopt_long(argc, argv, "nhfspmriva:", options, NULL)) != -1) {
>  		switch (i) {
>  		case 'h':
>  			usage();
> @@ -311,6 +359,9 @@ int main(int argc, char *argv[])
>  		case 'a':
>  			flags |= (atoi(optarg) & (S3_BIOS | S3_MODE));
>  			break;
> +		case 'v':
> +			flags |= PCI_SAVE;
> +			break;
>  		default:
>  			usage();
>  			break;
> 

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Pavel Machek]

Hi!

> thanks for explaining this, i am obviously not too deep into that
> PCI bus stuff :-)
> 
...
> > > I thought that this should somehow go away by the PCI bus suspend/resume
> > > methods that somewhen back got merged by Greg K-H.
> > 
> > The kernel will only save and restore the standardised PCI configuration 
> > registers - anything else needs to be handled by the specific device 
> > driver. Unfortunately, in the graphics hardware case, the closest thing 
> > to that is the framebuffer driver. Which we don't tend to use.
> 
> So the question is: should we either
>  - implement a minimal "graphics card PCI suspend resume" "driver" in the
>    kernel that will do this even if no framebuffer is used, or

We are going there, but it is *hard* to do, due to kernel graphics
missdesign. Could take years.

>  - implement this as a workaround in userspace?
> 
> I mean - it is not rocket science to do it in s2ram, but it just seems
> more correct (to me) to do it in the kernel, where the correct locking
> and ordering is more or less guaranteed.

Lets do it in userspace. Doing in kernel is right, but it will be
hard.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: suspend to RAM on lifebook 7110

[Rafael J. Wysocki]

Hi,

On Monday, 18 December 2006 13:16, Pavel Machek wrote:
> Hi!
> 
> > thanks for explaining this, i am obviously not too deep into that
> > PCI bus stuff :-)
> > 
> ...
> > > > I thought that this should somehow go away by the PCI bus suspend/resume
> > > > methods that somewhen back got merged by Greg K-H.
> > > 
> > > The kernel will only save and restore the standardised PCI configuration 
> > > registers - anything else needs to be handled by the specific device 
> > > driver. Unfortunately, in the graphics hardware case, the closest thing 
> > > to that is the framebuffer driver. Which we don't tend to use.
> > 
> > So the question is: should we either
> >  - implement a minimal "graphics card PCI suspend resume" "driver" in the
> >    kernel that will do this even if no framebuffer is used, or
> 
> We are going there, but it is *hard* to do, due to kernel graphics
> missdesign. Could take years.
> 
> >  - implement this as a workaround in userspace?
> > 
> > I mean - it is not rocket science to do it in s2ram, but it just seems
> > more correct (to me) to do it in the kernel, where the correct locking
> > and ordering is more or less guaranteed.
> 
> Lets do it in userspace. Doing in kernel is right, but it will be
> hard.

Agreed.

Plus if we do it in the user space, we'll be able to drop it as soon as it's
no longer needed. ;-)

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV