Re: Fujitsu S6010 still woes (partially)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter
<richter@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

With the latest upstream code we _do_ enable the pipes before we fire
up the dvo connector. Where you experiments with that? The patch was

commit 48f34e10169dbb3dd7a19af64e328492b7f54af4
Author: Daniel Vetter <daniel.vetter@xxxxxxxx>
Date:   Tue Oct 8 12:25:42 2013 +0200

    drm/i915/dvo: call ->mode_set callback only when the port is running

-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux