1. 11 6月, 2013 5 次提交
    • D
      drm/i915: switch crtc->shared_dpll from a pointer to an enum · e2b78267
      Daniel Vetter 提交于
      Dealing with discrete enum values is simpler for hw state readout and
      pipe config computations than pointers - having neat names instead of
      chasing pointers should look better in the code.
      
      This isn't a that good reason for pch plls, but on haswell we actually
      have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having
      explicit names should help there.
      
      Since this also adds the intel_crtc_to_shared_dpll helper to further
      abstract away the crtc -> dpll relationship this will also help to
      make the next patch simpler, which moves the shared dpll into the pipe
      configuration.
      
      Also note that for uniformity we have two special dpll ids: NONE for
      pipes which need a shared pll but don't have one (yet) and private for
      when there's a non-shared pll (e.g. per-pipe or per-port pll).
      
      I've thought whether we should also add a 2nd enum for the type of the
      pll we want (for really generic pll selection code) but thrown that
      idea out again - likely there's too much platform craziness going on
      to be able to share the pll selection logic much.
      
      Since this touched all the shared_pll functions a bit I've also done
      an s/intel_crtc/crtc/ replacement on a few of them.
      
      v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use
      it to check that the compute config stage assigns a dpll to every pipe.
      But since that code isn't ready yet until we move the dpll selection out
      of the ->mode_set callback, there's no use for it.
      
      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>
      e2b78267
    • 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 1 次提交
    • D
      drm/i915: check for strange pfit pipe assignemnt on ivb/hsw · cb8b2a30
      Daniel Vetter 提交于
      Panel fitters on ivb/hsw are not created equal since not all of them
      support the new high-quality upscaling mode. To offset this the hw
      allows us to freely assign the pfits to pipes.
      
      Since our code currently doesn't support this we might fall over when
      taking over firmware state. So check for this case and WARN about it.
      We can then improve the code once we've hit this in the wild. Or once
      we decide to support the improved upscale modes, though that requires
      global arbitrage of modeset resources across crtcs.
      
      v2: Check for IS_GEN7 instead of IS_IVB || IS_HSW as suggested by
      Paulo in his review comment.
      Suggested-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cb8b2a30