Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 6月, 2018 1 次提交
  3. 15 6月, 2018 1 次提交
    • R
      drm/i915/psr: Kill delays when activating psr back. · 5422b37c
      由 Rodrigo Vivi 提交于 
      The immediate enabling was actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.

Now that we removed VLV/CHV out of the picture completely
we can safely remove any delays.

Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.

v2:(DK): Remove unnecessary WARN_ONs and make some other
         VLV | CHV more readable.
v3: Do it regardless the timer rework.
v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable.
v5: Kill remaining items and fully rework activation functions.
v6: Rebase on top of VLV/CHV clean-up and keep the reactivation
    on a regular non-delayed work to avoid extra delays on exit
    calls and allow us to add few more safety checks before
    real activation.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613192600.3955-1-rodrigo.vivi@intel.com
      5422b37c
  5. 30 5月, 2018 1 次提交
    • D
      drm/i915/psr: Set idle frame count based on sink synchronization latency · a3db1428
      由 Dhinakaran Pandiyan 提交于 
      DPCD 2009h "Synchronization latency in sink" has bits that tell us the
maximum number of frames sink can take to resynchronize to source timing
when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
number of frames following PSR exit that the Source device needs to
wait for PSR entry."

We currently use this value only to setup the number frames to wait before
PSR2 selective update. But, based on the above description it makes more
sense to use this to configure idle frames for both PSR1 and and PSR2. This
will ensure we wait the required number of frames before
activation whether it is PSR1 or PSR2.

The minimum number of idle frames remains 6, while allowing sink
synchronization latency and VBT to increase this value.

This also solves the flip-flop between sink and source frames that I
noticed on my Thinkpad X260 during PSR exit. This specific panel has a
value of 8h, which according to the spec means the "Source device must
wait for more than eight active frames after PSR exit before initiating PSR
entry. (In this case, should be provided by the panel supplier.)" VBT
however has a value of 0.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525033047.7596-1-dhinakaran.pandiyan@intel.com
      a3db1428
  7. 24 5月, 2018 7 次提交
  9. 09 5月, 2018 1 次提交
  11. 27 4月, 2018 3 次提交
  13. 21 4月, 2018 2 次提交
  15. 10 4月, 2018 1 次提交
  17. 31 3月, 2018 7 次提交
  19. 22 3月, 2018 2 次提交
  21. 14 3月, 2018 2 次提交
  23. 13 3月, 2018 1 次提交
    • R
      drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. · caa1fd66
      由 Rodrigo Vivi 提交于 
      WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
the CPU host modify writes may not get updated on the Display
as expected.
WA: Write 0x00000000 to CUR_SURFLIVE_A with every CPU
host modify write to trigger PSR exit."

We can also find on spec other cases where they describe
bogus writes to cursor registers to force PSR exit with
HW tracking. And it was confirmed by HW engineers that
this Wa can be safely applied for any frontbuffer activity.

So let's use this more and more here instead of forcibly
disable and re-enable PSR everytime that we have a simple
reliable flush case.

Other commits improve the fbcon/fbdev use a lot, but this
approach is the only when where we can get a fully reliable
console with no slowness or missed frames and PSR still
enabled and active.

v2: - Rebase on drm-tip
    - (DK) Add a comment to explain that WA
    tells about writing 0 to CUR_SURFLIVE_A but we write to
    CUR_SURFLIVE(pipe).
v3: Wa doesn't work on PSR2.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180309005218.26772-1-rodrigo.vivi@intel.com
      caa1fd66
  25. 07 3月, 2018 1 次提交
  27. 28 2月, 2018 6 次提交
  29. 10 2月, 2018 1 次提交
  31. 20 1月, 2018 1 次提交
  33. 13 1月, 2018 2 次提交