Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
7027 discussions

Re: [Linaro-mm-sig] [RFC] Helper to abstract vma handling in media layer

by Hans Verkuil

On 04/11/2014 12:18 AM, Jan Kara wrote: > On Thu 10-04-14 23:57:38, Jan Kara wrote: >> On Thu 10-04-14 14:22:20, Hans Verkuil wrote: >>> On 04/10/14 14:15, Jan Kara wrote: >>>> On Thu 10-04-14 13:07:42, Hans Verkuil wrote: >>>>> On 04/10/14 12:32, Jan Kara wrote: >>>>>> Hello, >>>>>> >>>>>> On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: >>>>>>> On 2014-03-17 20:49, Jan Kara wrote: >>>>>>>> The following patch series is my first stab at abstracting vma handling >>>>>>> >from the various media drivers. After this patch set drivers have to know >>>>>>>> much less details about vmas, their types, and locking. My motivation for >>>>>>>> the series is that I want to change get_user_pages() locking and I want >>>>>>>> to handle subtle locking details in as few places as possible. >>>>>>>> >>>>>>>> The core of the series is the new helper get_vaddr_pfns() which is given a >>>>>>>> virtual address and it fills in PFNs into provided array. If PFNs correspond to >>>>>>>> normal pages it also grabs references to these pages. The difference from >>>>>>>> get_user_pages() is that this function can also deal with pfnmap, mixed, and io >>>>>>>> mappings which is what the media drivers need. >>>>>>>> >>>>>>>> The patches are just compile tested (since I don't have any of the hardware >>>>>>>> I'm afraid I won't be able to do any more testing anyway) so please handle >>>>>>>> with care. I'm grateful for any comments. >>>>>>> >>>>>>> Thanks for posting this series! I will check if it works with our >>>>>>> hardware soon. This is something I wanted to introduce some time ago to >>>>>>> simplify buffer handling in dma-buf, but I had no time to start working. >>>>>> Thanks for having a look in the series. >>>>>> >>>>>>> However I would like to go even further with integration of your pfn >>>>>>> vector idea. This structure looks like a best solution for a compact >>>>>>> representation of the memory buffer, which should be considered by the >>>>>>> hardware as contiguous (either contiguous in physical memory or mapped >>>>>>> contiguously into dma address space by the respective iommu). As you >>>>>>> already noticed it is widely used by graphics and video drivers. >>>>>>> >>>>>>> I would also like to add support for pfn vector directly to the >>>>>>> dma-mapping subsystem. This can be done quite easily (even with a >>>>>>> fallback for architectures which don't provide method for it). I will try >>>>>>> to prepare rfc soon. This will finally remove the need for hacks in >>>>>>> media/v4l2-core/videobuf2-dma-contig.c >>>>>> That would be a worthwhile thing to do. When I was reading the code this >>>>>> seemed like something which could be done but I delibrately avoided doing >>>>>> more unification than necessary for my purposes as I don't have any >>>>>> hardware to test and don't know all the subtleties in the code... BTW, is >>>>>> there some way to test the drivers without the physical video HW? >>>>> >>>>> You can use the vivi driver (drivers/media/platform/vivi) for this. >>>>> However, while the vivi driver can import dma buffers it cannot export >>>>> them. If you want that, then you have to use this tree: >>>>> >>>>> http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vb2-part4 >>>> Thanks for the pointer that looks good. I've also found >>>> drivers/media/platform/mem2mem_testdev.c which seems to do even more >>>> testing of the area I made changes to. So now I have to find some userspace >>>> tool which can issue proper ioctls to setup and use the buffers and I can >>>> start testing what I wrote :) >>> >>> Get the v4l-utils.git repository (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/). >>> You want the v4l2-ctl tool. Don't use the version supplied by your distro, >>> that's often too old. >>> >>> 'v4l2-ctl --help-streaming' gives the available options for doing streaming. >>> >>> So simple capturing from vivi is 'v4l2-ctl --stream-mmap' or '--stream-user'. >>> You can't test dmabuf unless you switch to the vb2-part4 branch of my tree. >> Great, it seems to be doing something and it shows there's some bug in my >> code. Thanks a lot for help. > OK, so after a small fix the basic functionality seems to be working. It > doesn't seem there's a way to test multiplanar buffers with vivi, is there? For that you need to switch to the vb2-part4 branch as well. That has support for multiplanar. Regards, Hans

12 years, 4 months

Re: [Linaro-mm-sig] [RFC] Helper to abstract vma handling in media layer

by Hans Verkuil

On 04/10/14 14:15, Jan Kara wrote: > On Thu 10-04-14 13:07:42, Hans Verkuil wrote: >> On 04/10/14 12:32, Jan Kara wrote: >>> Hello, >>> >>> On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: >>>> On 2014-03-17 20:49, Jan Kara wrote: >>>>> The following patch series is my first stab at abstracting vma handling >>>> >from the various media drivers. After this patch set drivers have to know >>>>> much less details about vmas, their types, and locking. My motivation for >>>>> the series is that I want to change get_user_pages() locking and I want >>>>> to handle subtle locking details in as few places as possible. >>>>> >>>>> The core of the series is the new helper get_vaddr_pfns() which is given a >>>>> virtual address and it fills in PFNs into provided array. If PFNs correspond to >>>>> normal pages it also grabs references to these pages. The difference from >>>>> get_user_pages() is that this function can also deal with pfnmap, mixed, and io >>>>> mappings which is what the media drivers need. >>>>> >>>>> The patches are just compile tested (since I don't have any of the hardware >>>>> I'm afraid I won't be able to do any more testing anyway) so please handle >>>>> with care. I'm grateful for any comments. >>>> >>>> Thanks for posting this series! I will check if it works with our >>>> hardware soon. This is something I wanted to introduce some time ago to >>>> simplify buffer handling in dma-buf, but I had no time to start working. >>> Thanks for having a look in the series. >>> >>>> However I would like to go even further with integration of your pfn >>>> vector idea. This structure looks like a best solution for a compact >>>> representation of the memory buffer, which should be considered by the >>>> hardware as contiguous (either contiguous in physical memory or mapped >>>> contiguously into dma address space by the respective iommu). As you >>>> already noticed it is widely used by graphics and video drivers. >>>> >>>> I would also like to add support for pfn vector directly to the >>>> dma-mapping subsystem. This can be done quite easily (even with a >>>> fallback for architectures which don't provide method for it). I will try >>>> to prepare rfc soon. This will finally remove the need for hacks in >>>> media/v4l2-core/videobuf2-dma-contig.c >>> That would be a worthwhile thing to do. When I was reading the code this >>> seemed like something which could be done but I delibrately avoided doing >>> more unification than necessary for my purposes as I don't have any >>> hardware to test and don't know all the subtleties in the code... BTW, is >>> there some way to test the drivers without the physical video HW? >> >> You can use the vivi driver (drivers/media/platform/vivi) for this. >> However, while the vivi driver can import dma buffers it cannot export >> them. If you want that, then you have to use this tree: >> >> http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vb2-part4 > Thanks for the pointer that looks good. I've also found > drivers/media/platform/mem2mem_testdev.c which seems to do even more > testing of the area I made changes to. So now I have to find some userspace > tool which can issue proper ioctls to setup and use the buffers and I can > start testing what I wrote :) Get the v4l-utils.git repository (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/). You want the v4l2-ctl tool. Don't use the version supplied by your distro, that's often too old. 'v4l2-ctl --help-streaming' gives the available options for doing streaming. So simple capturing from vivi is 'v4l2-ctl --stream-mmap' or '--stream-user'. You can't test dmabuf unless you switch to the vb2-part4 branch of my tree. If you need help with testing it's easiest to contact me on the #v4l irc channel. Regards, Hans

12 years, 4 months

Re: [Linaro-mm-sig] [RFC] Helper to abstract vma handling in media layer

by Hans Verkuil

On 04/10/14 12:32, Jan Kara wrote: > Hello, > > On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: >> On 2014-03-17 20:49, Jan Kara wrote: >>> The following patch series is my first stab at abstracting vma handling >> >from the various media drivers. After this patch set drivers have to know >>> much less details about vmas, their types, and locking. My motivation for >>> the series is that I want to change get_user_pages() locking and I want >>> to handle subtle locking details in as few places as possible. >>> >>> The core of the series is the new helper get_vaddr_pfns() which is given a >>> virtual address and it fills in PFNs into provided array. If PFNs correspond to >>> normal pages it also grabs references to these pages. The difference from >>> get_user_pages() is that this function can also deal with pfnmap, mixed, and io >>> mappings which is what the media drivers need. >>> >>> The patches are just compile tested (since I don't have any of the hardware >>> I'm afraid I won't be able to do any more testing anyway) so please handle >>> with care. I'm grateful for any comments. >> >> Thanks for posting this series! I will check if it works with our >> hardware soon. This is something I wanted to introduce some time ago to >> simplify buffer handling in dma-buf, but I had no time to start working. > Thanks for having a look in the series. > >> However I would like to go even further with integration of your pfn >> vector idea. This structure looks like a best solution for a compact >> representation of the memory buffer, which should be considered by the >> hardware as contiguous (either contiguous in physical memory or mapped >> contiguously into dma address space by the respective iommu). As you >> already noticed it is widely used by graphics and video drivers. >> >> I would also like to add support for pfn vector directly to the >> dma-mapping subsystem. This can be done quite easily (even with a >> fallback for architectures which don't provide method for it). I will try >> to prepare rfc soon. This will finally remove the need for hacks in >> media/v4l2-core/videobuf2-dma-contig.c > That would be a worthwhile thing to do. When I was reading the code this > seemed like something which could be done but I delibrately avoided doing > more unification than necessary for my purposes as I don't have any > hardware to test and don't know all the subtleties in the code... BTW, is > there some way to test the drivers without the physical video HW? You can use the vivi driver (drivers/media/platform/vivi) for this. However, while the vivi driver can import dma buffers it cannot export them. If you want that, then you have to use this tree: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vb2-part4 Regards, Hans

12 years, 4 months

Re: [Linaro-mm-sig] [RFC] Helper to abstract vma handling in media layer

by Marek Szyprowski

Hello, On 2014-03-17 20:49, Jan Kara wrote: > The following patch series is my first stab at abstracting vma handling > from the various media drivers. After this patch set drivers have to know > much less details about vmas, their types, and locking. My motivation for > the series is that I want to change get_user_pages() locking and I want > to handle subtle locking details in as few places as possible. > > The core of the series is the new helper get_vaddr_pfns() which is given a > virtual address and it fills in PFNs into provided array. If PFNs correspond to > normal pages it also grabs references to these pages. The difference from > get_user_pages() is that this function can also deal with pfnmap, mixed, and io > mappings which is what the media drivers need. > > The patches are just compile tested (since I don't have any of the hardware > I'm afraid I won't be able to do any more testing anyway) so please handle > with care. I'm grateful for any comments. Thanks for posting this series! I will check if it works with our hardware soon. This is something I wanted to introduce some time ago to simplify buffer handling in dma-buf, but I had no time to start working. However I would like to go even further with integration of your pfn vector idea. This structure looks like a best solution for a compact representation of the memory buffer, which should be considered by the hardware as contiguous (either contiguous in physical memory or mapped contiguously into dma address space by the respective iommu). As you already noticed it is widely used by graphics and video drivers. I would also like to add support for pfn vector directly to the dma-mapping subsystem. This can be done quite easily (even with a fallback for architectures which don't provide method for it). I will try to prepare rfc soon. This will finally remove the need for hacks in media/v4l2-core/videobuf2-dma-contig.c Thanks for motivating me to finally start working on this! Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

12 years, 4 months

Re: [Linaro-mm-sig] [PATCH 2/2] dma-buf: update exp_name when using dma_buf_export()

by Daniel Vetter

On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote: > commit c0b00a5 ("dma-buf: update debugfs output") modified the > default exporter name to be the KBUILD_MODNAME pre-processor > macro instead of __FILE__ but the documentation was not updated. > > Also the "Supporting existing mmap interfaces in exporters" section > title seems wrong since talks about the interface used by importers. > > Signed-off-by: Javier Martinez Canillas <javier.martinez(a)collabora.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> > --- > Documentation/dma-buf-sharing.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt > index 505e711..7d61cef 100644 > --- a/Documentation/dma-buf-sharing.txt > +++ b/Documentation/dma-buf-sharing.txt > @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following steps: > > Exporting modules which do not wish to provide any specific name may use the > helper define 'dma_buf_export()', with the same arguments as above, but > - without the last argument; a __FILE__ pre-processor directive will be > + without the last argument; a KBUILD_MODNAME pre-processor directive will be > inserted in place of 'exp_name' instead. > > 2. Userspace gets a handle to pass around to potential buffer-users > @@ -352,7 +352,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: > > No special interfaces, userspace simply calls mmap on the dma-buf fd. > > -2. Supporting existing mmap interfaces in exporters > +2. Supporting existing mmap interfaces in importers > > Similar to the motivation for kernel cpu access it is again important that > the userspace code of a given importing subsystem can use the same interfaces > -- > 1.9.0 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

12 years, 4 months

Performance issues with dmabuf

by kiran

Hi, I was looking at some code(given below) which seems to perform very badly when attachments and detachments to used to simulate cache coherency. In the code below, when remote_attach is false(ie no remote processors), using just the two A9 cores the following code runs in 8.8 seconds. But when remote_attach is true then even though there are other cores also executing and sharing the workload the following code takes 52.7 seconds. This shows that detach and attach is very heavy for this kind of code. (The system call detach performs dma_buf_unmap_attachment and dma_buf_detach, system call attach performs dma_buf_attach and dma_buf_map_attachment). for (k = 0; k < N; k++) { if(remote_attach) { detach(path) ; attach(path) ; } for(i = start_indx; i < end_indx; i++) { for (j = 0; j < N; j++) { if(path[i][j] < (path[i][k] + path[k][j])) { path[i][j] = path[i][k] + path[k][j] ; } } } } I would like to manage the cache explicitly and flush cache lines rather than pages to reduce overhead. I also want to access these buffers from the userspace. I can change some kernel code for this. Where should I start ? Thanks in advance. --Kiran

12 years, 4 months

[RFC] dma-buf: Implement test module

by Thierry Reding

This is a simple test module that can be used to allocate, export and delete DMA-BUF objects. It can be used to test DMA-BUF sharing in systems that lack a real second driver. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/base/Kconfig | 4 + drivers/base/Makefile | 1 + drivers/base/dma-buf-test.c | 308 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 313 insertions(+) create mode 100644 drivers/base/dma-buf-test.c diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index e373671652b0..bed2abb9491b 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -200,6 +200,10 @@ config DMA_SHARED_BUFFER APIs extension; the file's descriptor can then be passed on to other driver. +config DMA_BUF_TEST + tristate "DMA-BUF test module" + depends on DMA_SHARED_BUFFER + config DMA_CMA bool "DMA Contiguous Memory Allocator" depends on HAVE_DMA_CONTIGUOUS && CMA diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 94e8a80e87f8..cad983b6626f 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -25,3 +25,4 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG +obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o diff --git a/drivers/base/dma-buf-test.c b/drivers/base/dma-buf-test.c new file mode 100644 index 000000000000..f5498b74a09b --- /dev/null +++ b/drivers/base/dma-buf-test.c @@ -0,0 +1,308 @@ +#include <linux/dma-buf.h> +#include <linux/err.h> +#include <linux/fs.h> +#include <linux/miscdevice.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/uaccess.h> + +struct dmabuf_create { + __u32 flags; + __u32 size; +}; + +#define DMABUF_IOCTL_BASE 'D' +#define DMABUF_IOCTL_CREATE _IOWR(DMABUF_IOCTL_BASE, 0, struct dmabuf_create) +#define DMABUF_IOCTL_DELETE _IOWR(DMABUF_IOCTL_BASE, 1, int) +#define DMABUF_IOCTL_EXPORT _IOWR(DMABUF_IOCTL_BASE, 2, int) + +struct dmabuf_file { + struct dma_buf *buf; + dma_addr_t phys; + size_t size; + void *virt; +}; + +static int dmabuf_attach(struct dma_buf *buf, struct device *dev, + struct dma_buf_attachment *attach) +{ + return 0; +} + +static void dmabuf_detach(struct dma_buf *buf, + struct dma_buf_attachment *attach) +{ +} + +static struct sg_table *dmabuf_map_dma_buf(struct dma_buf_attachment *attach, + enum dma_data_direction dir) +{ + struct dmabuf_file *priv = attach->dmabuf->priv; + struct sg_table *sgt; + + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL); + if (!sgt) + return NULL; + + if (sg_alloc_table(sgt, 1, GFP_KERNEL)) { + kfree(sgt); + return NULL; + } + + sg_dma_address(sgt->sgl) = priv->phys; + sg_dma_len(sgt->sgl) = priv->size; + + return sgt; +} + +static void dmabuf_unmap_dma_buf(struct dma_buf_attachment *attach, + struct sg_table *sgt, + enum dma_data_direction dir) +{ + sg_free_table(sgt); + kfree(sgt); +} + +static void dmabuf_release(struct dma_buf *buf) +{ +} + +static int dmabuf_begin_cpu_access(struct dma_buf *buf, size_t size, + size_t length, + enum dma_data_direction direction) +{ + return 0; +} + +static void dmabuf_end_cpu_access(struct dma_buf *buf, size_t size, + size_t length, + enum dma_data_direction direction) +{ +} + +static void *dmabuf_kmap_atomic(struct dma_buf *buf, unsigned long page) +{ + return NULL; +} + +static void dmabuf_kunmap_atomic(struct dma_buf *buf, unsigned long page, + void *vaddr) +{ +} + +static void *dmabuf_kmap(struct dma_buf *buf, unsigned long page) +{ + return NULL; +} + +static void dmabuf_kunmap(struct dma_buf *buf, unsigned long page, void *vaddr) +{ +} + +static void dmabuf_vm_open(struct vm_area_struct *vma) +{ +} + +static void dmabuf_vm_close(struct vm_area_struct *vma) +{ +} + +static int dmabuf_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) +{ + return 0; +} + +static const struct vm_operations_struct dmabuf_vm_ops = { + .open = dmabuf_vm_open, + .close = dmabuf_vm_close, + .fault = dmabuf_vm_fault, +}; + +static int dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma) +{ + pgprot_t prot = vm_get_page_prot(vma->vm_flags); + struct dmabuf_file *priv = buf->priv; + + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_ops = &dmabuf_vm_ops; + vma->vm_private_data = priv; + vma->vm_page_prot = pgprot_writecombine(prot); + + return remap_pfn_range(vma, vma->vm_start, priv->phys >> PAGE_SHIFT, + vma->vm_end - vma->vm_start, vma->vm_page_prot); +} + +static void *dmabuf_vmap(struct dma_buf *buf) +{ + return NULL; +} + +static void dmabuf_vunmap(struct dma_buf *buf, void *vaddr) +{ +} + +static const struct dma_buf_ops dmabuf_ops = { + .attach = dmabuf_attach, + .detach = dmabuf_detach, + .map_dma_buf = dmabuf_map_dma_buf, + .unmap_dma_buf = dmabuf_unmap_dma_buf, + .release = dmabuf_release, + .begin_cpu_access = dmabuf_begin_cpu_access, + .end_cpu_access = dmabuf_end_cpu_access, + .kmap_atomic = dmabuf_kmap_atomic, + .kunmap_atomic = dmabuf_kunmap_atomic, + .kmap = dmabuf_kmap, + .kunmap = dmabuf_kunmap, + .mmap = dmabuf_mmap, + .vmap = dmabuf_vmap, + .vunmap = dmabuf_vunmap, +}; + +static int dmabuf_file_open(struct inode *inode, struct file *file) +{ + struct dmabuf_file *priv; + int ret = 0; + + priv = kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + file->private_data = priv; + + return ret; +} + +static int dmabuf_file_release(struct inode *inode, struct file *file) +{ + struct dmabuf_file *priv = file->private_data; + int ret = 0; + + if (priv->virt) + dma_free_writecombine(NULL, priv->size, priv->virt, priv->phys); + + if (priv->buf) + dma_buf_put(priv->buf); + + kfree(priv); + + return ret; +} + +static int dmabuf_ioctl_create(struct dmabuf_file *priv, const void __user *data) +{ + struct dmabuf_create args; + int ret = 0; + + if (priv->buf || priv->virt) + return -EBUSY; + + if (copy_from_user(&args, data, sizeof(args))) + return -EFAULT; + + priv->virt = dma_alloc_writecombine(NULL, args.size, &priv->phys, + GFP_KERNEL | __GFP_NOWARN); + if (!priv->virt) + return -ENOMEM; + + priv->buf = dma_buf_export(priv, &dmabuf_ops, args.size, args.flags); + if (!priv->buf) { + ret = -ENOMEM; + goto free; + } + + if (IS_ERR(priv->buf)) { + ret = PTR_ERR(priv->buf); + goto free; + } + + priv->size = args.size; + + return 0; + +free: + dma_free_writecombine(NULL, priv->size, priv->virt, priv->phys); + priv->virt = NULL; + return ret; +} + +static int dmabuf_ioctl_delete(struct dmabuf_file *priv, unsigned long flags) +{ + dma_free_writecombine(NULL, priv->size, priv->virt, priv->phys); + priv->virt = NULL; + priv->phys = 0; + priv->size = 0; + + dma_buf_put(priv->buf); + priv->buf = NULL; + + return 0; +} + +static int dmabuf_ioctl_export(struct dmabuf_file *priv, unsigned long flags) +{ + int err; + + get_dma_buf(priv->buf); + + err = dma_buf_fd(priv->buf, flags); + if (err < 0) + dma_buf_put(priv->buf); + + return err; +} + +static long dmabuf_file_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) +{ + struct dmabuf_file *priv = file->private_data; + long ret = 0; + + switch (cmd) { + case DMABUF_IOCTL_CREATE: + ret = dmabuf_ioctl_create(priv, (const void __user *)arg); + break; + + case DMABUF_IOCTL_DELETE: + ret = dmabuf_ioctl_delete(priv, arg); + break; + + case DMABUF_IOCTL_EXPORT: + ret = dmabuf_ioctl_export(priv, arg); + break; + + default: + ret = -ENOTTY; + break; + } + + return ret; +} + +static const struct file_operations dmabuf_fops = { + .owner = THIS_MODULE, + .open = dmabuf_file_open, + .release = dmabuf_file_release, + .unlocked_ioctl = dmabuf_file_ioctl, +}; + +static struct miscdevice dmabuf_device = { + .minor = 128, + .name = "dmabuf", + .fops = &dmabuf_fops, +}; + +static int __init dmabuf_init(void) +{ + return misc_register(&dmabuf_device); +} +module_init(dmabuf_init); + +static void __exit dmabuf_exit(void) +{ + misc_deregister(&dmabuf_device); +} +module_exit(dmabuf_exit); + +MODULE_AUTHOR("Thierry Reding <treding(a)nvidia.com>"); +MODULE_DESCRIPTION("DMA-BUF test driver"); +MODULE_LICENSE("GPL v2"); -- 1.8.4.2

12 years, 4 months

[PATCH] dma-buf: add meta data attachment

by Bin Wang

we found there'd be varied specific data connected to a dmabuf, like the iommu mapping of buffer, the dma descriptors (that can be shared between several components). Though these info might be able to be generated every time before dma operations, for performance sake, it's better to be kept before really invalid. Change-Id: I89d43dc3fe1ee3da91c42074da5df71b968e6d3c Signed-off-by: Bin Wang <binw(a)marvell.com> --- drivers/base/dma-buf.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 22 ++++++++++ 2 files changed, 122 insertions(+), 0 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 08fe897..5c82e60 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -50,6 +50,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) BUG_ON(dmabuf->vmapping_counter); + dma_buf_meta_release(dmabuf); dmabuf->ops->release(dmabuf); mutex_lock(&db_list.lock); @@ -138,6 +139,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); + INIT_LIST_HEAD(&dmabuf->metas); mutex_lock(&db_list.lock); list_add(&dmabuf->list_node, &db_list.head); @@ -570,6 +572,104 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) } EXPORT_SYMBOL_GPL(dma_buf_vunmap); +/** + * dma_buf_meta_attach - Attach additional meta data to the dmabuf + * @dmabuf: [in] the dmabuf to attach to + * @id: [in] the id of the meta data + * @pdata: [in] the raw data to be attached + * @release: [in] the callback to release the meta data + */ +int dma_buf_meta_attach(struct dma_buf *dmabuf, int id, void *pdata, + int (*release)(void *)) +{ + struct dma_buf_meta *pmeta; + + pmeta = kmalloc(sizeof(struct dma_buf_meta), GFP_KERNEL); + if (pmeta == NULL) + return -ENOMEM; + + pmeta->id = id; + pmeta->pdata = pdata; + pmeta->release = release; + + mutex_lock(&dmabuf->lock); + list_add(&pmeta->node, &dmabuf->metas); + mutex_unlock(&dmabuf->lock); + + return 0; +} +EXPORT_SYMBOL_GPL(dma_buf_meta_attach); + +/** + * dma_buf_meta_dettach - Dettach the meta data from dmabuf by id + * @dmabuf: [in] the dmabuf including the meta data + * @id: [in] the id of the meta data + */ +int dma_buf_meta_dettach(struct dma_buf *dmabuf, int id) +{ + struct dma_buf_meta *pmeta, *tmp; + int ret = -ENOENT; + + mutex_lock(&dmabuf->lock); + list_for_each_entry_safe(pmeta, tmp, &dmabuf->metas, node) { + if (pmeta->id == id) { + if (pmeta->release) + pmeta->release(pmeta->pdata); + list_del(&pmeta->node); + kfree(pmeta); + ret = 0; + break; + } + } + mutex_unlock(&dmabuf->lock); + + return ret; +} +EXPORT_SYMBOL_GPL(dma_buf_meta_dettach); + +/** + * dma_buf_meta_fetch - Get the meta data from dmabuf by id + * @dmabuf: [in] the dmabuf including the meta data + * @id: [in] the id of the meta data + */ +void *dma_buf_meta_fetch(struct dma_buf *dmabuf, int id) +{ + struct dma_buf_meta *pmeta; + void *pdata = NULL; + + mutex_lock(&dmabuf->lock); + list_for_each_entry(pmeta, &dmabuf->metas, node) { + if (pmeta->id == id) { + pdata = pmeta->pdata; + break; + } + } + mutex_unlock(&dmabuf->lock); + + return pdata; +} +EXPORT_SYMBOL_GPL(dma_buf_meta_fetch); + +/** + * dma_buf_meta_release - Release all the meta data attached to the dmabuf + * @dmabuf: [in] the dmabuf including the meta data + */ +void dma_buf_meta_release(struct dma_buf *dmabuf) +{ + struct dma_buf_meta *pmeta, *tmp; + + mutex_lock(&dmabuf->lock); + list_for_each_entry_safe(pmeta, tmp, &dmabuf->metas, node) { + if (pmeta->release) + pmeta->release(pmeta->pdata); + list_del(&pmeta->node); + kfree(pmeta); + } + mutex_unlock(&dmabuf->lock); + + return; +} + #ifdef CONFIG_DEBUG_FS static int dma_buf_describe(struct seq_file *s) { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index dfac5ed..369d032 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -120,6 +120,7 @@ struct dma_buf { size_t size; struct file *file; struct list_head attachments; + struct list_head metas; const struct dma_buf_ops *ops; /* mutex to serialize list manipulation, attach/detach and vmap/unmap */ struct mutex lock; @@ -149,6 +150,20 @@ struct dma_buf_attachment { }; /** + * struct dma_buf_meta - holds varied meta data attached to the buffer + * @id: the identification of the meta data + * @dmabuf: buffer for this attachment. + * @node: list of dma_buf_meta. + * @pdata: specific meta data. + */ +struct dma_buf_meta { + int id; + struct list_head node; + int (*release)(void *pdata); + void *pdata; +}; + +/** * get_dma_buf - convenience wrapper for get_file. * @dmabuf: [in] pointer to dma_buf * @@ -194,6 +209,13 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); + +int dma_buf_meta_attach(struct dma_buf *dmabuf, int id, void *pdata, + int (*release)(void *)); +int dma_buf_meta_dettach(struct dma_buf *dmabuf, int id); +void *dma_buf_meta_fetch(struct dma_buf *dmabuf, int id); +void dma_buf_meta_release(struct dma_buf *dmabuf); + int dma_buf_debugfs_create_file(const char *name, int (*write)(struct seq_file *)); #endif /* __DMA_BUF_H__ */ -- 1.7.0.4

12 years, 4 months

Re: [Linaro-mm-sig] [PATCH v5 09/11] arm: add support for reserved memory defined by device tree

by Grant Likely

On Thu, 13 Mar 2014 14:51:56 -0700, Kevin Hilman <khilman(a)linaro.org> wrote: > Josh Cartwright <joshc(a)codeaurora.org> writes: > > > On Thu, Mar 13, 2014 at 01:46:50PM -0700, Kevin Hilman wrote: > >> On Fri, Feb 21, 2014 at 4:25 AM, Marek Szyprowski > >> <m.szyprowski(a)samsung.com> wrote: > >> > Enable reserved memory initialization from device tree. > >> > > >> > Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> > >> > >> This patch has hit -next and several legacy (non-DT) boot failures > >> were detected and bisected down to this patch. A quick scan looks > >> like there needs to be some sanity checking whether a DT is even > >> present. > > > > Hmm. Yes, the code unconditionally calls of_flat_dt_scan(), which will > > gladly touch initial_boot_params, even though it may be uninitialized. > > The below patch should allow these boards to boot... > > > > However, I'm wondering if there is a good reason why we don't parse the > > /reserved-memory nodes at the right after we parse the /memory nodes as > > part of early_init_dt_scan()... > > > > Thanks, > > Josh > > > > --8<-- > > Subject: [PATCH] drivers: of: only scan for reserved mem when fdt present > > > > Reported-by: Kevin Hilman <khilman(a)linaro.org> > > Signed-off-by: Josh Cartwright <joshc(a)codeaurora.org> > > This gets legacy boot working again. Thanks. > > Tested-by: Kevin Hilman <khilman(a)linaro.org> Applied and confirmed on non-DT qemu boot. Thanks. It will be pushed out shortly. g.

12 years, 4 months

[RFC][PATCH 1/1] ion: support multiple address space map

by Hiroshi Doyu

Hi, Our H/Ws(inc. GPU) can accept a dmabuf fd which is originally allocated via ION. GPU tries to map this buffer into GPU address space via ION dmabuf backend(.map_dma_buf). Our Tegra IOMMU supports multiple address space in IOMMU. Basically each device has its own address space assigned by IOMMU. Usually DMA API hides the existance of IOMMU from driver code. To support this multiple IOMMU address space, I think that at least "ion_map_dma_buf" needs to create IOMMU mapping *per* device(address space). And I made the following patch *experimentally*. Is this the right solution to solve this multiple IOMMU address space? Any comment would be really appreciated. ---8<------8<------8<------8<------8<------8<------8<------8<--- From: Hiroshi Doyu <hdoyu(a)nvidia.com> Ion doesn't support multiple address space. The recent IOMMU usually provide multiple address spaces, where a mapping depends on an address space. An address space is bind to a device pointer passed from attachment. Those info needs to be stored in a buffer info. If the same buffer needs to be mapped into the same AS, the same mapping info needs to be passed back. Signed-off-by: Hiroshi Doyu <hdoyu(a)nvidia.com> --- drivers/staging/android/ion/ion.c | 96 +++++++++++++++++++++++++++++++++- drivers/staging/android/ion/ion_priv.h | 10 ++++ 2 files changed, 104 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 0836717..e260434 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -872,17 +872,109 @@ static void ion_buffer_sync_for_device(struct ion_buffer *buffer, static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction) { + int err, i, empty = -1; + struct dma_iommu_mapping *iommu_map; struct dma_buf *dmabuf = attachment->dmabuf; struct ion_buffer *buffer = dmabuf->priv; + unsigned int nents = buffer->sg_table->nents; + struct ion_mapping *map_ptr; + struct scatterlist *sg; + + iommu_map = to_dma_iommu_mapping(attachment->dev); + if (!iommu_map) { + ion_buffer_sync_for_device(buffer, attachment->dev, direction); + return buffer->sg_table; + } + + mutex_lock(&buffer->lock); + for (i = 0; i < ARRAY_SIZE(buffer->mapping); i++) { + map_ptr = &buffer->mapping[i]; + if (!map_ptr->dev) { + empty = i; + continue; + } + + if (to_dma_iommu_mapping(map_ptr->dev) == iommu_map) { + kref_get(&map_ptr->kref); + mutex_unlock(&buffer->lock); + return &map_ptr->sgt; + } + } - ion_buffer_sync_for_device(buffer, attachment->dev, direction); - return buffer->sg_table; + if (!empty) { + err = -ENOMEM; + goto err_no_space; + } + + map_ptr = &buffer->mapping[empty]; + err = sg_alloc_table(&map_ptr->sgt, nents, GFP_KERNEL); + if (err) + goto err_sg_alloc_table; + + for_each_sg(buffer->sg_table->sgl, sg, nents, i) + memcpy(map_ptr->sgt.sgl + i, sg, sizeof(*sg)); + + nents = dma_map_sg(attachment->dev, map_ptr->sgt.sgl, nents, direction); + if (!nents) { + err = -EINVAL; + goto err_dma_map_sg; + } + + kref_init(&map_ptr->kref); + map_ptr->dev = attachment->dev; + mutex_unlock(&buffer->lock); + return &map_ptr->sgt; + +err_dma_map_sg: + sg_free_table(&map_ptr->sgt); +err_sg_alloc_table: +err_no_space: + mutex_unlock(&buffer->lock); + return ERR_PTR(err); +} + +static void __ion_unmap_dma_buf(struct kref *kref) +{ + struct ion_mapping *map_ptr; + + map_ptr = container_of(kref, struct ion_mapping, kref); + dma_unmap_sg(map_ptr->dev, map_ptr->sgt.sgl, map_ptr->sgt.nents, + DMA_BIDIRECTIONAL); + sg_free_table(&map_ptr->sgt); + memset(map_ptr, 0, sizeof(*map_ptr)); } static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *table, enum dma_data_direction direction) { + int i; + struct dma_iommu_mapping *iommu_map; + struct dma_buf *dmabuf = attachment->dmabuf; + struct ion_buffer *buffer = dmabuf->priv; + struct ion_mapping *map_ptr; + + iommu_map = to_dma_iommu_mapping(attachment->dev); + if (!iommu_map) + return; + + mutex_lock(&buffer->lock); + for (i = 0; i < ARRAY_SIZE(buffer->mapping); i++) { + map_ptr = &buffer->mapping[i]; + if (!map_ptr->dev) + continue; + + if (to_dma_iommu_mapping(map_ptr->dev) == iommu_map) { + kref_put(&map_ptr->kref, __ion_unmap_dma_buf); + mutex_unlock(&buffer->lock); + return; + } + } + + dev_warn(attachment->dev, "Not found a map(%p)\n", + to_dma_iommu_mapping(attachment->dev)); + + mutex_unlock(&buffer->lock); } void ion_pages_sync_for_device(struct device *dev, struct page *page, diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h index 1eba3f2..441c251 100644 --- a/drivers/staging/android/ion/ion_priv.h +++ b/drivers/staging/android/ion/ion_priv.h @@ -26,11 +26,19 @@ #include <linux/sched.h> #include <linux/shrinker.h> #include <linux/types.h> +#include <linux/scatterlist.h> #include "ion.h" struct ion_buffer *ion_handle_buffer(struct ion_handle *handle); +struct ion_mapping { + struct device *dev; /* to get a map and dma_ops */ + struct sg_table sgt; + struct kref kref; +}; +#define NUM_ION_MAPPING 5 /* FIXME: dynamically allocate more than this */ + /** * struct ion_buffer - metadata for a particular buffer * @ref: refernce count @@ -84,6 +92,8 @@ struct ion_buffer { int handle_count; char task_comm[TASK_COMM_LEN]; pid_t pid; + + struct ion_mapping mapping[NUM_ION_MAPPING]; }; void ion_buffer_destroy(struct ion_buffer *buffer); -- 1.8.1.5

12 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig