[Intel-gfx] More questions and patches for 835GM/ns2501 DVO

[Ville Syrjälä]

On Mon, Nov 04, 2013 at 05:48:16PM +0200, Ville Syrjälä 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 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));

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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC