Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 3月, 2015 1 次提交
  3. 23 2月, 2015 1 次提交
  5. 14 2月, 2015 5 次提交
  7. 09 2月, 2015 1 次提交
  9. 31 1月, 2015 2 次提交
    • M
      drm/i915: Don't do posting reads on getting forcewake · 07859504
      由 Mika Kuoppala 提交于 
      The checking for ack and also any subsequent mmio access
will serialize with setting the forcewake bit. Drop the
posting read as superfluous.

Note that in the put side we still want to keep the posting read
as it will ensure that the hw sees our forcewake release in a
timely manner and doesn't keep the hw powered up.

Comment from Chris:

On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > IIRC the posting read from same cache line actually fixed real bugs. So
> > I'm a bit worried about dropping them. But I suppose it's possible only
> > the _put side was important for those bugs.
>
> I found these:
>
> commit 6af2d180
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Jul 26 16:24:50 2012 +0200
>
>     drm/i915: fix forcewake related hangs on snb
>
> commit 8dee3eea
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Sat Sep 1 22:59:50 2012 -0700
>
>     drm/i915: Never read FORCEWAKE
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51738
> https://bugs.freedesktop.org/show_bug.cgi?id=52424
>
> The snb here seems to survive gem_dummy_reloc_loop and
> gem_ring_sync_loop in here with the get side posting removed.

Note that we kept the once associated with #52424, but judging by my
comments in #51738 the posting read is just a band aid anyway as a full
mb() itself was not adequate.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: paste relevant review discussion in.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      07859504
    • M
      drm/i915: Do uncore early sanitize after domain init · f9b3927a
      由 Mika Kuoppala 提交于 
      intel_uncore_early_sanitize() will reset the forcewake registers. When
forcewake domains were introduced, the domain init was done after the
sanitization of the forcewake registers. And as the resetting of
registers use the domain accessors, we tried to reset the forcewake
registers with unitialized forcewake domains and failed.

Fix this by sanitizing after all the domains have been initialized. Do
per domain clearing of forcewake register on domain init so that
IVB can do early access to ECOBUS do determine the final configuration.

This regression was introduced in

commit 05a2fb15
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Jan 19 16:20:43 2015 +0200

    drm/i915: Consolidate forcewake code

v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NOlof Johansson <olof@lixom.net>
Tested-by: Darren Hart <dvhart@linux.intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f9b3927a
  11. 27 1月, 2015 8 次提交
  13. 15 12月, 2014 2 次提交
    • D
      drm/i915: Forcewake Register Range changes for CHV · db5ff4ac
      由 Deepak S 提交于 
      According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

v2: Update media forcewake range (Ville)
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      db5ff4ac
    • D
      drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON · 5f77eeb0
      由 Daniel Vetter 提交于 
      Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

v5: Chris suggested to add the case to MISSING_CASE for speedier
debug.

v6: Even some gcc 4.9 versions don't see through the maze, so give up
for now. Keep the skeleton and MISSING_CASE stuff though.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      5f77eeb0
  15. 03 12月, 2014 6 次提交
  17. 20 11月, 2014 2 次提交
  19. 18 11月, 2014 2 次提交
    • V
      drm/i915: Drop WaRsForcewakeWaitTC0:vlv · 2fe486c7
      由 Ville Syrjälä 提交于 
      GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give
0x0 no matter what the state of the render and media wells.

There was also some hint in the Gunit HAS that thread status not being
needed on VLV, and hence dropped when bringing stuff over from the IVB
design. Not really a definite comment about the specific register itself
though.

Also the w/a itself is no longer listed for VLV in the database. It was
there some time ago in the past, but I guess someone figured out the
mistake and dropped it.

So let's just drop it from the code as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2fe486c7
    • V
      drm/i915: Drop the HSW special case from __gen6_gt_wait_for_thread_c0() · eb88bd1b
      由 Ville Syrjälä 提交于 
      Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same
meaning since SNB. So treating them as something special for HSW doesn't
make sense to me.

Also the bits *seem* to work exactly the same way on IVB, HSW GT2 and
HSW GT3. At least intel_reg_read gives the identical results on all
platforms with and without forcewake.

Also the HSW PM guide rev 0.99 (ww05 2013) doesn't say anything about
those bits. It just says to poll for bits [2:0]. As does the more recent
BDW PM guide.

So just drop the HSW special case and treat all platforms the same way.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eb88bd1b
  21. 14 11月, 2014 1 次提交
  23. 08 11月, 2014 2 次提交
  25. 24 10月, 2014 2 次提交
  27. 24 9月, 2014 1 次提交
  29. 19 9月, 2014 1 次提交
  31. 03 9月, 2014 1 次提交
  33. 23 7月, 2014 2 次提交
    • P
      drm/i915: BDW can also detect unclaimed registers · 66bc2cab
      由 Paulo Zanoni 提交于 
      By the time I wrote this patch, it allowed me to catch some problems.
But due to patch reordering - in order to prevent fake "regression"
reports - this patch may be merged after the fixes of the problems
identified by this patch.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      66bc2cab
    • P
      drm/i915: reorganize the unclaimed register detection code · 5978118c
      由 Paulo Zanoni 提交于 
      The current code only runs when we do an I915_WRITE operation. It
checks if the unclaimed register flag is set before we do the
operation, and then it checks it again after we do the operation. This
double check allows us to find out if the I915_WRITE operation in
question is the bad one, or if some previous code is the bad one. When
it finds a problem, our code uses DRM_ERROR to signal it.

The good thing about the current code is that it detects the problem,
so at least we can know we did something wrong. The problem is that
even though we find the problem, we don't really have much information
to actually debug it. So whenever I see one of these DRM_ERROR
messages on my systems, the first thing I do is apply a patch to
change the DRM_ERROR to a WARN and also check for unclaimed registers
on I915_READ operations. This local patch makes things even slower,
but it usually helps a lot in finding the bad code.

The first point here is that since the current code is only useful to
detect whether we have a problem or not, but it is not really good to
find the cause of the problem, I don't think we should be checking
both before and after every I915_WRITE operation: just doing the check
once should be enough for us to quickly detect problems. With this
change, the code that runs by default for every single user will only
do 1 read operation for every single I915_WRITE, instead of 2. This
patch does this change.

The second point is that the local patch I have should be upstream,
but since it makes things slower it should be disabled by default. So
I added the i915.mmio_debug option to enable it.

So after this patch, this is what will happen:
 - By default, we will try to detect unclaimed registers once after
   every I915_WRITE operation. Previously we tried twice for every
   I915_WRITE.
 - When we find an unclaimed register we will still print a DRM_ERROR
   message, but we will now tell the user to try again with
   i915.mmio_debug=1.
 - When we use i915.mmio_debug=1 we will try to find unclaimed
   registers both before and after every I915_READ and I915_WRITE
   operation, and we will print stack traces in case we find them.
   This should really help locating the exact point of the bad code
   (or at least finding out that i915.ko is not the problem).

This commit also opens space for really-slow register debugging
operations on other platforms. In theory we can now add lots and lots
of debug code behind i915.mmio_debug, enable this option on our tests,
and catch more problems.

v2: - Remove not-so-useful comments (Daniel)
    - Fix the param definition macros (Rodrigo)
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5978118c