From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: More questions and patches for 835GM/ns2501 DVO Date: Mon, 4 Nov 2013 17:48:16 +0200 Message-ID: <20131104154816.GS13047@intel.com> References: <52768009.7070905@math.tu-berlin.de> <20131103171208.GA4167@phenom.ffwll.local> <19544_1383498802_52768431_19544_2610_1_20131103171348.GB4167@phenom.ffwll.local> <52769D39.5070501@math.tu-berlin.de> <19544_1383513468_5276BD7B_19544_3653_1_20131103211814.GC4167@phenom.ffwll.local> <5276D7BA.4090401@math.tu-berlin.de> <19544_1383549334_52774996_19544_5502_1_CAKMK7uEPjjCsqYTpyO+Bes1eg5b8fVfGFkzQFtwDPxYNe4KwRw@mail.gmail.com> <52778BA0.90604@math.tu-berlin.de> <20131104151509.GF4167@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id 3E7A8FA6DE for ; Mon, 4 Nov 2013 07:48:20 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131104151509.GF4167@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Mon, Nov 04, 2013 at 04:15:09PM +0100, Daniel Vetter wrote: > On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote: > > Hi Daniel, > > >>I also tried a lot with the two-monitor case and again went deeply in= to the > > >>DPLL setup logic. > > >>The differences I observed before are simply due to the initial resol= ution > > >>(800x600), in the final > > >>resolution, the DPLL settings are actually correct. What I get there = is: > > >I suspect that due to the pipe A quirk logic we actually get the setup > > >sequence for the DPLLs completely wrong. This will require a bit more > > >magic to make it work correctly ... But I have some ideas. > > >-Daniel > > Well, maybe. The register contents that are listed in my mail are > > read out from the hardware exactly when the > > DVO gets stuck, actually right before it. From what I can see from > > there is that the PLL setup and DVO setup > > look actually ok (from what I can tell). What is also remarkable is > > that the DVO-reenable logic does succeed by > > writing the same value to the DPLL_A and DPLL_B registers, which is > > the proper value for a 1024x768 screen. However, > > the DPLL_B register value is correct, whereas the DPLL_A register > > contains values that are likely useful for the VGA > > output. > > = > > Now, here is the miracle: The DVOC register indicates that the DVO > > gets its input from pipe B. However, writing the > > correct value into DPLL_A (!) (remember, DPLL_B is already set > > correctly) revives the DVO. > > = > > Thus, I wonder how this can be. The only explanation I have is that > > the DVO is still fed by pipe A, and not by pipe B. > > Maybe there is something else that needs to be done to switch the > > DVO to pipe B. > = > That's actually my suspicion. Most of these registers here are > double-buffered and only take effect if preconditions are right. Due to > our pipe A quirk we never shut down pipe A, so the pll updates might not > actually take effect at all (but the registers have the new values > already). There's unfortunately no registers to get at the actual hw > state, and only later hw generations have added at least a few bits to > indicate whether the large transitions (on/off) have actually happened. > = > The problem is that I don't yet have a clear idea how to do the pipe A > quirk correctly :( Could it be that we should only have the 2x DVO clock enable bit set in the correct DPLL register? diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/in= tel_display.c index 8f40ae3..4b02890 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1470,8 +1470,11 @@ static void i9xx_enable_pll(struct intel_crtc *crtc) static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pipe = pipe) { /* Don't disable pipe A or pipe A PLLs if needed */ - if (pipe =3D=3D PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE)) + if (pipe =3D=3D PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE)) { + /* disable 2x DVO clock output */ + I915_WRITE(DPLL(pipe), I915_READ(DPLL(pipe) & ~DPLL_2X_MODE= )); return; + } = /* Make sure the pipe isn't still relying on us */ assert_pipe_disabled(dev_priv, pipe); > -Daniel > -- = > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- = Ville Syrj=E4l=E4 Intel OTC