[Intel-gfx] Questions on display pipes on 835GM

[Ville Syrjälä]

On Sat, Oct 05, 2013 at 10:33:44AM +0200, Thomas Richter wrote:
> Hi Daniel, hi folks,
> 
> just playing again with the support code for the NS2501 DVO in my old 
> laptop. Despite finding one bug I'll send a patch
> for soon, there is something else that makes we wonder, and that is the 
> connection to external monitors.
> 
> Just to remind you, the NS2501 in this specific laptop, or probably in 
> general, seems to be clocked by parts of the
> sync signal of the display pipe. If the display pipe does not deliver 
> the right clock, the DVO locks up and does not
> react anymore to any commands on the i2c bus. The current ns2501 DVO 
> driver code thus includes a little hack that,
> if it detects that the DVO remains silent, forces the pipe A DLL to the 
> right values to reactivate it. This is a hack, though
> it works.
> 
> Now, interesting things happen if I connect an external monitor: The 
> i915 code reads the edid data from the monitor,
> finds that the monitor prefers a high clock rate (here an old CRT) of 
> 75Hz vertical, and reconfigures the display pipe.
> Interestingly, this *also* seems to modify the display pipe of the DVO 
> which should actually be connected to a
> different pipe. Anyhow, as now the DVO sees a clock signal out of its 
> operating range (60Hz vertical) it locks up and
> no display appears *on the internal* LCD. In fact, the display breaks 
> down completely and all you get is a residual
> display on the TFT which no longer receives refresh. If I force the 
> clocking of the external monitor to 60Hz, both
> displays work again. So for me it looks like the role of the display 
> pipes is somehow swapped if I connect an external
> monitor - it seems as if in this case either both monitors are driven by 
> the same pipe (why?) of that now pipe B feeds
> the DVI1 hence the DVO and the TFT, and pipe A feeds the external monitor.
> 
> Thus, here my questions:
> *) Can I, within the dvo driver code, somehow detect to which display 
> pipe the DVO and thus the TFT is actually connected
> to?

Something like this:
intel_dvo = container_of(dvo,  struct intel_dvo, dev);
pipe = to_intel_ctrc(intel_dvo.base.base.crtc)->pipe

But currectly it looks like struct intel_dvo isn't visible 
outside intel_dvo.c which would need changing, or the hacks
need to be moved into intel_dvoc.

> *) Can I somehow prohibit that the DVO is driven by *anything but* the 
> 60Hz signal it likes, thus to prevent the lock-up
> and disable the weird hack I'm currently using?

I think currently it should be driven at the correct rate or not at all.


The CRT port can only be driven by pipe A, so I think that explains why
your hacks may go bad when a CRT monitor is used.

I see several problems with the ns2501 code.
- it assumes DVOC. While that may be true always, getting the correct
  register from .dvo_reg is trivial
- assumes pipe A, which as stated isn't always true. During modesetting
  operations you can get the correct crtc via intel_dvo.base.base.crtc,
  from which you can get the pipe.
- the hack doesn't set up all the DPLL registers, but I suppose we
  could try to eliminate the hack. One thing that would need maybe
  fixing is the get_hw_state function. We could perhaps just change
  intel_dvo.c not to call the connector get_hw_state func if the
  encoder says the dvo port isn't active.

> 
> Somehow, the logic which display pipe drives which output is still 
> unclear to me. Would be great if somebody could help
> me out here.
> 
> Thanks,
>      Thomas
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC