1. 16 9月, 2020 1 次提交
  2. 03 9月, 2020 1 次提交
  3. 27 8月, 2020 1 次提交
  4. 01 7月, 2020 1 次提交
  5. 20 5月, 2020 1 次提交
  6. 13 2月, 2020 2 次提交
  7. 31 1月, 2020 2 次提交
  8. 08 1月, 2020 1 次提交
  9. 05 12月, 2019 1 次提交
  10. 19 11月, 2019 1 次提交
  11. 13 8月, 2019 1 次提交
  12. 06 8月, 2019 2 次提交
  13. 11 6月, 2019 1 次提交
  14. 10 5月, 2019 1 次提交
  15. 24 1月, 2019 1 次提交
  16. 12 1月, 2019 1 次提交
  17. 12 4月, 2018 2 次提交
  18. 16 2月, 2018 1 次提交
  19. 07 12月, 2017 1 次提交
  20. 16 8月, 2017 1 次提交
  21. 04 8月, 2017 1 次提交
  22. 14 7月, 2017 1 次提交
  23. 08 4月, 2017 1 次提交
  24. 06 4月, 2017 1 次提交
  25. 29 3月, 2017 2 次提交
  26. 15 12月, 2016 2 次提交
    • V
      drm: Nuke fb->bits_per_pixel · 272725c7
      Ville Syrjälä 提交于
      Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
      Less duplicated information is a good thing.
      
      Note that I didn't put parens around the cpp*8 in the below cocci script,
      on account of not wanting spurious parens all over the place. Instead I
      did the unsafe way, and tried to look over the entire diff to spot if
      any dangerous expressions were produced. I didn't see any.
      
      There are some cases where previously the code did X*bpp/8, so the
      division happened after the multiplication. Those are now just X*cpp
      so the division effectively happens before the multiplication,
      but that is perfectly fine since bpp is always a multiple of 8.
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       drm_helper_mode_fill_fb_struct(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       i9xx_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       ironlake_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
       skylake_get_initial_plane_config(...) {
      	...
      -	FB->bits_per_pixel = E;
      	...
       }
      
      @@
      struct drm_framebuffer FB;
      expression E;
      @@
      (
      - E * FB.bits_per_pixel / 8
      + E * FB.format->cpp[0]
      |
      - FB.bits_per_pixel / 8
      + FB.format->cpp[0]
      |
      - E * FB.bits_per_pixel >> 3
      + E * FB.format->cpp[0]
      |
      - FB.bits_per_pixel >> 3
      + FB.format->cpp[0]
      |
      - (FB.bits_per_pixel + 7) / 8
      + FB.format->cpp[0]
      |
      - FB.bits_per_pixel
      + FB.format->cpp[0] * 8
      |
      - FB.format->cpp[0] * 8 != 8
      + FB.format->cpp[0] != 1
      )
      
      @@
      struct drm_framebuffer *FB;
      expression E;
      @@
      (
      - E * FB->bits_per_pixel / 8
      + E * FB->format->cpp[0]
      |
      - FB->bits_per_pixel / 8
      + FB->format->cpp[0]
      |
      - E * FB->bits_per_pixel >> 3
      + E * FB->format->cpp[0]
      |
      - FB->bits_per_pixel >> 3
      + FB->format->cpp[0]
      |
      - (FB->bits_per_pixel + 7) / 8
      + FB->format->cpp[0]
      |
      - FB->bits_per_pixel
      + FB->format->cpp[0] * 8
      |
      - FB->format->cpp[0] * 8 != 8
      + FB->format->cpp[0] != 1
      )
      
      @@
      struct drm_plane_state *state;
      expression E;
      @@
      (
      - E * state->fb->bits_per_pixel / 8
      + E * state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel / 8
      + state->fb->format->cpp[0]
      |
      - E * state->fb->bits_per_pixel >> 3
      + E * state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel >> 3
      + state->fb->format->cpp[0]
      |
      - (state->fb->bits_per_pixel + 7) / 8
      + state->fb->format->cpp[0]
      |
      - state->fb->bits_per_pixel
      + state->fb->format->cpp[0] * 8
      |
      - state->fb->format->cpp[0] * 8 != 8
      + state->fb->format->cpp[0] != 1
      )
      
      @@
      @@
      - (8 * 8)
      + 8 * 8
      
      @@
      struct drm_framebuffer FB;
      @@
      - (FB.format->cpp[0])
      + FB.format->cpp[0]
      
      @@
      struct drm_framebuffer *FB;
      @@
      - (FB->format->cpp[0])
      + FB->format->cpp[0]
      
      @@
      @@
       struct drm_framebuffer {
      	 ...
      -	 int bits_per_pixel;
      	 ...
       };
      
      v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
      v3: Adjusted the semantic patch a bit and regenerated due to code
          changes
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com
      272725c7
    • V
      drm: Pass 'dev' to drm_helper_mode_fill_fb_struct() · a3f913ca
      Ville Syrjälä 提交于
      Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
      populate fb->dev early. Will make it easier to use the fb before we
      register it.
      
      @@
      identifier fb, mode_cmd;
      @@
       void drm_helper_mode_fill_fb_struct(
      +				     struct drm_device *dev,
      				     struct drm_framebuffer *fb,
      				     const struct drm_mode_fb_cmd2 *mode_cmd
      				     );
      
      @@
      identifier fb, mode_cmd;
      @@
       void drm_helper_mode_fill_fb_struct(
      +				     struct drm_device *dev,
      				     struct drm_framebuffer *fb,
      				     const struct drm_mode_fb_cmd2 *mode_cmd
      				     )
      { ... }
      
      @@
      function func;
      identifier dev;
      expression E1, E2;
      @@
      func(struct drm_device *dev, ...)
      {
       ...
       drm_helper_mode_fill_fb_struct(
      +				dev,
      				E1, E2);
       ...
      }
      
      @@
      expression E1, E2;
      @@
       drm_helper_mode_fill_fb_struct(
      +				dev,
      				E1, E2);
      
      v2: Rerun spatch due to code changes
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1481748539-18283-1-git-send-email-ville.syrjala@linux.intel.com
      a3f913ca
  27. 25 10月, 2016 1 次提交
    • C
      dma-buf: Rename struct fence to dma_fence · f54d1867
      Chris Wilson 提交于
      I plan to usurp the short name of struct fence for a core kernel struct,
      and so I need to rename the specialised fence/timeline for DMA
      operations to make room.
      
      A consensus was reached in
      https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
      that making clear this fence applies to DMA operations was a good thing.
      Since then the patch has grown a bit as usage increases, so hopefully it
      remains a good thing!
      
      (v2...: rebase, rerun spatch)
      v3: Compile on msm, spotted a manual fixup that I broke.
      v4: Try again for msm, sorry Daniel
      
      coccinelle script:
      @@
      
      @@
      - struct fence
      + struct dma_fence
      @@
      
      @@
      - struct fence_ops
      + struct dma_fence_ops
      @@
      
      @@
      - struct fence_cb
      + struct dma_fence_cb
      @@
      
      @@
      - struct fence_array
      + struct dma_fence_array
      @@
      
      @@
      - enum fence_flag_bits
      + enum dma_fence_flag_bits
      @@
      
      @@
      (
      - fence_init
      + dma_fence_init
      |
      - fence_release
      + dma_fence_release
      |
      - fence_free
      + dma_fence_free
      |
      - fence_get
      + dma_fence_get
      |
      - fence_get_rcu
      + dma_fence_get_rcu
      |
      - fence_put
      + dma_fence_put
      |
      - fence_signal
      + dma_fence_signal
      |
      - fence_signal_locked
      + dma_fence_signal_locked
      |
      - fence_default_wait
      + dma_fence_default_wait
      |
      - fence_add_callback
      + dma_fence_add_callback
      |
      - fence_remove_callback
      + dma_fence_remove_callback
      |
      - fence_enable_sw_signaling
      + dma_fence_enable_sw_signaling
      |
      - fence_is_signaled_locked
      + dma_fence_is_signaled_locked
      |
      - fence_is_signaled
      + dma_fence_is_signaled
      |
      - fence_is_later
      + dma_fence_is_later
      |
      - fence_later
      + dma_fence_later
      |
      - fence_wait_timeout
      + dma_fence_wait_timeout
      |
      - fence_wait_any_timeout
      + dma_fence_wait_any_timeout
      |
      - fence_wait
      + dma_fence_wait
      |
      - fence_context_alloc
      + dma_fence_context_alloc
      |
      - fence_array_create
      + dma_fence_array_create
      |
      - to_fence_array
      + to_dma_fence_array
      |
      - fence_is_array
      + dma_fence_is_array
      |
      - trace_fence_emit
      + trace_dma_fence_emit
      |
      - FENCE_TRACE
      + DMA_FENCE_TRACE
      |
      - FENCE_WARN
      + DMA_FENCE_WARN
      |
      - FENCE_ERR
      + DMA_FENCE_ERR
      )
       (
       ...
       )
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
      f54d1867
  28. 13 10月, 2016 1 次提交
  29. 04 10月, 2016 2 次提交
    • M
      drm/radeon: Prevent races on pre DCE4 between flip submission and completion. · 363926dc
      Mario Kleiner 提交于
      Pre DCE4 hw doesn't have reliable pageflip completion
      interrupts, so instead polling for flip completion is
      used from within the vblank irq handler to complete
      page flips.
      
      This causes a race if pageflip ioctl is called close to
      vblank:
      
      1. pageflip ioctl queues execution of radeon_flip_work_func.
      
      2. vblank irq fires, radeon_crtc_handle_vblank checks for
         flip_status == FLIP_SUBMITTED finds none, no-ops.
      
      3. radeon_flip_work_func runs inside vblank, decides to
         set flip_status == FLIP_SUBMITTED and programs the
         flip into hw.
      
      4. hw executes flip immediately (because in vblank), but
         as 2 already happened, the flip completion routine only
         emits the flip completion event one refresh later ->
         wrong vblank count/timestamp for completion and no
         performance gain, as instead of delaying the flip until
         next vblank, we now delay the next flip by 1 refresh
         while waiting for the delayed flip completion event.
      
      Given we often don't gain anything due to this race, but
      lose precision, prevent the programmed flip from executing
      in vblank on pre DCE4 asics to avoid this race.
      
      On pre-AVIVO hw we can't program the hw for edge-triggered
      flips, they always execute anywhere in vblank. Therefore delay
      the actual flip programming until after vblank on pre-AVIVO.
      Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      363926dc
    • M
      drm/radeon: Slightly more robust flip completion handling for < DCE-4 · 73d4c23f
      Mario Kleiner 提交于
      Pre DCE4 hardware doesn't have (reliable) pageflip completion
      irqs, therefore we have to use the old polling method for flip
      completion handling in vblank irq.
      
      As vblank irqs fire a bit before start of vblank (when the
      linebuffer fifo read position reaches end of scanout), we
      have some fudge for flip completion handling in the last
      lines of active scanout. Old code assumed the threshold to
      be 99% of active scanout height, a ballpark estimate which
      worked ok. Since we know since a while how to calculate the
      actual threshold from linebuffer size, lets make use of it
      to get a more accurate threshold.
      
      This completion path is still prone to some races in corner
      cases, especially on pre-AVIVO hardware, so document them
      a bit better in the code comments.
      Acked-by: NMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      73d4c23f
  30. 11 8月, 2016 1 次提交
  31. 30 7月, 2016 2 次提交
  32. 24 6月, 2016 1 次提交