[Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework
sumit.semwal at linaro.org
Mon Aug 29 09:01:59 UTC 2011
On 26 August 2011 23:39, Clark, Rob <rob at ti.com> wrote:
> On Fri, Aug 26, 2011 at 12:30 PM, Jordan Crouse <jcrouse at quicinc.com>
> > On 08/26/2011 10:28 AM, Clark, Rob wrote:
> >> On Fri, Aug 26, 2011 at 4:06 AM, Hans Verkuil<hverkuil at xs4all.nl>
> >>> Frankly, I'm not sure about the read and write. I don't really see the
> >>> use
> >>> case. The whole point of buffer sharing is to avoid copying buffers,
> >>> that's
> >>> exactly what read and write do.
> >> The main point (and maybe there is no point) for read/write is an
> >> alternative interface for sw access to buffer.. it isn't really
> >> intended for performant use cases, but rather for edge-cases. Like
> >> when we want to grab one frame of video and use sw to generate a
> >> thumbnail.
> >> Possibly mmap interface would be fine. But read/write seems
> >> attractive because you could do an easier job of hiding some weird
> >> formats. (Which I suppose you could still do w/ mmap and fault
> >> handling games.)
> >> I don't have any immediate plans for such use (mmap would suffice),
> >> but it did seem good to have all the normal file ops supported. If
> >> someone passed me a fd in userspace, I would expect to be able to
> >> read() and write(), and would be a bit surprised if that wasn't
> >> supported. So I guess principle-of-least-surpise applies here.
> > In that same line of thought you should implement lseek too. I wouldn't
> > find it odd to not have read/write available, but that might be shaded by
> > my prior DRM experience.
> yeah, I assume lseek (if we have read/write).. well default_llseek
> would be enough for any scenario I could think of, but I guess we
> might as well let the exporting driver provide default_llseek if that
> is what it wants
> re: DRM.. well, I assume that is because you don't have a fd for GEM
> anyways, "normal" fileops aren't a must-have.. the use-cases of sw
> access that I could think of would probably prefer mmap. There
> shouldn't be any issue to add them later if someone came up for a good
> reason to have 'em.
Ok - so to consolidate feedback: I would remove off read-write() calls [from
both dma-buf-ops and fileops], leave mmap() in. If during the course of
development, like Rob said, should anyone need a reason for them to be in,
we can add them back.
> > Personally, if I was to use a read/write interface I would want something
> > close to the PWRITE ioctl that the i915 DRM driver uses, but I agree that
> > in any event read/write will be a lesser used path, except possibly in
> > the case of SW rendering (and I _hope_ that is a lesser used path).
> > Jordan
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
Thanks and regards,
Linaro Kernel Engineer - Graphics working group
Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs*
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
| Blog <http://www.linaro.org/linaro-blog/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linaro-mm-sig