From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: Questions on display pipes on 835GM Date: Sat, 5 Oct 2013 14:44:32 +0300 Message-ID: <20131005114432.GE9395@intel.com> References: <1377298288-2830-1-git-send-email-przanoni@gmail.com> <20130830172552.GN11428@intel.com> <29427_1378101775_52242A0E_29427_747_1_20130902060151.GE9374@phenom.ffwll.local> <524FCEE8.4010307@math.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id DD19FE5CF4 for ; Sat, 5 Oct 2013 04:44:36 -0700 (PDT) Content-Disposition: inline In-Reply-To: <524FCEE8.4010307@math.tu-berlin.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Thomas Richter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org 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 =3D container_of(dvo, struct intel_dvo, dev); pipe =3D 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- = Ville Syrj=E4l=E4 Intel OTC