1. 05 11月, 2018 1 次提交
  2. 20 9月, 2018 1 次提交
  3. 08 12月, 2017 1 次提交
  4. 19 9月, 2017 1 次提交
  5. 26 7月, 2017 1 次提交
  6. 17 2月, 2017 1 次提交
  7. 08 2月, 2017 1 次提交
  8. 03 2月, 2017 1 次提交
    • G
      drm: Rely on mode_config data for fb_helper initialization · e4563f6b
      Gabriel Krisman Bertazi 提交于
      Instead of receiving the num_crts as a parameter, we can read it
      directly from the mode_config structure.  I audited the drivers that
      invoke this helper and I believe all of them initialize the mode_config
      struct accordingly, prior to calling the fb_helper.
      
      I used the following coccinelle hack to make this transformation, except
      for the function headers and comment updates.  The first and second
      rules are split because I couldn't find a way to remove the unused
      temporary variables at the same time I removed the parameter.
      
      // <smpl>
      @r@
      expression A,B,D,E;
      identifier C;
      @@
      (
      - drm_fb_helper_init(A,B,C,D)
      + drm_fb_helper_init(A,B,D)
      |
      - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
      + drm_fbdev_cma_init_with_funcs(A,B,D,E)
      |
      - drm_fbdev_cma_init(A,B,C,D)
      + drm_fbdev_cma_init(A,B,D)
      )
      
      @@
      expression A,B,C,D,E;
      @@
      (
      - drm_fb_helper_init(A,B,C,D)
      + drm_fb_helper_init(A,B,D)
      |
      - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
      + drm_fbdev_cma_init_with_funcs(A,B,D,E)
      |
      - drm_fbdev_cma_init(A,B,C,D)
      + drm_fbdev_cma_init(A,B,D)
      )
      
      @@
      identifier r.C;
      type T;
      expression V;
      @@
      - T C;
      <...
      when != C
      - C = V;
      ...>
      // </smpl>
      
      Changes since v1:
       - Rebased on top of the tip of drm-misc-next.
       - Remove mention to sti since a proper fix got merged.
      Suggested-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
      e4563f6b
  9. 31 1月, 2017 1 次提交
  10. 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: Nuke fb->depth · b00c600e
      Ville Syrjälä 提交于
      Replace uses of fb->depth with fb->format->depth. Less duplicate
      information is a good thing.
      
      @@
      struct drm_framebuffer *fb;
      expression E;
      @@
       drm_helper_mode_fill_fb_struct(...) {
      	...
      -	fb->depth = E;
      	...
       }
      
      @@
      struct nouveau_framebuffer *fb;
      @@
      - fb->base.depth
      + fb->base.format->depth
      
      @@
      struct drm_framebuffer fb;
      @@
      - fb.depth
      + fb.format->depth
      
      @@
      struct drm_framebuffer *fb;
      @@
      - fb->depth
      + fb->format->depth
      
      @@
      struct drm_framebuffer fb;
      @@
      - (fb.format->depth)
      + fb.format->depth
      
      @@
      struct drm_framebuffer *fb;
      @@
      - (fb->format->depth)
      + fb->format->depth
      
      @@
      @@
       struct drm_framebuffer {
      	 ...
      -	 unsigned int depth;
      	 ...
       };
      
      v2: Drop the vmw stuff (Daniel)
          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>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1481751095-18249-1-git-send-email-ville.syrjala@linux.intel.com
      b00c600e
  11. 14 11月, 2016 1 次提交
  12. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  13. 22 7月, 2016 1 次提交
  14. 30 4月, 2016 1 次提交
  15. 20 4月, 2016 1 次提交
  16. 12 4月, 2016 1 次提交
  17. 01 3月, 2016 2 次提交
  18. 15 2月, 2016 1 次提交
  19. 26 10月, 2015 1 次提交
    • J
      drm/exynos: cleanup name of gem object for exynos_drm · 813fd67b
      Joonyoung Shim 提交于
      Struct of gem object in exynos_drm driver is struct exynos_drm_gem_obj.
      It's too long and we can know its meaning of name without _obj postfix.
      
      We use several names to variable name of gem object for exynos_drm -
      exynos_gem_obj, gem_obj and obj. Especially "obj" name can cause
      misunderstanding with variable name "obj" of struct drm_gem_object.
      
      This will clean about name of gem object for exynos_drm as follows.
      s/struct exynos_drm_gem_obj/struct exynos_drm_gem
      s/exynos_gem_obj or gem_obj or obj/exynos_gem
      Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      813fd67b
  20. 02 9月, 2015 5 次提交
  21. 16 8月, 2015 1 次提交
  22. 06 8月, 2015 1 次提交
  23. 19 6月, 2015 1 次提交
  24. 12 3月, 2015 1 次提交
  25. 07 2月, 2015 1 次提交
  26. 19 9月, 2014 2 次提交
  27. 08 7月, 2014 2 次提交
  28. 05 6月, 2014 1 次提交
  29. 02 6月, 2014 3 次提交
  30. 04 4月, 2014 1 次提交