1. 13 6月, 2015 15 次提交
  2. 24 3月, 2015 3 次提交
  3. 20 3月, 2015 10 次提交
  4. 20 11月, 2014 1 次提交
  5. 15 11月, 2014 1 次提交
  6. 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
  7. 12 7月, 2014 2 次提交
  8. 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
  9. 14 4月, 2014 1 次提交
  10. 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
  11. 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
  12. 17 2月, 2013 1 次提交
    • R
      drm/omap: move out of staging · 8bb0daff
      Rob Clark 提交于
      Now that the omapdss interface has been reworked so that omapdrm can use
      dispc directly, we have been able to fix the remaining functional kms
      issues with omapdrm.  And in the mean time the PM sequencing and many
      other of that open issues have been solved.  So I think it makes sense
      to finally move omapdrm out of staging.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      8bb0daff
  13. 12 2月, 2013 1 次提交
  14. 08 1月, 2013 1 次提交
    • R
      staging: drm/omap: use omapdss low level API · f5f9454c
      Rob Clark 提交于
      This patch changes the omapdrm KMS to bypass the omapdss "compat"
      layer and use the core omapdss API directly.  This solves some layering
      issues that would cause unpin confusion vs GO bit status, because we
      would not know whether a particular pageflip or overlay update has hit
      the screen or not.  Now instead we explicitly manage the GO bits in
      dispc and handle the vblank/framedone interrupts ourself so that we
      always know which buffers are being scanned out at any given time, and
      so on.
      
      As an added bonus, we no longer leave the last overlay buffer pinned
      when the display is disabled, and have been able to add the previously
      missing vblank event handling.
      
      v1: original
      v2: rebased on latest staging-next and omapdss patches from Tomi and
          review comments from Archit Taneja
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NArchit Taneja <archit@ti.com>
      Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5f9454c