Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 8月, 2016 1 次提交
  3. 19 7月, 2016 1 次提交
  5. 05 7月, 2016 1 次提交
  7. 28 6月, 2016 1 次提交
  9. 06 5月, 2016 1 次提交
  11. 19 4月, 2016 1 次提交
  13. 15 4月, 2016 1 次提交
  15. 16 3月, 2016 1 次提交
  17. 07 3月, 2016 1 次提交
  19. 23 2月, 2016 1 次提交
  21. 22 2月, 2016 2 次提交
  23. 02 2月, 2016 1 次提交
  25. 19 1月, 2016 1 次提交
  27. 09 1月, 2016 1 次提交
  29. 09 12月, 2015 1 次提交
  31. 18 11月, 2015 2 次提交
    • 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
    • P
      drm/i915: Don't trust CSR program memory contents · fc131bf2
      由 Patrik Jakobsson 提交于 
      Replaces "drm/i915: Force loading of csr program at boot" in the old
series.

Previously we called blindly into intel_csr_load_program() and depended
on a check of whether the CSR program memory was cleared or not.
This check is not reliable and no longer needed since we fixed the
call-sites of intel_csr_load_program().
Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-2-git-send-email-patrik.jakobsson@linux.intel.com
      fc131bf2
  33. 12 11月, 2015 13 次提交
  35. 10 11月, 2015 3 次提交
  37. 30 9月, 2015 1 次提交
    • A
      drm/i915/skl: Added a check for the hardware status of csr fw before loading. · 4b7ab5fc
      由 Animesh Manna 提交于 
      Dmc will restore the csr program except DC9, cold boot,
warm reset, PCI function level reset, and hibernate/suspend.

intel_csr_load_program() function is used to load the firmware
data from kernel memory to csr address space.

All values of csr address space will be zero if it got reset and
the first byte of csr program is always a non-zero if firmware
is loaded successfuly. Based on hardware status will load the
firmware.

Without this condition check if we overwrite the firmware data the
counters exposed for dc5/dc6 (help for debugging) will be nullified.

Note: Above commit message seems to be confused and the real problem
apparently going on is that for suspend-to-idle and system standby the
firmware survives (it's like runtime pm), but it doesn't for
suspend-to-mem and hibernate-to-disk. All the other talking about DC9
and pci reset are irrelevant for the path touched here (only driver
load and system resume functions) and might not be true statements.

v1: Initial version.

v2: Based on review comments from Daniel,
- Added a check to know hardware status and load the firmware if not loaded.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
[danvet: Explain clearly in the code comment when we need to reload
and when not and make it a FIXME. Also deconfuse the commit message
with a note. Also: Make. it. compile.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4b7ab5fc
  39. 23 9月, 2015 3 次提交
  41. 14 9月, 2015 1 次提交
  43. 10 9月, 2015 1 次提交