[Intel-gfx] More questions and patches for 835GM/ns2501 DVO

[Thomas Richter]

On 03.11.2013 22:18, Daniel Vetter wrote:
>
> Hm, that would mean that the cursor is somehow stuck in the enabled state,
> despite that we've tried to disabled it very hard. Can you please try out
> the below patch? If this doesn't work please take not of the different
> WARNINGs you're hitting and whether it's always the same one with the same
> calltrace or something different.
>
> I think for now we should try to get the single monitor case working - I
> have a few theories for the dual-screen issues, but there's not much point
> working on them if the simple case doesn't work yet.
>
> Also I think I'll merge the two patches if they don't make things worse
> for you, imo it's the right approach and at least conceptually should be
> able to avoid all these retry loops.
Thanks for the patches. Tried quite a bit, and haven't seen the warning 
yet. Looks like the one-monitor
case works quite fine now, except that the boot console is vertically 
"off", which is just annoying though
not problematic.

I also tried a lot with the two-monitor case and again went deeply into 
the DPLL setup logic.
The differences I observed before are simply due to the initial 
resolution (800x600), in the final
resolution, the DPLL settings are actually correct. What I get there is:

--- Configuration found for regular display 1024x768:

Nov  3 23:33:30 tyleet kernel: [    9.122481] [drm:i9xx_find_best_dpll], 
clock.m1 = 21
Nov  3 23:33:30 tyleet kernel: [    9.122483] [drm:i9xx_find_best_dpll], 
clock.m2 = 13
Nov  3 23:33:30 tyleet kernel: [    9.122485] [drm:i9xx_find_best_dpll], 
clock.n  = 4
Nov  3 23:33:30 tyleet kernel: [    9.122488] [drm:i9xx_find_best_dpll], 
clock.p1 = 4

for 800x600:

Nov  3 23:38:41 tyleet kernel: [  368.725507] [drm:i9xx_find_best_dpll], 
clock.m1 = 19
Nov  3 23:38:41 tyleet kernel: [  368.725514] [drm:i9xx_find_best_dpll], 
clock.m2 = 13
Nov  3 23:38:41 tyleet kernel: [  368.725521] [drm:i9xx_find_best_dpll], 
clock.n  = 4
Nov  3 23:38:41 tyleet kernel: [  368.725528] [drm:i9xx_find_best_dpll], 
clock.p1 = 6

640 x 480:

Nov  3 23:40:05 tyleet kernel: [  452.965855] [drm:i9xx_find_best_dpll], 
clock.m1 = 20
Nov  3 23:40:05 tyleet kernel: [  452.965862] [drm:i9xx_find_best_dpll], 
clock.m2 = 14
Nov  3 23:40:05 tyleet kernel: [  452.965869] [drm:i9xx_find_best_dpll], 
clock.n  = 3
Nov  3 23:40:05 tyleet kernel: [  452.965876] [drm:i9xx_find_best_dpll], 
clock.p1 = 12

And even in the two-monitor case, the DPLL for DPLL_B is setup 
correctly. Thus, *that* does not seem the
cause of the problem.

What is different is the DVO setting:
bit differences:

In the two-monitor case, the internal DVOC register is 0xd000409c, in 
the one-monitor case it is: 0x90004084

Differences are:

DVO bit 30 should be 0 is 1.  DVO_PIPE_B_SELECT    enabled
DVO bit 4 should be 0 is 1.   DVO_VSYNC_ACTIVE_HIGH
DVO bit 3 should be 0 is 1.   DVO_HSYNC_ACTIVE_HIGH

Now, the bit 30 is clear, though I wonder why the sync signal is inverted.

Anyhow, something else makes we wonder. The DVO-reactivation code *does* 
work (the DVO-settings do not block,
though the DVO blocks afterwards), and the code is just:

     I915_WRITE(_DPLL_A, 0xd0820000);
     I915_WRITE(_DPLL_B, 0xd0820000);

Thus, while the DPLL_B register is just overwritten by the same value, 
though DPLL_A changes. The fact that this actually
unlocks the DVO means to me that actually bit 30 of the DVOC register 
*does not* work to re-assign the DVO to pipe B.
The way how the system behaves is rather consistent with the hypothesis 
that the DVO is still assigned to pipe A????

Is there any other bit or setting that controls which DVO goes to which 
pipe? It looks like the pipe output control does
not work correctly.

Greetings,
     Thomas