Re: [PATCH 0/3] Radeon acpi vgapost

Re: [PATCH 0/3] Radeon acpi vgapost

[Erik Andrén]

Sadly, this patches doesn't improve the situation for my Mobility M7 
mounted on a Dell C640.
(and no, I didn't apply the 4:th patch regarding locking it to only the 
M9 version).
Everything but the display resumes properly.
All I get is a small white box which I can move about using the mouse.
Switching between virtual terminals doesn't improve the situation either.

I'll gladly help you out if you want me to do some testing.

With best regards
Erik Andrén

[PATCH 0/3] Radeon acpi vgapost

[Michael Marineau]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Thses patches resume ATI radeon cards from acpi S3 suspend when using
radeonfb by reposting the video bios. This is needed to be able to use
S3 when the framebuffer is enabled.
-- 
Michael Marineau
marineam@engr.orst.edu
Oregon State University

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [PATCH 0/3] Radeon acpi vgapost

[Nishanth Aravamudan]

On 27.08.2005 [18:25:44 -0700], Michael Marineau wrote:
> Thses patches resume ATI radeon cards from acpi S3 suspend when using
> radeonfb by reposting the video bios. This is needed to be able to use
> S3 when the framebuffer is enabled.

Just wanted to report that these patches lead to progress on my T41p;
relevant lspci -vvv:

0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) (prog-if 00 [VGA])
	Subsystem: IBM: Unknown device 054f
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at 3000 [size=256]
	Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: <available only to root>

In 2.6.13-rc7 or 2.6.13-rc6-mm2, after echo mem > /sys/power/state, the
lcd light comes back, but no video is actually displayed (I just notice
that the backlight turns on). With your patches, I now see (with either
rc7 or rc6-mm2) a mostly black screen with "inux" in the upper left --
basically a garbled console -- which slowly turns completely white.

If you would like me to do more debugging, I would be more than happy to
do so.

Thanks for the work so far,
Nish

Re: [PATCH 0/3] Radeon acpi vgapost

[Michael Marineau]

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

Nishanth Aravamudan wrote:
> On 27.08.2005 [18:25:44 -0700], Michael Marineau wrote:
> 
>>Thses patches resume ATI radeon cards from acpi S3 suspend when using
>>radeonfb by reposting the video bios. This is needed to be able to use
>>S3 when the framebuffer is enabled.
> 
> 
> Just wanted to report that these patches lead to progress on my T41p;
> relevant lspci -vvv:
> 
> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) (prog-if 00 [VGA])
> 	Subsystem: IBM: Unknown device 054f
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
> 	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
> 	Region 1: I/O ports at 3000 [size=256]
> 	Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
> 	Capabilities: <available only to root>
> 
> In 2.6.13-rc7 or 2.6.13-rc6-mm2, after echo mem > /sys/power/state, the
> lcd light comes back, but no video is actually displayed (I just notice
> that the backlight turns on). With your patches, I now see (with either
> rc7 or rc6-mm2) a mostly black screen with "inux" in the upper left --
> basically a garbled console -- which slowly turns completely white.

I've seen the "inux" thing in the past, but by pressing a key shortly
after the screen turns back on the system continued to resume as usual.
 Given that the backlight normally turns back on for you maybe this post
method isn't the correct solution for your card. Mine wouldn't even turn
on the backlight.

> 
> If you would like me to do more debugging, I would be more than happy to
> do so.

What is the behaviour when the framebuffer is not enabled? If in that
case it doesn't work out of the box, does it work with a userspace trick
like vbetool?

-- 
Michael Marineau
marineam@engr.orst.edu
Oregon State University

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [PATCH 0/3] Radeon acpi vgapost

[Nishanth Aravamudan]

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

On 28.08.2005 [00:44:05 -0700], Michael Marineau wrote:
> Nishanth Aravamudan wrote:
> > On 27.08.2005 [18:25:44 -0700], Michael Marineau wrote:
> > 
> >>Thses patches resume ATI radeon cards from acpi S3 suspend when using
> >>radeonfb by reposting the video bios. This is needed to be able to use
> >>S3 when the framebuffer is enabled.
> > 
> > 
> > Just wanted to report that these patches lead to progress on my T41p;
> > relevant lspci -vvv:
> > 
> > 0000:01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) (prog-if 00 [VGA])
> > 	Subsystem: IBM: Unknown device 054f
> > 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
> > 	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > 	Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
> > 	Interrupt: pin A routed to IRQ 11
> > 	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
> > 	Region 1: I/O ports at 3000 [size=256]
> > 	Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
> > 	Capabilities: <available only to root>
> > 
> > In 2.6.13-rc7 or 2.6.13-rc6-mm2, after echo mem > /sys/power/state, the
> > lcd light comes back, but no video is actually displayed (I just notice
> > that the backlight turns on). With your patches, I now see (with either
> > rc7 or rc6-mm2) a mostly black screen with "inux" in the upper left --
> > basically a garbled console -- which slowly turns completely white.
> 
> I've seen the "inux" thing in the past, but by pressing a key shortly
> after the screen turns back on the system continued to resume as usual.
>  Given that the backlight normally turns back on for you maybe this post
> method isn't the correct solution for your card. Mine wouldn't even turn
> on the backlight.

Oh ok, thanks. I tried the keypress and nothing happened.

> > 
> > If you would like me to do more debugging, I would be more than happy to
> > do so.
> 
> What is the behaviour when the framebuffer is not enabled? If in that
> case it doesn't work out of the box, does it work with a userspace trick
> like vbetool?

It definitely doesn't work OOB for me. I didn't know about vbetool
before (I have messed with radeontool, though, when I told BenH about
this problem a while ago).

Here is what I ended up with in my lidbtn.sh (when I wish to
sleep-to-mem):

chvt 1 //vbetool needs to run from text console
echo mem > /sys/power/state
vbetool post //brings back video mode correctly
chvt 7 //return to X

This seems to work, if the framebuffer is not enabled.

radeontool's regs argument provides some useful information, I think. I
have attache three files, radeontool.pre, radeontool.post and
radeontool.postpost, which capture the output of radeontool regs before
the suspend, after the suspend and after the vbetool command
respectively. As you can see, there is a significant difference between
.pre and .post and less of one between .pre and .postpost.

Perhaps also useful, I have attached the equivalent output with the fb
enabled, in radeontool.fb.pre, radeontool.fb.post and
radeontool.fb.postpost.

Thanks,
Nish

[-- Attachment #2: radeontool.pre --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0f000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

[-- Attachment #3: radeontool.post --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=00770103
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0f000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=02000000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=08000008

[-- Attachment #4: radeontool.postpost --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

[-- Attachment #5: radeontool.fb.pre --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=0d000048
RADEON_CRTC_GEN_CNTL=03000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

[-- Attachment #6: radeontool.fb.post --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=00770103
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000048
RADEON_CRTC_GEN_CNTL=03000200
RADEON_CRTC2_GEN_CNTL=02000000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=080c0089

[-- Attachment #7: radeontool.fb.postpost --]
[-- Type: text/plain, Size: 492 bytes --]

RADEON_DAC_CNTL=ff000002
RADEON_DAC_CNTL2=00000000
RADEON_TV_DAC_CNTL=07770142
RADEON_DISP_OUTPUT_CNTL=1000000a
RADEON_CONFIG_MEMSIZE=08000000
RADEON_AUX_SC_CNTL=00000000
RADEON_CRTC_EXT_CNTL=00000000
RADEON_CRTC_GEN_CNTL=02000200
RADEON_CRTC2_GEN_CNTL=00800000
RADEON_DEVICE_ID=00004e54
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=00000000
RADEON_GPIO_MONIDB=00000000
RADEON_GPIO_CRT2_DDC=00000000
RADEON_GPIO_DVI_DDC=00000300
RADEON_GPIO_VGA_DDC=00000300
RADEON_LVDS_GEN_CNTL=003cffa1

Re: [PATCH 0/3] Radeon acpi vgapost

[Manuel Lauss]

Michael Marineau wrote:
> Thses patches resume ATI radeon cards from acpi S3 suspend when using
> radeonfb by reposting the video bios. This is needed to be able to use
> S3 when the framebuffer is enabled.

These patches break resume from S3 for me. On a vanilla kernel,
radeonfb comes back fine, with your patches applied, the backlight
gets turned on (by BIOS I think) and shortly afterwards its turned off
for good. (Radeon M11 on Sony Vaio)

-- 
  Manuel Lauss

Re: [PATCH 0/3] Radeon acpi vgapost

[Matthew Garrett]

Michael Marineau <marineam@engr.orst.edu> wrote:

> Thses patches resume ATI radeon cards from acpi S3 suspend when using
> radeonfb by reposting the video bios. This is needed to be able to use
> S3 when the framebuffer is enabled.

Please don't make this unconditional. There's no guarantee whatsoever
that the code at c000:0003 does anything useful on a laptop, and it may
actually be harmful in some cases. The sensible approach is to whitelist
it based on DMI entries or provide a sysfs attribute so userspace can
enable/disable it.

How well does this patch deal with multihead? If I have a mixed
radeon/non-radeon system, and the primary head is a non-radeon, won't
this result in the wrong card being POSTed?

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org