All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: rob.clark@linaro.org, linaro-mm-sig@lists.linaro.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, patches@linaro.org
Subject: Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)
Date: Thu, 09 Aug 2012 11:39:30 +0200	[thread overview]
Message-ID: <50238552.6030404@canonical.com> (raw)
In-Reply-To: <CAO_48GGmo65yT9UeJk69f-ASir3E+SWMsOJXgN4M_-UyO3XqUA@mail.gmail.com>

Hey Sumit,

Op 08-08-12 08:35, Sumit Semwal schreef:
> Hi Maarten,
>
> On 8 August 2012 00:17, Maarten Lankhorst
> <maarten.lankhorst@canonical.com> wrote:
>> Op 07-08-12 19:53, Maarten Lankhorst schreef:
>>> A dma-fence can be attached to a buffer which is being filled or consumed
>>> by hw, to allow userspace to pass the buffer without waiting to another
>>> device.  For example, userspace can call page_flip ioctl to display the
>>> next frame of graphics after kicking the GPU but while the GPU is still
>>> rendering.  The display device sharing the buffer with the GPU would
>>> attach a callback to get notified when the GPU's rendering-complete IRQ
>>> fires, to update the scan-out address of the display, without having to
>>> wake up userspace.
> Thanks for this patchset; Could you please also fill up
> Documentation/dma-buf-sharing.txt, to include the relevant bits?
>
> We've tried to make sure the Documentation corresponding is kept
> up-to-date as the framework has grown, and new features are added to
> it - and I think features as important as dma-fence and dmabufmgr do
> warrant a healthy update.

Ok I'll clean it up and add the documentation, one other question. If code
that requires dmabuf needs to select CONFIG_DMA_SHARED_BUFFER,
why does dma-buf.h have fallbacks for !CONFIG_DMA_SHARED_BUFFER?
This seems weird, would you have any objection if I removed those?

~Maarten

      reply	other threads:[~2012-08-09  9:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-07 17:53 [PATCH 1/3] dma-fence: dma-buf synchronization (v7) Maarten Lankhorst
2012-08-07 17:54 ` [PATCH 2/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing Maarten Lankhorst
2012-08-07 17:54 ` [PATCH 3/3] dma-buf-mgr: multiple dma-buf synchronization (v3) Maarten Lankhorst
2012-08-07 18:47 ` [PATCH 1/3] dma-fence: dma-buf synchronization (v7) Maarten Lankhorst
2012-08-08  6:35   ` Sumit Semwal
2012-08-09  9:39     ` Maarten Lankhorst [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50238552.6030404@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rob.clark@linaro.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.