Re: More questions and patches for 835GM/ns2501 DVO

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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 resolution
> > >>(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/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 *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 == PIPE_A && (dev_priv->quirks & QUIRK_PIPEA_FORCE))
+       if (pipe == 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älä
Intel OTC