From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Richter Subject: Re: Fujitsu S6010 still woes (partially) Date: Tue, 08 Apr 2014 14:05:50 +0200 Message-ID: <5343E61E.90702@rus.uni-stuttgart.de> References: <15021_1396784108_53413BEC_15021_2866_1_53413A1F.5000202@math.tu-berlin.de> <5343C5DE.80204@rus.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from hydra.rus.uni-stuttgart.de (hydra.rus.uni-stuttgart.de [129.69.192.3]) by gabe.freedesktop.org (Postfix) with ESMTP id D61F46E9CB for ; Tue, 8 Apr 2014 05:06:54 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org Am 08.04.2014 13:52, schrieb Daniel Vetter: > On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter > > Hm, my X30 also locks up here on resume. What hack do you apply to > make the ns2501 driver get through resume? I don't care about black > screen, but I just wonder whether my X30 has the same issue - atm it > hard-hangs. Actually, the same "enable_DVO" hack that was there before, where I just poke the registers in the same way the script does it (see below). That is, whenever it detects that the DVO is "stuck", it configures the pipes to enable it. This is of course a hack, i.e. it would be a much cleaner solution if the suspend mechanism of the intel driver would configure the pipes first before trying to program or detect the DVO. This is what does it: intel_reg_write 0x02120 0x0 intel_reg_write 0x61100 0x00000c00 intel_reg_write 0x61160 0x10004084 intel_reg_write 0x6101c 0x027f01df 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 0x71180 0x01000000 intel_reg_write 0x70188 0x00001000 intel_reg_write 0x20d8 0x10E0108 intel_reg_write 0x20dc 0x102 intel_reg_write 0x61120 0x0 intel_reg_write 0x6014 0xD0820000 intel_reg_write 0x6018 0x0 intel_reg_write 0x61140 0x80004084 intel_reg_write 0x61160 0x90004084 Actually, much of that is not required. You only need to configure the output on the right pipe (pipe B) and set the x2 flag for the DVO. The display timing (vblank,vtotal, hblank,htotal) are irrelevant. Also, from the linux suspend mechanism, /usr/lib/pm-utils/sleep.d/99video is just useless or breaks more than it helps. I just removed it. It tries some weird workarounds that are not beneficial, and the driver (once corrected) should work without those. Instead, you can place the above into sleep.d/99video plus a bit of glue logic to run it on resume. This *almost* works, i.e. I do get a working display, but it is driven through the wrong pipe. Greetings, Thomas