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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
