Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 6月, 2013 6 次提交
    • D
      drm/i915: move shared_dpll into the pipe config · a43f6e0f
      由 Daniel Vetter 提交于 
      With the big sed-job prep work done this is now really simple. With
the exception that we only assign the right shared dpll id in the
->mode_set callback but also depend upon the old one still being
around.

Until that mess is fixed up we need to jump through a few hoops to
keep the old value save.

v2: Kill the funny whitespace spotted by Chris.

v3: Move the shared_dpll pipe config fixup into this patch as noticed
by Ville. Also unconditionally set the shared_dpll with the current
one, since otherwise we won't handle direct pch port -> cpu edp
transitions correctly.

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>
      a43f6e0f
    • 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
  3. 10 6月, 2013 2 次提交
  5. 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
  7. 07 6月, 2013 8 次提交
  9. 06 6月, 2013 20 次提交
  11. 05 6月, 2013 3 次提交