Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 16 3月, 2017 1 次提交
  3. 15 2月, 2017 1 次提交
  5. 27 1月, 2017 1 次提交
  7. 10 1月, 2017 1 次提交
  9. 20 12月, 2016 1 次提交
  11. 14 12月, 2016 1 次提交
  13. 02 12月, 2016 1 次提交
  15. 12 10月, 2016 1 次提交
  17. 02 9月, 2016 1 次提交
  19. 22 8月, 2016 2 次提交
  21. 28 7月, 2016 1 次提交
  23. 14 7月, 2016 2 次提交
  25. 04 7月, 2016 1 次提交
  27. 24 6月, 2016 1 次提交
  29. 24 5月, 2016 1 次提交
  31. 11 5月, 2016 1 次提交
  33. 03 3月, 2016 1 次提交
  35. 13 1月, 2016 1 次提交
  37. 10 12月, 2015 1 次提交
  39. 18 11月, 2015 1 次提交
    • V
      drm/i915: Type safe register read/write · f0f59a00
      由 Ville Syrjälä 提交于 
      Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.

This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.

The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.

As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
  lea    0x70024(%rdx,%rax,1),%r9d
  mov    $0x1,%edx
- movslq %r9d,%r9
- mov    %r9,%rsi
- mov    %r9,-0x58(%rbp)
- callq  *0xd8(%rbx)
+ mov    %r9d,%esi
+ mov    %r9d,-0x48(%rbp)
 callq  *0xd8(%rbx)

So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.

v2: i915_mmio_reg_{offset,equal,valid}() helpers added
    s/_REG/_MMIO/ in the register defines
    mo more switch statements left to worry about
    ring_emit stuff got sorted in a prep patch
    cmd parser, lrc context and w/a batch buildup also in prep patch
    vgpu stuff cleaned up and moved to a prep patch
    all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f0f59a00
  41. 30 9月, 2015 2 次提交
  43. 15 6月, 2015 1 次提交
  45. 18 3月, 2015 1 次提交
  47. 27 2月, 2015 1 次提交
  49. 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
  51. 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
  53. 27 1月, 2015 5 次提交
  55. 24 10月, 2014 1 次提交
  57. 03 9月, 2014 1 次提交
  59. 12 7月, 2014 2 次提交
  61. 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
  63. 05 5月, 2014 1 次提交