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 0xd8000000
intel_reg_write 0x70188 0x2000
intel_reg_write 0x70190 0x02ff03ff
intel_reg_write 0x6001c 0x03ff02ff
intel_reg_write 0x70024 0x10000207
intel_reg_write 0x06040 0x0004150d
intel_reg_write 0x06044 0x0004150d
intel_reg_write 0x6014 0xd0820000
intel_reg_write 0x60000 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 0x01000000
intel_reg_write 0x71008 0x80000000
intel_reg_write 0x6101c 0x027f01df
intel_reg_write 0x71024 0x90000206
intel_reg_write 0x06018 0xc08b0000
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

Reply via email to