From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Richter Subject: Re: Questions on display pipes on 835GM Date: Sat, 05 Oct 2013 18:47:05 +0200 Message-ID: <52504289.10107@math.tu-berlin.de> 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> <29761_1380973482_524FFBA9_29761_4042_1_20131005114432.GE9395@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from charon.rus.uni-stuttgart.de (charon.rus.uni-stuttgart.de [129.69.192.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 70FEAE5DF4 for ; Sat, 5 Oct 2013 09:48:21 -0700 (PDT) In-Reply-To: <29761_1380973482_524FFBA9_29761_4042_1_20131005114432.GE9395@intel.com> 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: =?ISO-8859-1?Q?Ville_Syrj=E4l=E4?= Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org Hi Ville, hi Daniel, >> 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. What I currently did is that I'm assuming that the intel_encoder struct is right in front of the dvo structure, and thus I can get the pipe this way. Yuck! However, while I get the proper pipe back, apparently there is a discrepancy of what the i915 believes the DVO is attached to, and which pipe it is actually attached to. That is, if I boot up without an external monitor, everything is fine and my pipe code returns pipe 0, and "unlocks" the DVO correctly. If an external monitor is connected, the DVO locks up again during bootstrap. >> *) 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. True enough, but how to ensure this? > 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. Understood, this makes sense. Thus, DVO would then be at pipe B. How is this switch made, and where? There need to be a register somewhere that tells the i835 which signal goes where. > 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 This is actually no longer required. I experimented a bit with it and all that is necessary to keep the DVO active is the proper timing in the PLL register, either A or B, whatever the DVO is attached to. > - 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. True enough, but this information does not seem to be up to date, or seems to be incorrect if an external monitor is attached. If I'm resetting pipes A and B, then I don't see a problem and my little hack can activate the DVO just fine. However, some part of the i915 driver seem to have loaded an incorrect value into the pipe B PLL, then again creating a lock-up on the internal display. It seems to me that if "mirroring" is enabled, both displays seem to be driven by the same PLL, hence by the same frequency, hence locking up the display. The DVO is awakened by the hack if required, but the TFT is dead anyhow. > - 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. Not necessary, actually. If the PLL registers are set correctly, the DVO is operational. Concerning the get_hw_state(), I also added the hack here to re-enable the DVO if it's stuck, but it doesn't make a difference. Greetings, Thomas