From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Richter <thor@math.tu-berlin.de>
Subject: Re: Partial success - Fixing resume from s2ram on S6010
Date: Mon, 09 Jun 2014 13:19:46 +0200
Message-ID: <53959852.4000504@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>
 <5395932A.5080904@math.tu-berlin.de>
 <28223_1402312148_539595D3_28223_4884_1_20140609110857.GM27580@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from charon.rus.uni-stuttgart.de (charon.rus.uni-stuttgart.de
 [129.69.192.1])
 by gabe.freedesktop.org (Postfix) with ESMTP id 418FE6E11D
 for <intel-gfx@lists.freedesktop.org>; Mon,  9 Jun 2014 04:20:18 -0700 (PDT)
In-Reply-To: <28223_1402312148_539595D3_28223_4884_1_20140609110857.GM27580@intel.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

Am 09.06.2014 13:08, schrieb Ville Syrj=E4l=E4
> 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