[Intel-gfx] Questions on display pipes on 835GM
ville.syrjala at linux.intel.com
Sat Oct 5 13:44:32 CEST 2013
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
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.
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
More information about the Intel-gfx