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