Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 10月, 2019 7 次提交
  3. 24 10月, 2019 1 次提交
  5. 22 10月, 2019 1 次提交
  7. 19 10月, 2019 8 次提交
  9. 18 10月, 2019 3 次提交
  11. 17 10月, 2019 1 次提交
  13. 16 10月, 2019 4 次提交
  15. 15 10月, 2019 5 次提交
  17. 14 10月, 2019 1 次提交
  19. 10 10月, 2019 3 次提交
  21. 08 10月, 2019 1 次提交
    • A
      drm/i915/tgl: Do modeset to enable and configure DC3CO exitline · bdacf087
      由 Anshuman Gupta 提交于 
      DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset to enable and configure
DC3CO exitline.

v1: Computing dc3co_exitline crtc state from a DP encoder
    compute config. [Imre]
    Enabling and disabling DC3CO PSR2 transcoder exitline from
    encoder pre_enable and post_disable hooks. [Imre]
    Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
v2: Code refactoring for symmetry and to avoid exported function. [Imre]
    Removing IS_TIGERLAKE check from compute_config, adding PIPE_A
    restriction and clearing dc3co_exitline state if crtc is not active
    or it is not PSR2 capable in dc3co exitline compute_config. [Imre]
    Using GEN >= 12 check in dc3co exitline get_config. [Imre]

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003081738.22101-5-anshuman.gupta@intel.com
      bdacf087
  23. 06 10月, 2019 1 次提交
  25. 05 10月, 2019 1 次提交
  27. 04 10月, 2019 3 次提交
    • V
      drm/i915: Implement a better i945gm vblank irq vs. C-states workaround · 7d423af9
      由 Ville Syrjälä 提交于 
      The current "disable C3+" workaround for the delayed vblank
irqs on i945gm no longer works. I'm not sure what changed, but
now I need to also disable C2. I also got my hands on a i915gm
machine that suffers from the same issue.

After some furious poking of registers I managed to find a
better workaround: The "Do not Turn off Core Render Clock in C
states" bit. With that I no longer have to disable any C-states,
and as a nice bonus the power cost is only ~1/4 of the
"disable C3+" method (which mind you doesn't even work anymore,
and so would have an even higher power cost if we made it work
by also disabling C2).

So let's throw out all the cpuidle/qos crap and just toggle
the magic bit as needed. And we extend the workaround to cover
i915gm as well.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191003140231.24408-1-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
      7d423af9
    • C
      drm/i915/overlay: Drop struct_mutex guard · cb5eb072
      由 Chris Wilson 提交于 
      The overlay uses the modeset mutex to control itself and only required
the struct_mutex for requests, which is now obsolete.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-16-chris@chris-wilson.co.uk
      cb5eb072
    • C
      drm/i915: Pull i915_vma_pin under the vm->mutex · 2850748e
      由 Chris Wilson 提交于 
      Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).

In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.

Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!

v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
      2850748e