[Intel-gfx] Partial success - Fixing resume from s2ram on S6010
Hi Ville, dear intel experts,
without the deadlock in i915, I had at least a partial success in
restoring the video on the Fujitsu S6010.
Apparently, the bios does not re-initialize the 830MG registers, nor the
registers of the ns2501 DVO.
Instead, the 830MG is configured in a 640x480 mode (no matter what the
suspend mode was) and
the DVO is configured in a DPMS off state (no matter what the mode was
before the suspend).
The attached script, to be placed in /etc/pm/sleep.d/99video will force
correct values back into the registers
and thus restore the display. Partially. Trouble still is that the
restored screen has some type of hick-up by
moving left or right by a couple of pixels (probably exactly by one
tile, I did not measure). Interestingly,
a dump of the DVO and 830MG registers did not reveal any significant
difference before and after the restore,
so it is still unclear why that hick-up appears.
Anyhow - it seems that $OTHER_OS has a completely different strategy for
resume than Linux. $OTHER_OS seems
to simply re-load the video registers for the currently active mode,
ignoring the current state of the hardware.
The i915 kernel module instead seems to try to interpret the current
register set to a video mode, and then
restores its state from the state of the hardware. It seems to me that
this is a less than ideal approach, and
it would be better keep a copy of the registers how they should be
during suspend, and restore them in
the kernel module to the correct video mode on resume, ignoring whatever
the bios left there.
Do kernel modules like the i915 or the dvo_ns2501 offer some kind of
hook that is called by the kernel when
the machine is suspended and resumed? If so, this would be extremely
helpful and would allow a much safer
suspend/resume operation than currently possible with the mode-detect
guess i915 attempts to do.
Thanks,
Thomas
#!/bin/sh
#
PATH=/root/bin/:$PATH
suspend_video()
{
chvt 1
sleep 0.5
}
restore_video()
{
intel_reg_write 0x2120 0
intel_reg_write 0x61140 0x90004084
intel_reg_write 0x61100 0xC18
intel_reg_write 0x70180 0xd800
intel_reg_write 0x70188 0x2000
intel_reg_write 0x70190 0x02ff03ff
intel_reg_write 0x6001c 0x03ff02ff
intel_reg_write 0x70024 0x1207
intel_reg_write 0x06040 0x0004150d
intel_reg_write 0x06044 0x0004150d
intel_reg_write 0x6014 0xd082
intel_reg_write 0x6 0x053f03ff
intel_reg_write 0x60004 0x053f03ff
intel_reg_write 0x60008 0x049f0417
intel_reg_write 0x6000c 0x032502ff
intel_reg_write 0x60010 0x032502ff
intel_reg_write 0x60014 0x03080302
intel_reg_write 0x71180 0x0100
intel_reg_write 0x71008 0x8000
intel_reg_write 0x6101c 0x027f01df
intel_reg_write 0x71024 0x9206
intel_reg_write 0x06018 0xc08b
intel_reg_write 0x61000 0x031f027f
intel_reg_write 0x61004 0x03170287
intel_reg_write 0x61008 0x02ef028f
intel_reg_write 0x6100c 0x020c01df
intel_reg_write 0x61010 0x020401e7
intel_reg_write 0x61014 0x01eb01e9
intel_reg_write 0x2000 0x00400131
intel_reg_write 0x2004 0x05000561
intel_reg_write 0x200c 0x02000561
intel_reg_write 0x2010 0x0
modprobe i2c-hid
modprobe i2c-algo-bit
modprobe i2c-dev
modprobe i2c-scmi
modprobe i2c-i801
modprobe i2c-ismt
modprobe i2c-gpio
modprobe i2c-piix4
modprobe i2c-isch
modprobe i2c-mux
modprobe i2c-core
i2cset -y 5 0x38 8 0x35
i2cset -y 5 0x38 0x34 0x03
i2cset -y 5 0x38 0x35 0xff
i2cset -y 5 0x38 0x37 0x44
i2cset -y 5 0x38 0x40 0x80
i2cset -y 5 0x38 0x41 0x00
i2cset -y 5 0x38 0xb7 0x03
i2cset -y 5 0x38 0xc0 0x01
i2cset -y 5 0x38 0xf0 0xca
i2cset -y 5 0x38 0xf1 0x00
i2cset -y 5 0x38 0xf2 0x11
chvt 7
}
case $1 in
suspend) suspend_video;;
hibernate) suspend_video;;
resume) restore_video;;
thaw) restore_video;;
esac
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010
On Mon, Jun 09, 2014 at 12:57:46PM +0200, Thomas Richter wrote: Hi Ville, dear intel experts, without the deadlock in i915, I had at least a partial success in restoring the video on the Fujitsu S6010. Apparently, the bios does not re-initialize the 830MG registers, nor the registers of the ns2501 DVO. Instead, the 830MG is configured in a 640x480 mode (no matter what the suspend mode was) and the DVO is configured in a DPMS off state (no matter what the mode was before the suspend). The attached script, to be placed in /etc/pm/sleep.d/99video will force correct values back into the registers and thus restore the display. Partially. Trouble still is that the restored screen has some type of hick-up by moving left or right by a couple of pixels (probably exactly by one tile, I did not measure). Interestingly, a dump of the DVO and 830MG registers did not reveal any significant difference before and after the restore, so it is still unclear why that hick-up appears. Anyhow - it seems that $OTHER_OS has a completely different strategy for resume than Linux. $OTHER_OS seems to simply re-load the video registers for the currently active mode, ignoring the current state of the hardware. The i915 kernel module instead seems to try to interpret the current register set to a video mode, and then restores its state from the state of the hardware. No, we do restore the mode you were using before suspend. Are you still using vbetool? That would explain why things go bad since vbetool will clobber whatever i915 already did. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010
Am 09.06.2014 13:08, schrieb Ville Syrjälä No, we do restore the mode you were using before suspend. Are you still using vbetool? That would explain why things go bad since vbetool will clobber whatever i915 already did. No, vbetool is out of the equation (see the script attached to the previous post). However, I dumped the 830MG register set and the ns2501 DVO set before and after the suspend, and they are pretty different. As said, the 830 is configured to use a 640x480 mode (instead of the 1024x786 mode) and the DVO is off. Maybe the kernel tries to mode-detect the connected monitor, and this fails because the PLLs are not yet configured correctly? Note that the ns2501 requires a correctly configured DVO to be able to respond on the i2c bus. If so, mode-detection requires configuring the PLLs to *some* useful mode before attempting to detect anything, otherwise the DVO just plays dead. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010
On Mon, Jun 09, 2014 at 01:19:46PM +0200, Thomas Richter wrote: Am 09.06.2014 13:08, schrieb Ville Syrjälä No, we do restore the mode you were using before suspend. Are you still using vbetool? That would explain why things go bad since vbetool will clobber whatever i915 already did. No, vbetool is out of the equation (see the script attached to the previous post). So now you're using acpi_sleep=s3_bios, or nothing? However, I dumped the 830MG register set and the ns2501 DVO set before and after the suspend, and they are pretty different. As said, the 830 is configured to use a 640x480 mode (instead of the 1024x786 mode) and the DVO is off. Maybe the kernel tries to mode-detect the connected monitor, and this fails because the PLLs are not yet configured correctly? Note that the ns2501 requires a correctly configured DVO to be able to respond on the i2c bus. If so, mode-detection requires configuring the PLLs to *some* useful mode before attempting to detect anything, otherwise the DVO just plays dead. Boot with drm.debug=0xe grab the dmesg after the resume and let's see if there is something fishy happening. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010
Am 09.06.2014 13:31, schrieb Ville Syrjälä: So now you're using acpi_sleep=s3_bios, or nothing? Ok, tried now with acpi_sleep=s3. Unfortunately, this hangs the machine completely during resume, I cannot even ping it. Then, I tried the same trick again, namely unloading the i915 module before the resume, reloading it after the resume. This worked flawlessly, display came back without requiring any quirks, even with the state the bios left the hardware in. Note again that this is different for the resume from acpi_sleep=s3 or 'nothing', where I can restore the display (though the result is a hick-up). If there is another deadlock in i915 (not unlikely) I cannot debug it this way, unfortunately. Unfortunately, the S6010 does not have a serial port to redirect the console to. I can only use the netconsole, though this reveals nothing. Probably the deadlock happens before the is enabled. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010
Hi Ville, dear Intel experts, more on the partial resume from suspend for the S6010. It seems that the culprit is really the lack of a proper initialization of the DVO. The minimum sequence to restore the display does not require to modify the 830 registers directly, but rather needs to setup the DVO. xrandr --output DVI1 --mode 640x480 # without this, access to the DVO is blocked, thus # all the following fails. The above initializes the # PLLs such that the DVO can be accessed. modprobe i2c-hid modprobe i2c-algo-bit modprobe i2c-dev modprobe i2c-scmi modprobe i2c-i801 modprobe i2c-ismt modprobe i2c-gpio modprobe i2c-piix4 modprobe i2c-isch modprobe i2c-mux modprobe i2c-core # # Only the following two are required. i2cset -y 5 0x38 0x34 0x02 i2cset -y 5 0x38 0x35 0x7f # This restores the old resolution. xrandr --output DVI1 --mode 1024x768 Thus, it really seems that the culprit is here that the resume operation does not provide access to the DVO correctly. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
