Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 6月, 2015 1 次提交
  3. 18 3月, 2015 1 次提交
  5. 27 2月, 2015 1 次提交
  7. 26 2月, 2015 1 次提交
    • A
      drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions · bc4d91f6
      由 Akash Goel 提交于 
      The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register
are stored, initially by the Driver, inside the dev_priv->rps structure.
Since these values are expected to remain same throughout, there is no real
need to read this register, on dynamic basis, from certain debugfs/sysfs
functions and the values can be instead retrieved from the dev_priv->rps
structure when needed.
For the i915_frequency_info debugfs interface, the frequency values from the
RP_STATE_CAP register only should be used, to indicate the actual Hw state,
since it is principally used for the debugging purpose.

v2: Reverted the changes in i915_frequency_info function, to continue report
    back the frequency values, as per the actual Hw state (Chris)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bc4d91f6
  9. 14 2月, 2015 1 次提交
    • V
      drm/i915: Introduce intel_set_rps() · ffe02b40
      由 Ville Syrjälä 提交于 
      Replace the valleyview_set_rps() and gen6_set_rps() calls with
intel_set_rps() which itself does the IS_VALLEYVIEW() check. The
code becomes simpler since the callers don't have to do this check
themselves.

Most of the change was performe with the following semantic patch:
@@
expression E1, E2, E3;
@@
- if (IS_VALLEYVIEW(E1)) {
-  valleyview_set_rps(E2, E3);
- } else {
-  gen6_set_rps(E2, E3);
- }
+ intel_set_rps(E2, E3);

Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps()
static was done manually. Also valleyview_set_rps() had to be moved a
bit avoid a forward declaration.

v2: Use a less greedy semantic patch

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ffe02b40
  11. 27 1月, 2015 5 次提交
  13. 24 10月, 2014 1 次提交
  15. 03 9月, 2014 1 次提交
  17. 12 7月, 2014 2 次提交
  19. 23 5月, 2014 1 次提交
    • O
      drm/i915: s/i915_hw_context/intel_context · 273497e5
      由 Oscar Mateo 提交于 
      Up until now, contexts had one (and only one) backing object that was
used by the hardware to save/restore render ring contexts (via the
MI_SET_CONTEXT command). Other rings did not have or need this, so
our i915_hw_context struct had a 1:1 relationship with a a real HW
context.

With Logical Ring Contexts and Execlists, this is not possible anymore:
all rings need a backing object, and it cannot be reused. To prepare
for that, rename our contexts to the more generic term intel_context.

No functional changes.
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      273497e5
  21. 05 5月, 2014 1 次提交
  23. 20 3月, 2014 4 次提交
  25. 07 2月, 2014 1 次提交
    • J
      drm/i915: Update rps interrupt limits · b8a5ff8d
      由 Jeff McGee 提交于 
      sysfs changes to rps min and max delay were only triggering an update
of the rps interrupt limits if the active delay required an update.
This change ensures that interrupt limits are always updated.

v2: correct compile issue missed on rebase
v3: add igt testcases to signed-off-by section

Testcase: igt/pm_rps/min-max-config-idle
Testcase: igt/pm_rps/min-max-config-loaded
Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b8a5ff8d
  27. 11 12月, 2013 1 次提交
  29. 08 11月, 2013 1 次提交
  31. 07 11月, 2013 2 次提交
  33. 22 10月, 2013 1 次提交
    • D
      drm/sysfs: sort out minor and connector device object lifetimes. · 5bdebb18
      由 Dave Airlie 提交于 
      So drm was abusing device lifetimes, by having embedded device structures
in the minor and connector it meant that the lifetime of the internal drm
objects (drm_minor and drm_connector) were tied to the lifetime of the device
files in sysfs, so if something kept those files opened the current code
would kfree the objects and things would go downhill from there.

Now in reality there is no need for these lifetimes to be so intertwined,
especailly with hotplugging of devices where we wish to remove the sysfs
and userspace facing pieces before we can unwind the internal objects due
to open userspace files or mmaps, so split the objects out so the struct
device is no longer embedded and do what fbdev does and just allocate
and remove the sysfs inodes separately.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      5bdebb18
  35. 15 10月, 2013 1 次提交
  37. 10 10月, 2013 1 次提交
    • T
      drm/i915: Finish enabling rps before use by sysfs or debugfs · 5c9669ce
      由 Tom O'Rourke 提交于 
      Enabling rps (turbo setup) was put in a work queue because it may
take quite awhile.  This change flushes the work queue to initialize
rps values before use by sysfs or debugfs.  Specifically,
rps.delayed_resume_work is flushed before using rps.hw_max,
rps.max_delay, rps.min_delay, or rps.cur_delay.

This change fixes a problem in sysfs where show functions using
uninitialized values show incorrect values and store functions
using uninitialized values in range checks incorrectly fail to
store valid input values.  This change also addresses similar use
before initialized problems in debugfs.
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5c9669ce
  39. 01 10月, 2013 1 次提交
  41. 21 9月, 2013 1 次提交
  43. 20 9月, 2013 6 次提交
    • J
      drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT · 5ffd494b
      由 Jesse Barnes 提交于 
      Byt doesn't have rc6p and rc6pp support and even more important the
the offsets of the residency registers there's something else. So Just
return a constant 0 to avoid upsetting userspace tools like powertop.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Explain a bit in the commit message what's going on.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5ffd494b
    • B
      drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF · 040d2baa
      由 Ben Widawsky 提交于 
      We'd only ever used this define to denote whether or not we have the
dynamic parity feature (DPF) and never to determine whether or not L3
exists. Baytrail is a good example of where L3 exists, and not DPF.

This patch provides clarify in the code for future use cases which might
want to actually query whether or not L3 exists.

v2: Add /* DPF == dynamic parity feature */
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      040d2baa
    • B
      drm/i915: Do remaps for all contexts · 3ccfd19d
      由 Ben Widawsky 提交于 
      On both Ivybridge and Haswell, row remapping information is saved and
restored with context. This means, we never actually properly supported
the l3 remapping because our sysfs interface is asynchronous (and not
tied to any context), and the known faulty HW would be reused by the
next context to run.

Not that due to the asynchronous nature of the sysfs entry, there is no
point modifying the registers for the existing context. Instead we set a
flag for all contexts to load the correct remapping information on the
next run. Interested clients can use debugfs to determine whether or not
the row has been remapped.

One could propose at this point that we just do the remapping in the
kernel. I guess since we have to maintain the sysfs interface anyway,
I'm not sure how useful it is, and I do like keeping the policy in
userspace; (it wasn't my original decision to make the
interface the way it is, so I'm not attached).

v2: Force a context switch when we have a remap on the next switch.
(Ville)
Don't let userspace use the interface with disabled contexts.

v3: Don't force a context switch, just let it nop
Improper context slice remap initialization, 1<<1 instead of 1<<i, but I
rewrote it to avoid a second round of confusion.
Error print moved to error path (All Ville)
Added a comment on why the slice remap initialization happens.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3ccfd19d
    • B
      drm/i915: Make l3 remapping use the ring · c3787e2e
      由 Ben Widawsky 提交于 
      Using LRI for setting the remapping registers allows us to stream l3
remapping information. This is necessary to handle per context remaps as
we'll see implemented in an upcoming patch.

Using the ring also means we don't need to frob the DOP clock gating
bits.

v2: Add comment about lack of worry for concurrent register access
(Daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Bikeshed the comment a bit by doing a s/XXX/Note - there's
nothing to fix.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c3787e2e
    • B
      drm/i915: Add second slice l3 remapping · 35a85ac6
      由 Ben Widawsky 提交于 
      Certain HSW SKUs have a second bank of L3. This L3 remapping has a
separate register set, and interrupt from the first "slice". A slice is
simply a term to define some subset of the GPU's l3 cache. This patch
implements both the interrupt handler, and ability to communicate with
userspace about this second slice.

v2:  Remove redundant check about non-existent slice.
Change warning about interrupts of unknown slices to WARN_ON_ONCE
Handle the case where we get 2 slice interrupts concurrently, and switch
the tracking of interrupts to be non-destructive (all Ville)
Don't enable/mask the second slice parity interrupt for ivb/vlv (even
though all docs I can find claim it's rsvd) (Ville + Bryan)
Keep BYT excluded from L3 parity

v3: Fix the slice = ffs to be decremented by one (found by Ville). When
I initially did my testing on the series, I was using 1-based slice
counting, so this code was correct. Not sure why my simpler tests that
I've been running since then didn't pick it up sooner.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      35a85ac6
    • B
      drm/i915: Fix HSW parity test · 1c966dd2
      由 Ben Widawsky 提交于 
      Haswell changed the log registers to be WO, so we can no longer read
them to determine the programming (which sucks, see later note). For
now, simply use the cached value, and hope HW doesn't screw us over.

v2: Simplify the logic to avoid an extra !, remove last, and fix the
buffer offset which broke along the rebase (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1c966dd2
  45. 13 9月, 2013 2 次提交
  47. 03 9月, 2013 1 次提交
  49. 02 7月, 2013 1 次提交