On Thu, Sep 4, 2014 at 2:22 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
Agree. leaving idle_frame = 1 and increasing time to 600ms also works.
On Wed, Sep 03, 2014 at 10:49:56PM -0400, Rodrigo Vivi wrote:
> With Software tracking we are going to PSR sooner than we should and stayingHm, that sounds like we allow psr before it is really possible. And we
> with blank screens in many cases.
>
> Using 2 identical frames to detect idleness is safier.
>
> Discovered and validated with refactored igt/kms_sink_psr_crc.
>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f79473b..a796831 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1813,7 +1813,7 @@ static void intel_edp_psr_enable_source(struct intel_dp *intel_dp)
> struct drm_device *dev = dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> uint32_t max_sleep_time = 0x1f;
> - uint32_t idle_frames = 1;
> + uint32_t idle_frames = 2;
still delay the actual re-enable work by 100ms, so it very much looks like
something is broken here.
Agree. leaving idle_frame = 1 and increasing time to 600ms also works.
500ms fails.
So I thought we had an issue with frontbuffer tracking but couldn find any.
So I thought we had an issue with frontbuffer tracking but couldn find any.
So this idle_frame = 2 was the most clear way I could find for now.
Which exact subcases do fail?
Here are the results with idle_frame=1
IGT-Version: 1.7-gdee8754 (x86_64) (Linux: 3.17.0-rc2+ x86_64)
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest primary_page_flip: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest primary_mmap_gtt: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest primary_mmap_gtt_waiting: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest primary_mmap_cpu: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest primary_blt: FAIL
Subtest primary_render: SUCCESS
Subtest sprite_mmap_gtt: SUCCESS
Waiting 10s...
Subtest sprite_mmap_gtt_waiting: SUCCESS
Subtest sprite_mmap_cpu: SUCCESS
Subtest sprite_blt: SUCCESS
Subtest sprite_render: SUCCESS
Subtest sprite_plane_move: SUCCESS
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest sprite_plane_onoff: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_mmap_gtt: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_mmap_gtt_waiting: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_mmap_cpu: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_blt: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_render: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_plane_move: FAIL
Test assertion failure function get_sink_crc, file kms_psr_sink_crc.c:271:
Failed assertion: strcmp(crc, CRC_BLACK) != 0
Subtest cursor_plane_onoff: FAIL
-Daniel
--
> uint32_t val = 0x0;
> const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> bool _only_standby_ = false;
> --
> 1.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
