1. 14 11月, 2017 1 次提交
  2. 18 10月, 2017 2 次提交
  3. 12 10月, 2017 1 次提交
  4. 10 10月, 2017 1 次提交
  5. 01 9月, 2017 1 次提交
  6. 12 8月, 2017 1 次提交
  7. 11 8月, 2017 2 次提交
    • B
      drm/i915: Add format modifiers for Intel · 714244e2
      Ben Widawsky 提交于
      This was based on a patch originally by Kristian. It has been modified
      pretty heavily to use the new callbacks from the previous patch.
      
      v2:
        - Add LINEAR and Yf modifiers to list (Ville)
        - Combine i8xx and i965 into one list of formats (Ville)
        - Allow 1010102 formats for Y/Yf tiled (Ville)
      
      v3:
        - Handle cursor formats (Ville)
        - Put handling for LINEAR in the mod_support functions (Ville)
      
      v4:
        - List each modifier explicitly in supported modifiers (Ville)
        - Handle the CURSOR plane (Ville)
      
      v5:
        - Split out cursor and sprite handling (Ville)
      
      v6:
        - Actually use the sprite funcs (Emil)
        - Use unreachable (Emil)
      
      v7:
        - Only allow Intel modifiers and LINEAR (Ben)
      
      v8
        - Fix spite assert introduced in v6 (Daniel)
      
      v9
        - Change vendor check logic to avoid magic 56 (Emil)
        - Reorder skl_mod_support (Ville)
        - make intel_plane_funcs static, could be done as of v5 (Ville)
        - rename local variable intel_format_modifiers to modifiers (Ville)
          - actually use sprite modifiers
        - split out modifier/formats by platform (Ville)
      
      v10:
        - Undo vendor check from v9
      
      v11:
        - Squash CCS advertisement into this patch (daniels)
        - Don't advertise CCS on higher sprite planes (daniels)
      
      v12:
        - Don't advertise Y-tiled or CCS on any sprite planes, since we don't
          allocate enough DDB space for it to work. (daniels)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v8)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      714244e2
    • V
      drm/i915: Add render decompression support · 2e2adb05
      Ville Syrjälä 提交于
      SKL+ display engine can scan out certain kinds of compressed surfaces
      produced by the render engine. This involved telling the display engine
      the location of the color control surfae (CCS) which describes
      which parts of the main surface are compressed and which are not. The
      location of CCS is provided by userspace as just another plane with its
      own offset.
      
      Add the required stuff to validate the user provided AUX plane metadata
      and convert the user provided linear offset into something the hardware
      can consume.
      
      Due to hardware limitations we require that the main surface and
      the AUX surface (CCS) be part of the same bo. The hardware also
      makes life hard by not allowing you to provide separate x/y offsets
      for the main and AUX surfaces (excpet with NV12), so finding suitable
      offsets for both requires a bit of work. Assuming we still want keep
      playing tricks with the offsets. I've just gone with a dumb "search
      backward for suitable offsets" approach, which is far from optimal,
      but it works.
      
      Also not all planes will be capable of scanning out compressed surfaces,
      and eg. 90/270 degree rotation is not supported in combination with
      decompression either.
      
      This patch may contain work from at least the following people:
      * Vandana Kannan <vandana.kannan@intel.com>
      * Daniel Vetter <daniel@ffwll.ch>
      * Ben Widawsky <ben@bwidawsk.net>
      
      v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
      v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
          Put the AUX register defines to the correct place
          Fix up the slightly bogus rotation check
      v4: Use I915_WRITE_FW() due to plane update locking changes
          s/return -EINVAL/goto err/ in intel_framebuffer_init()
          Eliminate a bunch hardcoded numbers in CCS code
      
      v5: (By Ben)
      conflict resolution +
      -               res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum);
      +               res_blocks += fixed16_to_u32_round_up(y_tile_minimum);
      
      v6: (daniels) Fix botched commit message.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Jason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: NVille Syrjä <ville.syrjala@linux.intel.com>
      Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
      Reviewed-by: NDaniel Stone <daniels@collabora.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170801165817.7063-1-ben@bwidawsk.net
      2e2adb05
  8. 02 8月, 2017 1 次提交
    • B
      drm: Plumb modifiers through plane init · e6fc3b68
      Ben Widawsky 提交于
      This is the plumbing for supporting fb modifiers on planes. Modifiers
      have already been introduced to some extent, but this series will extend
      this to allow querying modifiers per plane. Based on this, the client to
      enable optimal modifications for framebuffers.
      
      This patch simply allows the DRM drivers to initialize their list of
      supported modifiers upon initializing the plane.
      
      v2: A minor addition from Daniel
      
      v3:
      * Updated commit message
      * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
      * Remove some excess newlines (Liviu)
      * Update comment for > 64 modifiers (Liviu)
      
      v4: Minor comment adjustments (Liviu)
      
      v5: Some new platforms added due to rebase
      
      v6: Add some missed plane inits (or maybe they're new - who knows at
      this point) (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)
      Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NDaniel Stone <daniels@collabora.com>
      e6fc3b68
  9. 21 7月, 2017 1 次提交
  10. 07 7月, 2017 1 次提交
  11. 07 6月, 2017 1 次提交
    • V
      drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail · 8f4d3809
      Ville Syrjälä 提交于
      The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
      increment is not lined up with the start of vblank like it is on
      every other platform and output type. This causes problems for
      both the vblank timestamping and atomic update vblank evasion.
      
      On my FFRD8 machine at least, the scanline counter increment
      happens about 1/3 of a scanline ahead of the start of vblank (which
      is where all register latching happens still). That means we can't
      trust the scanline counter to tell us whether we're in vblank or not
      while we're on that particular line. In order to keep vblank
      timestamping in working condition when called from the vblank irq,
      we'll leave scanline_offset at one, which means that the entire
      line containing the start of vblank is considered to be inside
      the vblank.
      
      For the vblank evasion we'll need to consider that entire line
      to be bad, since we can't tell whether the registers already
      got latched or not. And we can't actually use the start of vblank
      interrupt to get us past that line as the interrupt would fire
      too soon, and then we'd up waiting for the next start of vblank
      instead. One way around that would using the frame start
      interrupt instead since that wouldn't fire until the next
      scanline, but that would require some bigger changes in the
      interrupt code. So for simplicity we'll just poll until we get
      past the bad line.
      
      v2: Adjust the comments a bit
      
      Cc: stable@vger.kernel.org
      Cc: Jonas Aaberg <cja@gmx.net>
      Tested-by: NJonas Aaberg <cja@gmx.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.comTested-by: NMika Kahola <mika.kahola@intel.com>
      Reviewed-by: NMika Kahola <mika.kahola@intel.com>
      (cherry picked from commit ec1b4ee2)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      8f4d3809
  12. 06 6月, 2017 1 次提交
    • V
      drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail · ec1b4ee2
      Ville Syrjälä 提交于
      The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
      increment is not lined up with the start of vblank like it is on
      every other platform and output type. This causes problems for
      both the vblank timestamping and atomic update vblank evasion.
      
      On my FFRD8 machine at least, the scanline counter increment
      happens about 1/3 of a scanline ahead of the start of vblank (which
      is where all register latching happens still). That means we can't
      trust the scanline counter to tell us whether we're in vblank or not
      while we're on that particular line. In order to keep vblank
      timestamping in working condition when called from the vblank irq,
      we'll leave scanline_offset at one, which means that the entire
      line containing the start of vblank is considered to be inside
      the vblank.
      
      For the vblank evasion we'll need to consider that entire line
      to be bad, since we can't tell whether the registers already
      got latched or not. And we can't actually use the start of vblank
      interrupt to get us past that line as the interrupt would fire
      too soon, and then we'd up waiting for the next start of vblank
      instead. One way around that would using the frame start
      interrupt instead since that wouldn't fire until the next
      scanline, but that would require some bigger changes in the
      interrupt code. So for simplicity we'll just poll until we get
      past the bad line.
      
      v2: Adjust the comments a bit
      
      Cc: stable@vger.kernel.org
      Cc: Jonas Aaberg <cja@gmx.net>
      Tested-by: NJonas Aaberg <cja@gmx.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.comTested-by: NMika Kahola <mika.kahola@intel.com>
      Reviewed-by: NMika Kahola <mika.kahola@intel.com>
      ec1b4ee2
  13. 22 5月, 2017 1 次提交
  14. 12 5月, 2017 1 次提交
    • V
      drm/i915: Make vblank evade warnings optional · 7b8cd336
      Ville Syrjälä 提交于
      Add a new Kconfig option to enable/disable the extra warnings
      from the vblank evade code. For now we'll keep the warning
      about an actually missed vblank always enabled as that can have
      an actual user visible impact. But if we miss the deadline
      othrwise there's no real need to bother the user with that.
      We'll want these warnings enabled during development however
      so that we can catch regressions.
      
      Based on the reports it looks like this is still very easy
      to hit on SKL, so we have more work ahead of us to optimize
      the crtiical section further.
      
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: NJens Axboe <axboe@kernel.dk>
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Fixes: e1edbd44 ("drm/i915: Complain if we take too long under vblank evasion.")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7b8cd336
  15. 10 5月, 2017 2 次提交
  16. 27 3月, 2017 2 次提交
  17. 23 3月, 2017 4 次提交
  18. 14 3月, 2017 2 次提交
  19. 13 3月, 2017 1 次提交
  20. 09 3月, 2017 1 次提交
  21. 08 3月, 2017 1 次提交
  22. 06 3月, 2017 1 次提交
  23. 17 2月, 2017 1 次提交
  24. 01 2月, 2017 1 次提交
  25. 30 1月, 2017 2 次提交
  26. 19 1月, 2017 1 次提交
  27. 15 12月, 2016 2 次提交
    • V
      drm: Nuke fb->pixel_format · 438b74a5
      Ville Syrjälä 提交于
      Replace uses of fb->pixel_format with fb->format->format.
      Less duplicated information is a good thing.
      
      Note that coccinelle failed to eliminate the
      "/* fourcc format */" comment from drm_framebuffer.h, so I had
      to do that part manually.
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       drm_helper_mode_fill_fb_struct(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       i9xx_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       ironlake_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       skylake_get_initial_plane_config(...) {
      	...
      -	FB->pixel_format = E;
      	...
       }
      
      @@
      struct drm_framebuffer *a;
      struct drm_framebuffer b;
      @@
      (
      - a->pixel_format
      + a->format->format
      |
      - b.pixel_format
      + b.format->format
      )
      
      @@
      struct drm_plane_state *a;
      struct drm_plane_state b;
      @@
      (
      - a->fb->pixel_format
      + a->fb->format->format
      |
      - b.fb->pixel_format
      + b.fb->format->format
      )
      
      @@
      struct drm_crtc *CRTC;
      @@
      (
      - CRTC->primary->fb->pixel_format
      + CRTC->primary->fb->format->format
      |
      - CRTC->primary->state->fb->pixel_format
      + CRTC->primary->state->fb->format->format
      )
      
      @@
      struct drm_mode_set *set;
      @@
      (
      - set->fb->pixel_format
      + set->fb->format->format
      |
      - set->crtc->primary->fb->pixel_format
      + set->crtc->primary->fb->format->format
      )
      
      @@
      @@
       struct drm_framebuffer {
      	 ...
      -	 uint32_t pixel_format;
      	 ...
       };
      
      v2: Fix commit message (Laurent)
          Rebase due to earlier removal of many fb->pixel_format uses,
          including the 'fb->format = drm_format_info(fb->format->format);'
          snafu
      v3: Adjusted the semantic patch a bit and regenerated due to code
          changes
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751175-18463-1-git-send-email-ville.syrjala@linux.intel.com
      438b74a5
    • V
      drm: Replace drm_format_plane_cpp() with fb->format->cpp[] · 353c8598
      Ville Syrjälä 提交于
      Replace drm_format_plane_cpp(fb->pixel_format) with just
      fb->format->cpp[]. Avoids the expensive format info lookup.
      
      @@
      struct drm_framebuffer *a;
      struct drm_framebuffer b;
      expression E;
      @@
      (
      - drm_format_plane_cpp(a->pixel_format, E)
      + a->format->cpp[E]
      |
      - drm_format_plane_cpp(b.pixel_format, E)
      + b.format->cpp[E]
      )
      
      @@
      struct drm_plane_state *a;
      struct drm_plane_state b;
      expression E;
      @@
      (
      - drm_format_plane_cpp(a->fb->pixel_format, E)
      + a->fb->format->cpp[E]
      |
      - drm_format_plane_cpp(b.fb->pixel_format, E)
      + b.fb->format->cpp[E]
      )
      
      @@
      struct drm_framebuffer *a;
      identifier T;
      expression E;
      @@
        T = a->pixel_format
      <+...
      - drm_format_plane_cpp(T, E)
      + a->format->cpp[E]
      ...+>
      
      @@
      struct drm_framebuffer b;
      identifier T;
      expression E;
      @@
        T = b.pixel_format
      <+...
      - drm_format_plane_cpp(T, E)
      + b.format->cpp[E]
      ...+>
      
      v2: Rerun spatch due to code changes
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Suggested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751057-18123-1-git-send-email-ville.syrjala@linux.intel.com
      353c8598
  28. 24 11月, 2016 3 次提交