1. 05 10月, 2015 1 次提交
  2. 08 9月, 2015 1 次提交
  3. 02 7月, 2015 1 次提交
  4. 13 6月, 2015 15 次提交
  5. 24 3月, 2015 3 次提交
  6. 20 3月, 2015 10 次提交
  7. 20 11月, 2014 1 次提交
  8. 15 11月, 2014 1 次提交
  9. 22 7月, 2014 1 次提交
    • R
      drm: omapdrm: fix compiler errors · 2d31ca3a
      Russell King 提交于
      Regular randconfig nightly testing has detected problems with omapdrm.
      
      omapdrm fails to build when the kernel is built to support 64-bit DMA
      addresses and/or 64-bit physical addresses due to an assumption about
      the width of these types.
      
      Use %pad to print DMA addresses, rather than %x or %Zx (which is even
      more wrong than %x).  Avoid passing a uint32_t pointer into a function
      which expects dma_addr_t pointer.
      
      drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
      drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format]
      drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format]
      make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1
      drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr':
      drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format]
      drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe':
      drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format]
      drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init':
      drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format]
      make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1
      drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
      drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror]
      make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1
      make[5]: Target `__build' not remade because of errors.
      make[4]: *** [drivers/gpu/drm/omapdrm] Error 2
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      2d31ca3a
  10. 12 7月, 2014 2 次提交
  11. 15 4月, 2014 1 次提交
    • T
      drm/omap: fix the handling of fb ref counts · f2d022aa
      Tomi Valkeinen 提交于
      With the recent primary-plane changes for drm, the primary plane's
      framebuffer needs to be ref counted the same way as for
      non-primary-planes. This was not done by the omapdrm driver, which
      caused the ref count to drop to 0 too early, causing problems.
      
      This patch moves the fb unref and ref from omap_plane_update to
      omap_plane_mode_set. This way the fb refs are updated for both primary
      and non-primary cases, as omap_plane_update calls omap_plane_mode_set.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f2d022aa
  12. 14 4月, 2014 1 次提交
  13. 19 8月, 2013 1 次提交
    • R
      drm/omap: use flip-work helper · 5833bd2f
      Rob Clark 提交于
      And simplify how we hold a ref+pin to what is being scanned out by using
      fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
      was less straightforward than it could have been.  By holding a ref to
      the fb, we don't have to care about how many plane's there are and
      holding a ref to each color plane's bo.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5833bd2f
  14. 11 4月, 2013 1 次提交
    • A
      drm/omap: Take a fb reference in omap_plane_update() · b03e14fd
      Archit Taneja 提交于
      When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
      passes control to the update_plane op defined by the drm driver.
      
      In omapdrm, we have a worker thread which queues framebuffers objects received
      from update_plane and displays them at the appropriate time.
      
      It is possible that the framebuffer is destoryed by userspace between the time
      of calling the ioctl and apply-worker being scheduled. If this happens, the
      apply-worker holds a pointer to a framebuffer which is already destroyed.
      
      Take an extra refernece/unreference of the fb in omap_plane_update() to prevent
      this from happening. A reference is taken of the fb passed to update_plane(),
      the previous framebuffer (held by plane->fb) is unreferenced. This will prevent
      drm from destroying the framebuffer till the time it's unreferenced by the
      apply-worker.
      
      This is in addition to the exisitng reference/unreference in update_pin(),
      which is taken for the scanout of the plane's current framebuffer, and an
      unreference the previous framebuffer.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b03e14fd