1. 11 6月, 2013 4 次提交
    • D
      drm/i915: s/pch_pll/shared_dpll/ · e72f9fbf
      Daniel Vetter 提交于
      For fastboot we need some support to read out the sharing state of
      plls, at least for platforms where they can be shared (or freely
      assigned at least). Now for ivb we already have pretty extensive
      infrastructure for tracking pch plls, and it took us an aweful lot of
      tries to get that remotely right. Note that hsw could also share plls,
      but even now they're already freely assignable. So we need this on
      more than just ivb.
      
      So on top of the usual fastboot fun pll sharing seems to be an
      additional step up in fragility. Hence a common infrastructure for all
      shared/freely assignable display plls seems to be in order.
      
      The plan is to have a bit of dpll hw state readout code, which can be
      used individually, but also to fill in the pipe config. The hw state
      cross check code will then use that information to make sure that
      after every modeset every pipe still is connected to a pll which still
      has the correct configuration - a lot of the pch pll sharing bugs
      where due to incorrect sharing.
      
      We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
      job.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e72f9fbf
    • D
      drm/i915: lock down pch pll accouting some more · f4a091c7
      Daniel Vetter 提交于
      Before I start to make a complete mess out of this, crank up
      the paranoia level a bit.
      
      v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid
      as spotted by Ville since we currently only put the dpll when we
      already have the new pipe config. So a direct pch port -> cpu edp
      transition will hit this.
      
      v3: Now that I've lifted my blinders add the WARN_ON Ville requested.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f4a091c7
    • D
      drm/i915: conditionally disable pch resources in ilk_crtc_disable · d925c59a
      Daniel Vetter 提交于
      Simlar to how disable already works on haswell. This is possible
      since we now carefully track the pch state in the pipe config.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d925c59a
    • D
      drm/i915: fix up pch pll handling in ->mode_set · cdbd2316
      Daniel Vetter 提交于
      We ->mode_set is called we can't just blindly reuse an existing pll
      since that might be shared with a different, still active pch output.
      
      v2: Only update the pll settings when the pch pll is know to be
      unused, otherwise we can wreak havoc with a running pipe. Which in the
      case of DP will likely result in a black screen due to loss of link
      lock.
      
      v3: Tighten up the asserts a bit more, especially make sure that the
      pch pll is still enabled when we try to disable it. This would have
      caught the bug fixed in this patch.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cdbd2316
  2. 10 6月, 2013 2 次提交
  3. 08 6月, 2013 1 次提交
    • V
      drm/i915: Make g4x_fixup_plane() operational again · 22e407d7
      Ville Syrjälä 提交于
      Don't enable the cursor until g4x_fixup_plane() had a chance to do
      cast its magic spell.
      
      Egbert writes:
      "Today I had the chance to test this. First I tried
       if I can still reproduce the blank with this patch
       added when I disable my voodoo g4x_fixup_plane():
       It turned out it still happens however very rarely
       (like 1 out of 20 tries). When I reenabled my voodoo
       the issue still occurred.
       I had to switch two lines around, ie:
      
               intel_enable_plane(dev_priv, plane, pipe);
               if (IS_G4X(dev))
                       g4x_fixup_plane(dev_priv, pipe);
       +       intel_crtc_update_cursor(crtc, true);
      
       to avoid the blank screen issue - which is it didn't
       happen in ~75 tries."
      
      v2: Add a comment to remind people of the ordering constraints
      Acked-by: NEgbert Eich <eich@suse.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      22e407d7
  4. 07 6月, 2013 8 次提交
  5. 06 6月, 2013 20 次提交
  6. 05 6月, 2013 3 次提交
  7. 04 6月, 2013 2 次提交