Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

4 participants
6271 discussions

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

by Rob Clark

On Fri, Mar 16, 2012 at 12:24 PM, Tom Cooksey <tom.cooksey(a)arm.com> wrote: > >> From: Rob Clark <rob(a)ti.com> >> >> Enable optional userspace access to dma-buf buffers via mmap() on the >> dma-buf file descriptor. Userspace access to the buffer should be >> bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to >> give the exporting driver a chance to deal with cache synchronization >> and such for cached userspace mappings without resorting to page >> faulting tricks. The reasoning behind this is that, while drm >> drivers tend to have all the mechanisms in place for dealing with >> page faulting tricks, other driver subsystems may not. And in >> addition, while page faulting tricks make userspace simpler, there >> are some associated overheads. > > Speaking for the ARM Mali T6xx driver point of view, this API looks > good for us. Our use-case for mmap is glReadPixels and > glTex[Sub]Image2D on buffers the driver has imported via dma_buf. In > the case of glReadPixels, the finish ioctl isn't strictly necessary > as the CPU won't have written to the buffer and so doesn't need > flushing. As such, we'd get an additional cache flush which isn't > really necessary. But hey, it's glReadPixels - it's supposed to be > slow. :-) > > I think requiring the finish ioctl in the API contract is a good > idea, even if the CPU has only done a ro access as it allows future > enhancements*. To "fix" the unnecessary flush in glReadPixels, I > think we'd like to keep the finish but see an "access type" > parameter added to prepare ioctl indicating if the access is ro or > rw to allow the cache flush in finish to be skipped if the access > was ro. As Rebecca says, a debug feature could even be added to > re-map the pages as ro in prepare(ro) to catch naughty accesses. I'd > also go as far as to say the debug feature should completely unmap > the pages after finish too. Though for us, both the access-type > parameter and debug features are "nice to haves" - we can make > progress with the code as it currently stands (assuming exporters > start using the API that is). Perhaps it isn't a bad idea to include access-type bitmask in the first version. It would help optimize a bit the cache operations. > Something which also came up when discussing internally is the topic > of mmap APIs of the importing device driver. For example, I believe > DRM has an mmap API on GEM buffer objects. If a new dma_buf import > ioctl was added to GEM (maybe the PRIME patches already add this), > how would GEM's bo mmap API work? My first thought is maybe we should just dis-allow this for now until we have a chance to see if there are any possible issues with an importer mmap'ing the buffer to userspace. We could possible have a helper dma_buf_mmap() fxn which in turn calls dmabuf ops->mmap() so the mmap'ing is actually performed by the exporter on behalf of the importer. > > * Future enhancements: The prepare/finish bracketing could be used > as part of a wider synchronization scheme with other devices. > E.g. If another device was writing to the buffer, the prepare ioctl > could block until that device had finished accessing that buffer. > In the same way, another device could be blocked from accessing that > buffer until the client process called finish. We have already > started playing with such a scheme in the T6xx driver stack we're > terming "kernel dependency system". In this scheme each buffer has a > FIFO of "buffer consumers" waiting to access a buffer. The idea > being that a "buffer consumer" is fairly abstract and could be any > device or userspace process participating in the synchronization > scheme. Examples would be GPU jobs, display controller "scan-out" > jobs, etc. > > So for example, a userspace application could dispatch a GPU > fragment shading job into the GPU's kernel driver which will write > to a KMS scanout buffer. The application then immediately issues a > drm_mode_crtc_page_flip ioctl on the display controller's DRM driver > to display the soon-to-be-rendered buffer. Inside the kernel, the > GPU driver adds the fragment job to the dma_buf's FIFO. As the FIFO > was empty, dma_buf calls into the GPU kernel driver to tell it it > "owns" access to the buffer and the GPU driver schedules the job to > run on the GPU. Upon receiving the drm_mode_crtc_page_flip ioctl, > the DRM/KMS driver adds a scan-out job to the buffer's FIFO. > However, the FIFO already has the GPU's fragment shading job in it > so nothing happens until the GPU job completes. When the GPU job > completes, the GPU driver calls into dma_buf to mark its job > complete. dma_buf then takes the next job in its FIFO which the KMS > driver's scanout job, calls into the KMS driver to schedule the > pageflip. The result? A buffer gets scanned out as soon as it has > finished being rendered without needing a round-trip to userspace. > Sure, there are easier ways to achieve that goal, but the idea is > that the mechanism can be used to synchronize access across multiple > devices, which makes it useful for lots of other use-cases too. > > > As I say, we have already implemented something which works as I > describe but where the buffers are abstract resources not linked to > dma_buf. I'd like to discuss the finer points of the mechanisms > further, but if it's looking like there's interest in this approach > we'll start re-writing the code we have to sit on-top of dma_buf > and posting it as RFCs to the various lists. The intention is to get > this to mainline, if mainline wants it. :-) I think we do need some sort of 'sync object' (which might really just be a 'synchronization queue' object) in the kernel. It probably shouldn't be built-in to dma-buf, but I expect we'd want the dma_buf struct to have a 'struct sync_queue *' (or whatever it ends up being called). The sync-queue seems like a reasonable approach for pure cpu-sw based synchronization. The only thing I'm not sure is how to also deal with hw that supports any sort of auto synchronization without cpu sw involvement. BR, -R > Personally, what I particularly like about this approach to > synchronization is that it doesn't require any interfaces to be > modified. I think/hope that makes it easier to port existing drivers > and sub-systems to take advantage of it. The buffer itself is the > synchronization object and interfaces already pass buffers around so > don't need modification. There are of course some limitations with > this approach, the main one we can think of being that it can't > really be used for A/V sync. It kinda assumes "jobs" in the FIFO > should be run as soon as the preceding job completes, which isn't > the case when streaming real-time video. Though nothing precludes > more explicit sync objects being used in conjunction with this > approach. > > > Cheers, > > Tom > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel

14 years, 1 month

[PATCH] RFC: dma-buf: userspace mmap support

by Rob Clark

From: Rob Clark <rob(a)ti.com> Enable optional userspace access to dma-buf buffers via mmap() on the dma-buf file descriptor. Userspace access to the buffer should be bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to give the exporting driver a chance to deal with cache synchronization and such for cached userspace mappings without resorting to page faulting tricks. The reasoning behind this is that, while drm drivers tend to have all the mechanisms in place for dealing with page faulting tricks, other driver subsystems may not. And in addition, while page faulting tricks make userspace simpler, there are some associated overheads. In all cases, the mmap() call is allowed to fail, and the associated dma_buf_ops are optional (mmap() will fail if at least the mmap() op is not implemented by the exporter, but in either case the {prepare,finish}_access() ops are optional). For now the prepare/finish access ioctls are kept simple with no argument, although there is possibility to add additional ioctls (or simply change the existing ioctls from _IO() to _IOW()) later to provide optimization to allow userspace to specify a region of interest. For a final patch, dma-buf.h would need to be split into what is exported to userspace, and what is kernel private, but I wanted to get feedback on the idea of requiring userspace to bracket access first (vs. limiting this to coherent mappings or exporters who play page faltings plus PTE shoot-down games) before I split the header which would cause conflicts with other pending dma-buf patches. So flame-on! --- drivers/base/dma-buf.c | 42 ++++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 22 ++++++++++++++++++++++ 2 files changed, 64 insertions(+), 0 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index c9a945f..382b78a 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -30,6 +30,46 @@ static inline int is_dma_buf_file(struct file *); +static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma) +{ + struct dma_buf *dmabuf; + + if (!is_dma_buf_file(file)) + return -EINVAL; + + dmabuf = file->private_data; + + if (dmabuf->ops->mmap) + return dmabuf->ops->mmap(dmabuf, file, vma); + + return -ENODEV; +} + +static long dma_buf_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) +{ + struct dma_buf *dmabuf; + + if (!is_dma_buf_file(file)) + return -EINVAL; + + dmabuf = file->private_data; + + switch (_IOC_NR(cmd)) { + case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS): + if (dmabuf->ops->prepare_access) + return dmabuf->ops->prepare_access(dmabuf); + return 0; + case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS): + if (dmabuf->ops->finish_access) + return dmabuf->ops->finish_access(dmabuf); + return 0; + default: + return -EINVAL; + } +} + + static int dma_buf_release(struct inode *inode, struct file *file) { struct dma_buf *dmabuf; @@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct file *file) } static const struct file_operations dma_buf_fops = { + .mmap = dma_buf_mmap, + .unlocked_ioctl = dma_buf_ioctl, .release = dma_buf_release, }; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index a885b26..cbdff81 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -34,6 +34,17 @@ struct dma_buf; struct dma_buf_attachment; +/* TODO: dma-buf.h should be the userspace visible header, and dma-buf-priv.h (?) + * the kernel internal header.. for now just stuff these here to avoid conflicting + * with other patches.. + * + * For now, no arg to keep things simple, but we could consider adding an + * optional region of interest later. + */ +#define DMA_BUF_IOCTL_PREPARE_ACCESS _IO('Z', 0) +#define DMA_BUF_IOCTL_FINISH_ACCESS _IO('Z', 1) + + /** * struct dma_buf_ops - operations possible on struct dma_buf * @attach: [optional] allows different devices to 'attach' themselves to the @@ -49,6 +60,13 @@ struct dma_buf_attachment; * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter * pages. * @release: release this buffer; to be called after the last dma_buf_put. + * @mmap: [optional, allowed to fail] operation called if userspace calls + * mmap() on the dmabuf fd. Note that userspace should use the + * DMA_BUF_PREPARE_ACCESS / DMA_BUF_FINISH_ACCESS ioctls before/after + * sw access to the buffer, to give the exporter an opportunity to + * deal with cache maintenance. + * @prepare_access: [optional] handler for PREPARE_ACCESS ioctl. + * @finish_access: [optional] handler for FINISH_ACCESS ioctl. */ struct dma_buf_ops { int (*attach)(struct dma_buf *, struct device *, @@ -72,6 +90,10 @@ struct dma_buf_ops { /* after final dma_buf_put() */ void (*release)(struct dma_buf *); + int (*mmap)(struct dma_buf *, struct file *, struct vm_area_struct *); + int (*prepare_access)(struct dma_buf *); + int (*finish_access)(struct dma_buf *); + }; /** -- 1.7.5.4

14 years, 1 month

expected userspace prime/dma-buf usage

by Dave Airlie

Just wondering how we expect userspace to use dma-buf/prime interfaces. Currently I see one driver in sharing the buffer with handle->fd, then passing the fd to the other driver and it using fd->handle, do we then expect the importing driver to close the fd? Dave.

14 years, 1 month

[PATCH v3 0/4] Add CMA heap for ION memory manager

by benjamin.gaignard＠stericsson.com

From: benjamin gaignard <benjamin.gaignard(a)linaro.org> The goal of those patches is to allow ION clients (drivers or userland applications) to use Contiguous Memory Allocator (CMA). To get more info about CMA: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html patches version 3: - add a private field in ion_heap structure instead of expose ion_device structure to all heaps - ion_cma_heap is no more a platform driver - ion_cma_heap use ion_heap private field to store the device pointer and make the link with reserved CMA regions - provide ux500-ion driver and configuration file for snowball board to give an example of how use CMA heaps patches version 2: - fix comments done by Andy Green Benjamin Gaignard (1): fix ion_platform_data definition add private field in ion_heap structure add CMA heap add test/example driver for ux500 platform arch/arm/mach-ux500/board-mop500.c | 80 +++++++++++++++++++ drivers/gpu/ion/Kconfig | 6 ++ drivers/gpu/ion/Makefile | 2 + drivers/gpu/ion/cma/Makefile | 1 + drivers/gpu/ion/cma/ion_cma_heap.c | 126 ++++++++++++++++++++++++++++++ drivers/gpu/ion/cma/ion_cma_heap.h | 11 +++ drivers/gpu/ion/ion_priv.h | 2 + drivers/gpu/ion/ux500/Makefile | 1 + drivers/gpu/ion/ux500/ux500_ion.c | 147 ++++++++++++++++++++++++++++++++++++ include/linux/ion.h | 2 +- 10 files changed, 377 insertions(+), 1 deletions(-) create mode 100644 drivers/gpu/ion/cma/Makefile create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.c create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.h create mode 100644 drivers/gpu/ion/ux500/Makefile create mode 100644 drivers/gpu/ion/ux500/ux500_ion.c

14 years, 1 month

[PATCH 0/3] Add CMA heap for ION memory manager

by benjamin.gaignard＠stericsson.com

14 years, 1 month

for-next inclusion request: dma-buf buffer sharing framework

by Sumit Semwal

Hi Stephen, May I request you to please add the dma-buf buffer sharing framework tree to linux-next? It is hosted here git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git branch: for-next -- Thanks and nest regards, Sumit Semwal.

14 years, 1 month

[PATCHv23 00/16] Contiguous Memory Allocator

by Marek Szyprowski

Hi, This is (yet another) quick update of CMA patches. I've rebased them onto next-20120222 tree from git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and fixed the bug pointed by Aaro Koskinen. Best regards Marek Szyprowski Samsung Poland R&D Center Links to previous versions of the patchset: v22: <http://www.spinics.net/lists/linux-media/msg44370.html> v21: <http://www.spinics.net/lists/linux-media/msg44155.html> v20: <http://www.spinics.net/lists/linux-mm/msg29145.html> v19: <http://www.spinics.net/lists/linux-mm/msg29145.html> v18: <http://www.spinics.net/lists/linux-mm/msg28125.html> v17: <http://www.spinics.net/lists/arm-kernel/msg148499.html> v16: <http://www.spinics.net/lists/linux-mm/msg25066.html> v15: <http://www.spinics.net/lists/linux-mm/msg23365.html> v14: <http://www.spinics.net/lists/linux-media/msg36536.html> v13: (internal, intentionally not released) v12: <http://www.spinics.net/lists/linux-media/msg35674.html> v11: <http://www.spinics.net/lists/linux-mm/msg21868.html> v10: <http://www.spinics.net/lists/linux-mm/msg20761.html> v9: <http://article.gmane.org/gmane.linux.kernel.mm/60787> v8: <http://article.gmane.org/gmane.linux.kernel.mm/56855> v7: <http://article.gmane.org/gmane.linux.kernel.mm/55626> v6: <http://article.gmane.org/gmane.linux.kernel.mm/55626> v5: (intentionally left out as CMA v5 was identical to CMA v4) v4: <http://article.gmane.org/gmane.linux.kernel.mm/52010> v3: <http://article.gmane.org/gmane.linux.kernel.mm/51573> v2: <http://article.gmane.org/gmane.linux.kernel.mm/50986> v1: <http://article.gmane.org/gmane.linux.kernel.mm/50669> Changelog: v23: 1. fixed bug spotted by Aaro Koskinen (incorrect check inside VM_BUG_ON) 2. rebased onto next-20120222 tree from git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git v22: 1. Fixed compilation break caused by missing fixup patch in v21 2. Fixed typos in the comments 3. Removed superfluous #include entries v21: 1. Fixed incorrect check which broke memory compaction code 2. Fixed hacky and racy min_free_kbytes handling 3. Added serialization patch to watermark calculation 4. Fixed typos here and there in the comments v20 and earlier - see previous patchsets. Patches in this patchset: Marek Szyprowski (6): mm: extract reclaim code from __alloc_pages_direct_reclaim() mm: trigger page reclaim in alloc_contig_range() to stabilise watermarks drivers: add Contiguous Memory Allocator X86: integrate CMA with DMA-mapping subsystem ARM: integrate CMA with DMA-mapping subsystem ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device Mel Gorman (1): mm: Serialize access to min_free_kbytes Michal Nazarewicz (9): mm: page_alloc: remove trailing whitespace mm: compaction: introduce isolate_migratepages_range() mm: compaction: introduce map_pages() mm: compaction: introduce isolate_freepages_range() mm: compaction: export some of the functions mm: page_alloc: introduce alloc_contig_range() mm: page_alloc: change fallbacks array handling mm: mmzone: MIGRATE_CMA migration type added mm: page_isolation: MIGRATE_CMA isolation functions added Documentation/kernel-parameters.txt | 9 + arch/Kconfig | 3 + arch/arm/Kconfig | 2 + arch/arm/include/asm/dma-contiguous.h | 15 ++ arch/arm/include/asm/mach/map.h | 1 + arch/arm/kernel/setup.c | 9 +- arch/arm/mm/dma-mapping.c | 369 ++++++++++++++++++++++++------ arch/arm/mm/init.c | 23 ++- arch/arm/mm/mm.h | 3 + arch/arm/mm/mmu.c | 31 ++- arch/arm/plat-s5p/dev-mfc.c | 51 +---- arch/x86/Kconfig | 1 + arch/x86/include/asm/dma-contiguous.h | 13 + arch/x86/include/asm/dma-mapping.h | 4 + arch/x86/kernel/pci-dma.c | 18 ++- arch/x86/kernel/pci-nommu.c | 8 +- arch/x86/kernel/setup.c | 2 + drivers/base/Kconfig | 89 +++++++ drivers/base/Makefile | 1 + drivers/base/dma-contiguous.c | 401 +++++++++++++++++++++++++++++++ include/asm-generic/dma-contiguous.h | 28 +++ include/linux/device.h | 4 + include/linux/dma-contiguous.h | 110 +++++++++ include/linux/gfp.h | 12 + include/linux/mmzone.h | 47 +++- include/linux/page-isolation.h | 18 +- mm/Kconfig | 2 +- mm/Makefile | 3 +- mm/compaction.c | 418 +++++++++++++++++++++------------ mm/internal.h | 33 +++ mm/memory-failure.c | 2 +- mm/memory_hotplug.c | 6 +- mm/page_alloc.c | 409 ++++++++++++++++++++++++++++---- mm/page_isolation.c | 15 +- mm/vmstat.c | 3 + 35 files changed, 1790 insertions(+), 373 deletions(-) create mode 100644 arch/arm/include/asm/dma-contiguous.h create mode 100644 arch/x86/include/asm/dma-contiguous.h create mode 100644 drivers/base/dma-contiguous.c create mode 100644 include/asm-generic/dma-contiguous.h create mode 100644 include/linux/dma-contiguous.h -- 1.7.1.569.g6f426

14 years, 1 month

Test application for DMABUF sharing between V4L2 and DRM

by Tomasz Stanislawski

Hi Everyone, This email contains a test application showing DMABUF sharing between DRM/KMS display and camera capture node. It show simple camera preview on LCD display. The similar application showing DMABUF sharing between two V4L devices is available at link: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4379… The program is written in C99 and it was tested using Exynos/DRM and FIMC capture for M5MOLS and S5K6AAFX sensors on UniversalC210 board. This application shows how buffer sharing between V4L2/DRM may look like. Please let me know if/where I use DRM/V4L2 incorrectly. The application was tested against 3.3-rc5 kernel with patches: http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 [redesign of DMA mapping] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4379… [support for dma_get_pages, PoC generic API for transforming DMA object into list of pages] http://thread.gmane.org/gmane.comp.video.dri.devel/65583/focus=65703 [DRM prime support] http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exy… [DRM prime support for Exynos DRM] http://thread.gmane.org/gmane.comp.video.dri.devel/65992 [fix to DRM prime in Exynos DRM] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296… [support for DMABUF importing in V4L2] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/45394 [integrate V4L2 with DMABUF] Regards, Tomasz Stanislawski --- #include <errno.h> #include <fcntl.h> #include <linux/videodev2.h> #include <math.h> #include <poll.h> #include <stdio.h> #include <stdint.h> #include <stdlib.h> #include <string.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <sys/stat.h> #include <sys/types.h> #include <unistd.h> #include <xf86drm.h> #include <xf86drmMode.h> #include <exynos_drm.h> #define ERRSTR strerror(errno) #define BYE_ON(cond, ...) \ do { \ if (cond) { \ int errsv = errno; \ fprintf(stderr, "ERROR(%s:%d) : ", \ __FILE__, __LINE__); \ errno = errsv; \ fprintf(stderr, __VA_ARGS__); \ abort(); \ } \ } while(0) static inline int warn(const char *file, int line, const char *fmt, ...) { int errsv = errno; va_list va; va_start(va, fmt); fprintf(stderr, "WARN(%s:%d): ", file, line); vfprintf(stderr, fmt, va); va_end(va); errno = errsv; return 1; } #define WARN_ON(cond, ...) \ ((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0) struct setup { char module[32]; uint32_t conId; uint32_t crtId; char modestr[32]; char video[32]; unsigned int w, h; unsigned int use_wh : 1; unsigned int in_fourcc; unsigned int out_fourcc; unsigned int buffer_count; unsigned int use_crop : 1; unsigned int use_compose : 1; struct v4l2_rect crop; struct v4l2_rect compose; }; struct buffer { unsigned int bo_handle; unsigned int fb_handle; int dbuf_fd; }; struct stream { int v4lfd; int current_buffer; int buffer_count; struct buffer *buffer; } stream; static void usage(char *name) { fprintf(stderr, "usage: %s [-Moisth]\n", name); fprintf(stderr, "\t-M <drm-module>\tset DRM module\n"); fprintf(stderr, "\t-o <connector_id>:<crtc_id>:<mode>\tset a mode\n"); fprintf(stderr, "\t-i <video-node>\tset video node like /dev/video*\n"); fprintf(stderr, "\t-S <width,height>\tset input resolution\n"); fprintf(stderr, "\t-f <fourcc>\tset input format using 4cc\n"); fprintf(stderr, "\t-F <fourcc>\tset output format using 4cc\n"); fprintf(stderr, "\t-s <width,height>@<left,top>\tset crop area\n"); fprintf(stderr, "\t-t <width,height>@<left,top>\tset compose area\n"); fprintf(stderr, "\t-b buffer_count\tset number of buffers\n"); fprintf(stderr, "\t-h\tshow this help\n"); fprintf(stderr, "\n\tDefault is to dump all info.\n"); } static inline int parse_rect(char *s, struct v4l2_rect *r) { return sscanf(s, "%d,%d@%d,%d", &r->width, &r->height, &r->top, &r->left) != 4; } static int parse_args(int argc, char *argv[], struct setup *s) { if (argc <= 1) usage(argv[0]); int c, ret; memset(s, 0, sizeof(*s)); while ((c = getopt(argc, argv, "M:o:i:S:f:F:s:t:b:h")) != -1) { switch (c) { case 'M': strncpy(s->module, optarg, 31); break; case 'o': ret = sscanf(optarg, "%u:%u:%31s", &s->conId, &s->crtId, s->modestr); if (WARN_ON(ret != 3, "incorrect mode description\n")) return -1; break; case 'i': strncpy(s->video, optarg, 31); break; case 'S': ret = sscanf(optarg, "%u,%u", &s->w, &s->h); if (WARN_ON(ret != 2, "incorrect input size\n")) return -1; s->use_wh = 1; break; case 'f': if (WARN_ON(strlen(optarg) != 4, "invalid fourcc\n")) return -1; s->in_fourcc = ((unsigned)optarg[0] << 0) | ((unsigned)optarg[1] << 8) | ((unsigned)optarg[2] << 16) | ((unsigned)optarg[3] << 24); break; case 'F': if (WARN_ON(strlen(optarg) != 4, "invalid fourcc\n")) return -1; s->out_fourcc = ((unsigned)optarg[0] << 0) | ((unsigned)optarg[1] << 8) | ((unsigned)optarg[2] << 16) | ((unsigned)optarg[3] << 24); break; case 's': ret = parse_rect(optarg, &s->crop); if (WARN_ON(ret, "incorrect crop area\n")) return -1; s->use_crop = 1; break; case 't': ret = parse_rect(optarg, &s->compose); if (WARN_ON(ret, "incorrect compose area\n")) return -1; s->use_compose = 1; break; case 'b': ret = sscanf(optarg, "%u", &s->buffer_count); if (WARN_ON(ret != 1, "incorrect buffer count\n")) return -1; break; case '?': case 'h': usage(argv[0]); return -1; } } return 0; } static int buffer_create(struct buffer *b, int drmfd, struct setup *s, uint64_t size, uint32_t pitch) { int ret = strncmp(s->module, "exynos", 6); if (WARN_ON(ret, "drm: only exynos GEM is supported\n")) return -1; struct drm_exynos_gem_create gem; struct drm_gem_close gem_close; memset(&gem, 0, sizeof gem); gem.size = size; ret = ioctl(drmfd, DRM_IOCTL_EXYNOS_GEM_CREATE, &gem); if (WARN_ON(ret, "EXYNOS_GEM_CREATE failed: %s\n", ERRSTR)) return -1; b->bo_handle = gem.handle; struct drm_prime_handle prime; memset(&prime, 0, sizeof prime); prime.handle = b->bo_handle; ret = ioctl(drmfd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &prime); if (WARN_ON(ret, "PRIME_HANDLE_TO_FD failed: %s\n", ERRSTR)) goto fail_gem; printf("dbuf_fd = %d\n", prime.fd); b->dbuf_fd = prime.fd; uint32_t offsets[4] = { 0 }; uint32_t pitches[4] = { pitch }; uint32_t bo_handles[4] = { b->bo_handle }; unsigned int fourcc = s->out_fourcc; if (!fourcc) fourcc = s->in_fourcc; ret = drmModeAddFB2(drmfd, s->w, s->h, fourcc, bo_handles, pitches, offsets, &b->fb_handle, 0); if (WARN_ON(ret, "drmModeAddFB2 failed: %s\n", ERRSTR)) goto fail_prime; return 0; fail_prime: close(b->dbuf_fd); fail_gem: memset(&gem_close, 0, sizeof gem_close); gem_close.handle = b->bo_handle, ret = ioctl(drmfd, DRM_IOCTL_GEM_CLOSE, gem_close); WARN_ON(ret, "GEM_CLOSE failed: %s\n", ERRSTR); return -1; } static int find_mode(drmModeModeInfo *m, int drmfd, struct setup *s, uint32_t *con) { int ret = -1; drmModeRes *res = drmModeGetResources(drmfd); if (WARN_ON(!res, "drmModeGetResources failed: %s\n", ERRSTR)) return -1; if (WARN_ON(res->count_crtcs <= 0, "drm: no crts\n")) goto fail_res; if (WARN_ON(res->count_connectors <= 0, "drm: no connectors\n")) goto fail_res; if (WARN_ON(s->conId >= res->count_connectors, "connector %d " "is not supported\n", s->conId)) goto fail_res; drmModeConnector *c; c = drmModeGetConnector(drmfd, res->connectors[s->conId]); if (WARN_ON(!c, "drmModeGetConnector failed: %s\n", ERRSTR)) goto fail_res; if (WARN_ON(!c->count_modes, "connector supports no mode\n")) goto fail_conn; drmModeModeInfo *found = NULL; for (int i = 0; i < c->count_modes; ++i) if (strcmp(c->modes[i].name, s->modestr) == 0) found = &c->modes[i]; if (WARN_ON(!found, "mode %s not supported\n", s->modestr)) { fprintf(stderr, "Valid modes:"); for (int i = 0; i < c->count_modes; ++i) fprintf(stderr, " %s", c->modes[i].name); fprintf(stderr, "\n"); goto fail_conn; } memcpy(m, found, sizeof *found); if (con) *con = c->connector_id; ret = 0; fail_conn: drmModeFreeConnector(c); fail_res: drmModeFreeResources(res); return ret; } static void page_flip_handler(int fd, unsigned int frame, unsigned int sec, unsigned int usec, void *data) { int index = stream.current_buffer; struct v4l2_buffer buf; struct v4l2_plane plane; int ret; stream.current_buffer = (int)data; if (index < 0) return; memset(&buf, 0, sizeof buf); memset(&plane, 0, sizeof plane); buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; buf.memory = V4L2_MEMORY_DMABUF; buf.index = index; buf.m.planes = &plane; buf.length = 1; plane.m.fd = stream.buffer[index].dbuf_fd; ret = ioctl(stream.v4lfd, VIDIOC_QBUF, &buf); BYE_ON(ret, "VIDIOC_QBUF(index = %d) failed: %s\n", index, ERRSTR); } int main(int argc, char *argv[]) { int ret; struct setup s; ret = parse_args(argc, argv, &s); BYE_ON(ret, "failed to parse arguments\n"); BYE_ON(s.module[0] == 0, "DRM module is missing\n"); BYE_ON(s.video[0] == 0, "video node is missing\n"); int drmfd = drmOpen(s.module, NULL); BYE_ON(drmfd < 0, "drmOpen(%s) failed: %s\n", s.module, ERRSTR); int v4lfd = open(s.video, O_RDWR); BYE_ON(v4lfd < 0, "failed to open %s: %s\n", s.video, ERRSTR); struct v4l2_capability caps; memset(&caps, 0, sizeof caps); ret = ioctl(v4lfd, VIDIOC_QUERYCAP, &caps); BYE_ON(ret, "VIDIOC_QUERYCAP failed: %s\n", ERRSTR); /* TODO: add single plane support */ BYE_ON(~caps.capabilities & V4L2_CAP_VIDEO_CAPTURE_MPLANE, "video: multiplanar capture is not supported\n"); struct v4l2_format fmt; memset(&fmt, 0, sizeof fmt); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; ret = ioctl(v4lfd, VIDIOC_G_FMT, &fmt); BYE_ON(ret < 0, "VIDIOC_G_FMT failed: %s\n", ERRSTR); printf("G_FMT(start): width = %u, height = %u, 4cc = %.4s\n", fmt.fmt.pix_mp.width, fmt.fmt.pix_mp.height, (char*)&fmt.fmt.pix_mp.pixelformat); if (s.use_wh) { fmt.fmt.pix_mp.width = s.w; fmt.fmt.pix_mp.height = s.h; } if (s.in_fourcc) fmt.fmt.pix_mp.pixelformat = s.in_fourcc; ret = ioctl(v4lfd, VIDIOC_S_FMT, &fmt); BYE_ON(ret < 0, "VIDIOC_S_FMT failed: %s\n", ERRSTR); ret = ioctl(v4lfd, VIDIOC_G_FMT, &fmt); BYE_ON(ret < 0, "VIDIOC_G_FMT failed: %s\n", ERRSTR); printf("G_FMT(final): width = %u, height = %u, 4cc = %.4s\n", fmt.fmt.pix_mp.width, fmt.fmt.pix_mp.height, (char*)&fmt.fmt.pix_mp.pixelformat); BYE_ON(fmt.fmt.pix_mp.num_planes > 1, "multiplanar formats are not supported\n"); struct v4l2_requestbuffers rqbufs; memset(&rqbufs, 0, sizeof(rqbufs)); rqbufs.count = s.buffer_count; rqbufs.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; rqbufs.memory = V4L2_MEMORY_DMABUF; ret = ioctl(v4lfd, VIDIOC_REQBUFS, &rqbufs); BYE_ON(ret < 0, "VIDIOC_REQBUFS failed: %s\n", ERRSTR); BYE_ON(rqbufs.count < s.buffer_count, "video node allocated only " "%u of %u buffers\n", rqbufs.count, s.buffer_count); s.in_fourcc = fmt.fmt.pix_mp.pixelformat; s.w = fmt.fmt.pix_mp.width; s.h = fmt.fmt.pix_mp.height; /* TODO: add support for multiplanar formats */ struct buffer buffer[s.buffer_count]; uint64_t size = fmt.fmt.pix_mp.plane_fmt[0].sizeimage; uint32_t pitch = fmt.fmt.pix_mp.plane_fmt[0].bytesperline; printf("size = %llu pitch = %u\n", size, pitch); for (int i = 0; i < s.buffer_count; ++i) { ret = buffer_create(&buffer[i], drmfd, &s, size, pitch); BYE_ON(ret, "failed to create buffer%d\n", i); } printf("buffers ready\n"); drmModeModeInfo drmmode; uint32_t con; ret = find_mode(&drmmode, drmfd, &s, &con); BYE_ON(ret, "failed to find valid mode\n"); ret = drmModeSetCrtc(drmfd, s.crtId, buffer[0].fb_handle, 0, 0, &con, 1, &drmmode); BYE_ON(ret, "drmModeSetCrtc failed: %s\n", ERRSTR); /* enqueueing first buffer to DRM */ ret = drmModePageFlip(drmfd, s.crtId, buffer[0].fb_handle, DRM_MODE_PAGE_FLIP_EVENT, 0); BYE_ON(ret, "drmModePageFlip failed: %s\n", ERRSTR); for (int i = 1; i < s.buffer_count; ++i) { struct v4l2_plane plane; memset(&plane, 0, sizeof plane); struct v4l2_buffer buf; memset(&buf, 0, sizeof buf); buf.index = i; buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; buf.memory = V4L2_MEMORY_DMABUF; buf.m.planes = &plane; buf.length = 1; plane.m.fd = buffer[i].dbuf_fd; ret = ioctl(v4lfd, VIDIOC_QBUF, &buf); BYE_ON(ret < 0, "VIDIOC_QBUF for buffer %d failed: %s\n", buf.index, ERRSTR); } int type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; ret = ioctl(v4lfd, VIDIOC_STREAMON, &type); BYE_ON(ret < 0, "STREAMON failed: %s\n", ERRSTR); struct pollfd fds[] = { { .fd = v4lfd, .events = POLLIN }, { .fd = drmfd, .events = POLLIN }, }; /* buffer currently used by drm */ stream.v4lfd = v4lfd; stream.current_buffer = -1; stream.buffer = buffer; while ((ret = poll(fds, 2, 5000)) > 0) { if (fds[0].revents & POLLIN) { struct v4l2_buffer buf; memset(&buf, 0, sizeof buf); /* dequeue buffer */ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; buf.memory = V4L2_MEMORY_DMABUF; ret = ioctl(v4lfd, VIDIOC_DQBUF, &buf); BYE_ON(ret, "VIDIOC_DQBUF failed: %s\n", ERRSTR); ret = drmModePageFlip(drmfd, s.crtId, buffer[buf.index].fb_handle, DRM_MODE_PAGE_FLIP_EVENT, (void*)buf.index); BYE_ON(ret, "drmModePageFlip failed: %s\n", ERRSTR); } if (fds[1].revents & POLLIN) { drmEventContext evctx; memset(&evctx, 0, sizeof evctx); evctx.version = DRM_EVENT_CONTEXT_VERSION; evctx.page_flip_handler = page_flip_handler; ret = drmHandleEvent(drmfd, &evctx); BYE_ON(ret, "drmHandleEvent failed: %s\n", ERRSTR); } } return 0; }

14 years, 1 month

[PATCH 0/3] [RFC] kernel cpu access support for dma_buf

by Daniel Vetter

Hi all, This series here implements an interface to enable cpu access from the kernel context to dma_buf objects. The main design goal of this interface proposal is to enable buffer objects that reside in highmem. Comments, flames, ideas and questions highly welcome. Althouhg I might be a bit slow in responding - I'm on conferences and vacation the next 2 weeks. Cheers, Daniel Daniel Vetter (3): dma-buf: don't hold the mutex around map/unmap calls dma-buf: add support for kernel cpu access dma_buf: Add documentation for the new cpu access support Documentation/dma-buf-sharing.txt | 102 +++++++++++++++++++++++++++++- drivers/base/dma-buf.c | 124 +++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 62 ++++++++++++++++++- 3 files changed, 280 insertions(+), 8 deletions(-) -- 1.7.7.5

14 years, 1 month

dma-buf feature tree: working model

by Sumit Semwal

Hi all, Since the inclusion of dma-buf buffer sharing framework in 3.3 (thanks to Dave Airlie primarily), I have been volunteered to be its maintainer. Obviously there is a need for some simple rules about the dma-buf feature tree, so here we are: - there will be a 'for-next' branch for (N+1), which will open around -Nrc1, and close about 1-2 weeks before the (N+1)merge opens. - there will be a 'fixes' branch, which will take fixes after the for-next pull request is sent upstream. - after -rc2, regression fixes only. - after -rc4/5, only revert and disable patches. The real fix should then be targeted at for-next. - to stop me from pushing useless stuff, I will merge my own patches only after sufficient review on our mailing lists. If you see me breaking this rule, please shout out at me _publicly_ at the top of your voice. Being a 'first-time-maintainer', I am very willing to learn on-the-job, though I might still take cover under the 'first-time-maintainer' umbrella [for sometime :)] for any stupid acts I might commit. The tree resides at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git At present, the mailing lists are: linux-media(a)vger.kernel.org, dri-devel(a)lists.freedesktop.org, linaro-mm-sig(a)lists.linaro.org, in addition to lkml. Comments, flames and suggestions highly welcome. (I have been 'influenced' quite a bit from Daniel Vetter's model for the drm/i915 -next tree [thank you, DanVet!], but any errors/omissions are entirely mine.) Thanks and regards, ~Sumit.

14 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig