01 May, 2013

3 commits

  • drm_gem_release should release all handles connected to the drm file and
    so should also release the prime lookup entries of these handles. So
    just WARN if this isn't the case.

    Signed-off-by: Imre Deak
    Reviewed-by: Daniel Vetter
    Signed-off-by: Dave Airlie

    Imre Deak
     
  • In commit be8a42ae60 we inroduced a refcount problem, where on the
    drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
    self imported dma buffers.

    Fix this by taking a reference on the dma buffer in the .gem_import
    hook instead of assuming the caller had taken one. Besides fixing the
    bug this is also more logical.

    Signed-off-by: Imre Deak
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter
    Signed-off-by: Dave Airlie

    Imre Deak
     
  • Currently we have a problem with this:
    1. i915: create gem object
    2. i915: export gem object to prime
    3. radeon: import gem object
    4. close prime fd
    5. radeon: unref object
    6. i915: unref object

    i915 has an imported object reference in its file priv, that isn't
    cleaned up properly until fd close. The reference gets added at step 2,
    but at step 6 we don't have enough info to clean it up.

    The solution is to take a reference on the dma-buf when we export it,
    and drop the reference when the gem handle goes away.

    So when we export a dma_buf from a gem object, we keep track of it
    with the handle, we take a reference to the dma_buf. When we close
    the handle (i.e. userspace is finished with the buffer), we drop
    the reference to the dma_buf, and it gets collected.

    This patch isn't meant to fix any other problem or bikesheds, and it doesn't
    fix any races with other scenarios.

    v1.1: move export symbol line back up.

    v2: okay I had to do a bit more, as the first patch showed a leak
    on one of my tests, that I found using the dma-buf debugfs support,
    the problem case is exporting a buffer twice with the same handle,
    we'd add another export handle for it unnecessarily, however
    we now fail if we try to export the same object with a different gem handle,
    however I'm not sure if that is a case I want to support, and I've
    gotten the code to WARN_ON if we hit something like that.

    v2.1: rebase this patch, write better commit msg.
    v3: cleanup error handling, track import vs export in linked list,
    these two patches were separate previously, but seem to work better
    like this.
    v4: danvet is correct, this code is no longer useful, since the buffer
    better exist, so remove it.
    v5: always take a reference to the dma buf object, import or export.
    (Imre Deak contributed this originally)
    v6: square the circle, remove import vs export tracking now
    that there is no difference

    Reviewed-by: Daniel Vetter
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie

    Dave Airlie
     

23 Mar, 2013

1 commit

  • It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
    sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
    creating SG table for the buffers having more than 204 physical pages i.e.
    equal to SG_MAX_SINGLE_ALLOC.

    When using sg_alloc_table_from_pages interface, in place of sg_alloc_table,
    page list will be passes to get each contiguous section which is represented
    by a single entry in the table. For a Contiguous Buffer, number of entries
    should be equal to 1.

    Following check is causing the failure which is not applicable for Non-Contig
    buffers:

    if (WARN_ON_ONCE(nents > max_ents))
    return -EINVAL;

    Above patch is well tested for EXYNOS4 and EXYNOS5 for with/wihtout IOMMU
    supprot. NOUVEAU and RADEON platforms also depends on drm_prime_pages_to_sg
    helper function.

    This set is base on "exynos-drm-fixes" branch at
    http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

    Signed-off-by: Rahul Sharma
    Acked-by: Dave Airlie
    Reviewed-by: Aaron Plattner
    Tested-by: Aaron Plattner
    Signed-off-by: Daniel Vetter

    Rahul Sharma
     

08 Feb, 2013

1 commit

  • Instead of reimplementing all of the dma_buf functionality in every driver,
    create helpers drm_prime_import and drm_prime_export that implement them in
    terms of new, lower-level hook functions:

    gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT
    gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
    gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
    gem_prime_vmap, gem_prime_vunmap: map and unmap an object

    These hooks are optional; drivers can opt in by using drm_gem_prime_import and
    drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
    struct drm_driver.

    v2:
    - Drop .begin_cpu_access. None of the drivers this code replaces implemented
    it. Having it here was a leftover from when I was trying to include i915 in
    this rework.
    - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
    did. This patch series shouldn't change that behavior.
    - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
    Rename struct sg_table* variables to 'sgt' for clarity.
    - Update drm.tmpl for these new hooks.

    v3:
    - Pass the vaddr down to the driver. This lets drivers that just call vunmap on
    the pointer avoid having to store the pointer in their GEM private structures.
    - Move documentation into a /** DOC */ comment in drm_prime.c and include it in
    drm.tmpl with a !P line. I tried to use !F lines to include documentation of
    the individual functions from drmP.h, but the docproc / kernel-doc scripts
    barf on that file, so hopefully this is good enough for now.
    - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
    ("drm/prime: drop reference on imported dma-buf come from gem")

    Signed-off-by: Aaron Plattner
    Cc: Daniel Vetter
    Cc: David Airlie
    Signed-off-by: Dave Airlie

    Aaron Plattner
     

03 Oct, 2012

1 commit


23 May, 2012

2 commits


30 Mar, 2012

1 commit

  • This adds the basic drm dma-buf interface layer, called PRIME. This
    commit doesn't add any driver support, it is simply and agreed upon starting
    point so we can work towards merging driver support for the next merge window.

    Current drivers with work done are nouveau, i915, udl, exynos and omap.

    The main APIs exposed to userspace allow translating a 32-bit object handle
    to a file descriptor, and a file descriptor to a 32-bit object handle.

    The flags value is currently limited to O_CLOEXEC.

    Acknowledgements:
    Daniel Vetter: lots of review
    Rob Clark: cleaned up lots of the internals and did lifetime review.

    v2: rename some functions after Chris preferred a green shed
    fix IS_ERR_OR_NULL -> IS_ERR
    v3: Fix Ville pointed out using buffer + kmalloc
    v4: add locking as per ickle review
    v5: allow re-exporting the original dma-buf (Daniel)

    Reviewed-by: Daniel Vetter
    Reviewed-by: Rob Clark
    Reviewed-by: Sumit Semwal
    Reviewed-by: Inki Dae
    Acked-by: Ben Widawsky
    Signed-off-by: Dave Airlie

    Dave Airlie