1. 21 Feb, 2019 2 commits
  2. 20 Feb, 2019 6 commits
  3. 19 Feb, 2019 1 commit
  4. 15 Feb, 2019 8 commits
  5. 14 Feb, 2019 1 commit
    • José Roberto de Souza's avatar
      test: Add PSR2 selective update tests · eea5cf40
      José Roberto de Souza authored
      This tests checks if hardware is able to do selective update when
      screen changes.
      PSR2 don't trigger interruptions and the 'PSR2 SU status' register
      is not kept loaded all the times, so it is necessary keep polling
      PSR status debugfs until those values are loaded.
      
      Also from DEEP_SLEEP state HW will not do a seletive update, as
      most of the memory/context is lost in deep sleep state hardware will
      need to exit PSR mode then wait a configured number of frames to
      activate PSR again to then start doing seletive updates, that is why
      just one screen change is not enough to pass this tests.
      
      When a selective update happens and the values are loaded and read
      from debugfs it is compared with the expected value of seletive
      update blocks, if matches the polling is stopped and the test passed
      otherwise it will wait until it reachs a maximum number o screen
      changes to fail the test.
      
      v2: Using new SU blocks debugfs output
      
      v3:
      - removed the timerfd to fail the test, now failing based in a
      maximum number of screen changes
      - removing thread to read debugfs, read from main thread is enough
      - improved commit message
      
      v4:
      - getting cairo context for frontbuffer test in prepare()
      - droppoing poll(), using blocking timerfd instead
      
      v5:
      - Doing a modeset before trying to enable PSR2
      
      v6:
      - doing atomic commits to fix(legacy commit is taking more time in
      recent kernels causing us to miss the SU when reading debugfs) and
      speedup test
      - fixed code to skip test when PSR2 is not possile
      Reviewed-by: Dhinakaran Pandiyan's avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Tested-by: Dhinakaran Pandiyan's avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: José Roberto de Souza's avatarJosé Roberto de Souza <jose.souza@intel.com>
      eea5cf40
  6. 13 Feb, 2019 2 commits
    • Maarten Lankhorst's avatar
      lib/igt_fb: Add support for P01x formats, v5. · cb8e45a6
      Maarten Lankhorst authored
      The P01x formats are planar 16 bits per component, with the unused lower bits set to 0.
      This means they can all be converted the same way. Only the range is slightly different,
      and this is handled in the color_encoding implementation.
      
      This requires cairo 1.17.2 and pixman 0.36. This works but doesn't give extra precision.
      For more than 8 bits precision a few more patches are required to pixman, pending review:
      https://lists.freedesktop.org/archives/pixman/2019-January/004815.html
      https://lists.freedesktop.org/archives/pixman/2019-January/004809.html
      
      Once those are merged, we will require the next pixman release for better precision.
      
      Changes since v1:
      - Add fallback color definitions when compiling on cairo version < 1.17.2.
      - Skip when FB creation fails on HDR formats, instead of failing.
      Changes since v2:
      - Complain slightly harder when pixman/cairo are out of date.
      - Create a fb with alpha when converting to pixman formats with alpha.
      - Oops, s/pixman_format_code_t/cairo_format_t/
      Changes since v3:
      - Rebase on top of upstream YUV changes.
      Changes since v4:
      - Rebase again.
      - Use drm_fourcc.h from drm-misc-next.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>  #v4
      cb8e45a6
    • Maarten Lankhorst's avatar
      lib/color_encoding: Prepare support for HDR modes, v2. · b0033d93
      Maarten Lankhorst authored
      We're starting to add support for 10, 12 and 16-bits formats that all have
      different values for the Y offset and range. Some 10 bits formats
      go from [0...1023], others go to [0...1023] shifted left by 6. To
      accomodate all formats add a struct definition for all various formats,
      this can be extended further when we add new formats.
      
      Changes since v1:
      - Rebase on top of added yuv changes.
      - Add commit description (swatish)
      - Add missing newline. (swatish)
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1
      b0033d93
  7. 11 Feb, 2019 8 commits
  8. 05 Feb, 2019 8 commits
  9. 04 Feb, 2019 1 commit
  10. 01 Feb, 2019 3 commits