1. 24 Oct, 2019 4 commits
    • Wambui Karuga's avatar
      drm/mediatek: remove cast to pointers passed to kfree · 2ec35bd2
      Wambui Karuga authored
      Remove unnecessary casts to pointer types passed to kfree.
      Issue detected by coccinelle:
      @@
      type t1;
      expression *e;
      @@
      
      -kfree((t1 *)e);
      +kfree(e);
      Signed-off-by: default avatarWambui Karuga <wambui.karugax@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191023111107.9972-1-wambui.karugax@gmail.com
      2ec35bd2
    • Daniel Vetter's avatar
      drm/simple-kms: Standardize arguments for callbacks · 62db7d1e
      Daniel Vetter authored
      Passing the wrong type feels icky, everywhere else we use the pipe as
      the first parameter. Spotted while discussing patches with Thomas
      Zimmermann.
      
      v2: Make xen compile correctly
      
      Acked-By: Thomas Zimmermann <tzimmermann@suse.de> (v1)
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Emil Velikov <emil.velikov@collabora.com>
      Cc: virtualization@lists.linux-foundation.org
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191023101256.20509-1-daniel.vetter@ffwll.ch
      62db7d1e
    • Christian König's avatar
      dma-buf: stop using the dmabuf->lock so much v2 · f45f57cc
      Christian König authored
      The attachment list is now protected by the dma_resv object.
      
      Stop holding the dma_buf->lock while calling ->attach/->detach,
      this allows for concurrent attach/detach operations.
      
      v2: cleanup commit message and locking in _debug_show()
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/336790
      f45f57cc
    • Christian König's avatar
      dma-buf: change DMA-buf locking convention v3 · 15fd552d
      Christian König authored
      This patch is a stripped down version of the locking changes
      necessary to support dynamic DMA-buf handling.
      
      It adds a dynamic flag for both importers as well as exporters
      so that drivers can choose if they want the reservation object
      locked or unlocked during mapping of attachments.
      
      For compatibility between drivers we cache the DMA-buf mapping
      during attaching an importer as soon as exporter/importer
      disagree on the dynamic handling.
      
      Issues and solutions we considered:
      
      - We can't change all existing drivers, and existing improters have
        strong opinions about which locks they're holding while calling
        dma_buf_attachment_map/unmap. Exporters also have strong opinions about
        which locks they can acquire in their ->map/unmap callbacks, levaing no
        room for change. The solution to avoid this was to move the
        actual map/unmap out from this call, into the attach/detach callbacks,
        and cache the mapping. This works because drivers don't call
        attach/detach from deep within their code callchains (like deep in
        memory management code called from cs/execbuf ioctl), but directly from
        the fd2handle implementation.
      
      - The caching has some troubles on some soc drivers, which set other modes
        than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
        can't re-create the mapping at _map time due to the above locking fun.
        We very carefuly step around that by only caching at attach time if the
        dynamic mode between importer/expoert mismatches.
      
      - There's been quite some discussion on dma-buf mappings which need active
        cache management, which would all break down when caching, plus we don't
        have explicit flush operations on the attachment side. The solution to
        this was to shrug and keep the current discrepancy between what the
        dma-buf docs claim and what implementations do, with the hope that the
        begin/end_cpu_access hooks are good enough and that all necessary
        flushing to keep device mappings consistent will be done there.
      
      v2: cleanup set_name merge, improve kerneldoc
      v3: update commit message, kerneldoc and cleanup _debug_show()
      Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/336788/
      15fd552d
  2. 23 Oct, 2019 19 commits
  3. 22 Oct, 2019 17 commits