1. 21 Mar, 2019 2 commits
  2. 11 Mar, 2019 2 commits
  3. 16 Oct, 2018 1 commit
  4. 01 Oct, 2018 1 commit
  5. 27 Sep, 2018 1 commit
    • Ville Syrjälä's avatar
      lib/igt_fb: Pass around igt_fb internally · 2238361a
      Ville Syrjälä authored
      Instead of passing around a boatload of integers everywhere let's
      just pass around the igt_fb struct. That obviously means we have to
      populate it first sufficiently, to which end we'll add a small helper.
      Later on the stride/size calculations will consult the already
      pre-populated igt_fb and fill in the rest as needed.
      This makes the whole thing a lot less error prone as it's impossible
      to accidentally pass the arguments in the wrong order when there's
      just the one of them, and it's a pointer.
      v2: Rebase due to uint64_t size
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Paulo Zanoni's avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
  6. 23 May, 2018 1 commit
  7. 09 Feb, 2018 2 commits
  8. 25 Jan, 2018 1 commit
  9. 04 Dec, 2017 5 commits
  10. 14 Aug, 2017 1 commit
  11. 10 Aug, 2017 8 commits
  12. 04 Aug, 2017 2 commits
    • Daniel Stone's avatar
      tests/kms_ccs: Don't overallocate CCS surface · d2415478
      Daniel Stone authored
      Due to a mix-up in kernel branches being used, I'd mangled Jason's
      original CCS test to hopelessly overallocate the CCS surface size.
      Restore it back to its original.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Cc: Jason Ekstrand <jason@jlekstrand.net>
    • Jason Ekstrand's avatar
      tests/kms_ccs: Fix the color/ccs surface generation · d75bbbff
      Jason Ekstrand authored
      Previously, the test used the old 64x64 convention that Ville introduced
      for CCS tiles and not the current 128x32 Y-tile convention.  Also, the
      original scheme for generating the CCS data was over-complicated and
      didn't work correctly because it assumed you could cut the main surface
      at an arbitrary Y coordinate.  While you clearly *can* do this (the
      hardware does), it's not a good idea for a generator in a test.  The new
      scheme, introduced here, is entirely based on the relationship between
      cache-lines in the main surface and the CCS that's documented in the
      PRM.  By keeping everything CCS cache-line aligned, our chances of
      generating correct data for an arbitrary-size surface are much higher.
      [daniels: Align CCS surface size to full height, per kernel
                requirements. Invert compressed/uncompressed red back so the
      	  top half of the display is compressed.]
      Fixes: d900dd85 ("tests/kms_ccs: Add test for render compression")
      Signed-off-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: 's avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
  13. 16 Jun, 2017 2 commits
  14. 21 Mar, 2017 3 commits
  15. 31 Jan, 2017 1 commit
  16. 05 Jan, 2017 1 commit
  17. 04 Jan, 2017 1 commit