From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Richter Subject: Partial success - Fixing resume from s2ram on S6010 Date: Mon, 09 Jun 2014 12:57:46 +0200 Message-ID: <5395932A.5080904@math.tu-berlin.de> References: <5394EE4E.3040402@rus.uni-stuttgart.de> <1402296430-5065-1-git-send-email-chris@chris-wilson.co.uk> <20140609083025.GL27580@intel.com> <28223_1402303866_5395757A_28223_3428_1_20140609085045.GE16767@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070109000609050206090906" Return-path: Received: from charon.rus.uni-stuttgart.de (charon.rus.uni-stuttgart.de [129.69.192.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 118096E07B for ; Mon, 9 Jun 2014 03:57:55 -0700 (PDT) In-Reply-To: <28223_1402303866_5395757A_28223_3428_1_20140609085045.GE16767@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --------------070109000609050206090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------070109000609050206090906 Content-Type: text/plain; name="99video" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="99video" #!/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 --------------070109000609050206090906 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --------------070109000609050206090906--