public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Thomas Richter <thor@math.tu-berlin.de>
To: intel-gfx@lists.freedesktop.org
Subject: Partial success - Fixing resume from s2ram on S6010
Date: Mon, 09 Jun 2014 12:57:46 +0200	[thread overview]
Message-ID: <5395932A.5080904@math.tu-berlin.de> (raw)
In-Reply-To: <28223_1402303866_5395757A_28223_3428_1_20140609085045.GE16767@nuc-i3427.alporthouse.com>

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

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


[-- Attachment #2: 99video --]
[-- Type: text/plain, Size: 1846 bytes --]

#!/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

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2014-06-09 10:57 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 16:15 [PATCH 00/15] drm/i915: Fix 830M/ns2501 for real, well almost ville.syrjala
2014-06-05 16:15 ` [PATCH 01/15] drm/i915: Use named initializers for gmch wm params ville.syrjala
2014-06-05 20:43   ` Chris Wilson
2014-06-05 21:02     ` Thomas Richter
2014-06-05 21:33     ` Bug reports on 830MG patches (thanks, but more trouble) Thomas Richter
2014-06-06  8:46       ` Ville Syrjälä
2014-06-06 17:24         ` Thomas Richter
2014-06-06 20:08           ` Ville Syrjälä
2014-06-06 21:09             ` Thomas Richter
2014-06-06 21:41               ` Ville Syrjälä
2014-06-08 21:29             ` [PATCH] Check for a min level when computing the watermark Thomas Richter
2014-06-06 16:38     ` [PATCH 01/15] drm/i915: Use named initializers for gmch wm params Daniel Vetter
2014-06-05 16:15 ` [PATCH 02/15] drm/i915: Fix gen2 planes B and C max watermark value ville.syrjala
2014-06-05 16:15 ` [PATCH 03/15] drm/i915: Don't get hw state from DVO chip unless DVO is enabled ville.syrjala
2014-06-06 16:39   ` Daniel Vetter
2014-06-05 16:15 ` [PATCH 04/15] drm/i915: ns2501 is on DVOB ville.syrjala
2014-06-06 16:57   ` Daniel Vetter
2014-06-06 21:46     ` Ville Syrjälä
2014-06-05 16:15 ` [PATCH 05/15] drm/i915: Enable DVO between mode_set and dpms hooks ville.syrjala
2014-06-05 16:15 ` [PATCH 06/15] drm/i915: Don't call DVO mode_set hook on DPMS changes ville.syrjala
2014-06-05 16:15 ` [PATCH 07/15] drm/i915: Kill useless ns2501_dump_regs ville.syrjala
2014-06-05 16:15 ` [PATCH 08/15] drm/i915: Rewrite ns2501 driver a bit ville.syrjala
2014-06-05 16:15 ` [PATCH 09/15] drm/i915: Ignore VBT int_crt_support on 830M ville.syrjala
2014-06-06 17:00   ` Daniel Vetter
2014-06-06 19:44     ` [PATCH v2 " ville.syrjala
2014-06-06 20:13       ` Daniel Vetter
2014-06-07 20:37         ` [Patch] Add minimum watermark level for I830 Thomas Richter
2014-06-06 21:15       ` [PATCH v2 09/15] drm/i915: Ignore VBT int_crt_support on 830M Bob Paauwe
2014-06-06 22:23         ` Daniel Vetter
2014-06-06 22:51           ` Jesse Barnes
     [not found]         ` <2094_1402093395_53923F53_2094_10301_1_CAKMK7uGAnNP4VR9+zXd0KD5v0Vo=XuDS=NhRNFRqHKcae7T4XQ@mail.gmail.com>
2014-06-07 17:32           ` Thomas Richter
2014-10-24 13:23       ` Jani Nikula
2014-10-24 14:11         ` Ville Syrjälä
2014-06-05 16:15 ` [PATCH 10/15] drm/i915: Fix DVO 2x clock enable " ville.syrjala
2014-06-05 16:16 ` [PATCH 11/15] Revert "drm/i915: Nuke pipe A quirk on i830M" ville.syrjala
2014-06-05 16:16 ` [PATCH 12/15] drm/i915: Add pipe B force quirk for 830M ville.syrjala
2014-06-05 16:16 ` [PATCH 13/15] drm/i915: Eliminate rmw from .update_primary_plane() ville.syrjala
2014-06-06  0:02   ` Matt Roper
2014-06-06 19:45   ` [PATCH v2 " ville.syrjala
2014-06-05 16:16 ` [PATCH 14/15] drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane() ville.syrjala
2014-06-06  0:02   ` Matt Roper
2014-06-06  8:40     ` Ville Syrjälä
2014-06-06 19:46     ` [PATCH v2 " ville.syrjala
2014-06-05 16:16 ` [PATCH 15/15] drm/i915: Check pixel clock in ns2501 mode_valid hook ville.syrjala
2014-06-06 19:47 ` [PATCH 16/15] drm/i915: Pass intel_crtc to intel_disable_pipe() and intel_wait_for_pipe_off() ville.syrjala
2014-06-06 19:47   ` [PATCH 17/15] drm/i915: Disable double wide even when leaving the pipe on ville.syrjala
2014-06-06 22:09     ` [PATCH v2 " ville.syrjala
2014-06-08 23:14       ` Deadlock in intel_enable_pipe_a() Thomas Richter
2014-06-09  6:47         ` [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc() Chris Wilson
2014-06-09  8:30           ` Ville Syrjälä
2014-06-09  8:50             ` Chris Wilson
     [not found]             ` <28223_1402303866_5395757A_28223_3428_1_20140609085045.GE16767@nuc-i3427.alporthouse.com>
2014-06-09 10:57               ` Thomas Richter [this message]
2014-06-09 11:08                 ` Partial success - Fixing resume from s2ram on S6010 Ville Syrjälä
     [not found]                 ` <28223_1402312148_539595D3_28223_4884_1_20140609110857.GM27580@intel.com>
2014-06-09 11:19                   ` Thomas Richter
2014-06-09 11:31                     ` Ville Syrjälä
     [not found]                     ` <2086_1402313568_53959B5F_2086_895_1_20140609113155.GN27580@intel.com>
2014-06-09 12:33                       ` Thomas Richter
2014-06-09 12:57                       ` Thomas Richter
2014-06-09 18:41                       ` Thomas Richter
2014-06-09 19:46                         ` [PATCH] drm/i915: Init important ns2501 registers ville.syrjala
     [not found]                         ` <28223_1402343538_53961072_28223_7661_1_1402343204-28608-1-git-send-email-ville.syrjala@linux.intel.com>
2014-06-09 20:58                           ` Thomas Richter
2014-06-09 22:29                           ` Thomas Richter
2014-06-10 14:04                             ` Ville Syrjälä
     [not found]                             ` <29040_1402409145_539710B9_29040_2220_1_20140610140430.GD27580@intel.com>
2014-06-10 16:38                               ` Thomas Richter
2014-06-18 16:03                       ` i830GM on IBM R31 works with alm_fixes5 repository Thomas Richter
2014-06-10  7:02             ` [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc() Daniel Vetter
2014-06-10  8:53               ` Ville Syrjälä
2014-06-10  9:22                 ` Daniel Vetter
2014-06-10  6:59           ` Daniel Vetter
2014-06-10  7:13             ` Chris Wilson
2014-06-06 19:47   ` [PATCH 18/15] drm/i915: Preserve VGACNTR bits from the BIOS ville.syrjala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5395932A.5080904@math.tu-berlin.de \
    --to=thor@math.tu-berlin.de \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox