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 18:05:16 +0200 Message-ID: <20131104160515.GU13047@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> <20131104154816.GS13047@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 2240DEEED6 for ; Mon, 4 Nov 2013 08:05:41 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131104154816.GS13047@intel.com> 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 05:48:16PM +0200, Ville Syrj=E4l=E4 wrote: > 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 = into the > > > >>DPLL setup logic. > > > >>The differences I observed before are simply due to the initial res= olution > > > >>(800x600), in the final > > > >>resolution, the DPLL settings are actually correct. What I get ther= e is: > > > >I suspect that due to the pipe A quirk logic we actually get the set= up > > > >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/= intel_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 *crt= c) > static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pip= e 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_MO= DE)); And that should be ~DPLL_DVO_2X_MODE obviously. > 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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- = Ville Syrj=E4l=E4 Intel OTC