Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
2911 discussions

[patch 1/2 -next] dma-buf: double unlock in debugfs code

by Dan Carpenter

We unlock here when we failed to take the lock. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- This is in linux-next, and I think the debugfs code is only in Sumit's tree. diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 466476f..174cd2c 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -593,7 +593,7 @@ static int dma_buf_describe(struct seq_file *s) if (ret) { seq_printf(s, "\tERROR locking buffer object: skipping\n"); - goto skip_buffer; + continue; } seq_printf(s, "\t"); @@ -618,7 +618,6 @@ static int dma_buf_describe(struct seq_file *s) count++; size += buf_obj->size; -skip_buffer: mutex_unlock(&buf_obj->lock); }

12 years, 2 months

Re: [Linaro-mm-sig] Status of exporting an fbdev framebuffer with dma_buf?

by Laurent Pinchart

Hi Tom, On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote: > Hi All, > > Last year Laurent posted an RFC patch[i] to add support for exporting an > fbdev framebuffer through dma_buf. Looking through the mailing list > archives, it doesn't appear to have progressed beyond an RFC? What would be > needed to get this merged? It would be useful for our Mali T6xx driver > (which supports importing dma_buf buffers) to allow the GPU to draw > directly into the framebuffer on platforms which lack a DRM/KMS driver. The patch was pretty simple, I don't think it would take lots of efforts to get it to mainline. On the other hand, fbdev is a dying API, so I'm not sure how much energy we want to spend on upgrading it. I suppose all that would be needed is a developer with enough interest in the topic to fix the patch according to the comments. > [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012. -- Regards, Laurent Pinchart

12 years, 2 months

Status of exporting an fbdev framebuffer with dma_buf?

by Tom Cooksey

Hi All, Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev framebuffer through dma_buf. Looking through the mailing list archives, it doesn't appear to have progressed beyond an RFC? What would be needed to get this merged? It would be useful for our Mali T6xx driver (which supports importing dma_buf buffers) to allow the GPU to draw directly into the framebuffer on platforms which lack a DRM/KMS driver. [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012. Cheers, Tom

12 years, 2 months

[PATCH v3 0/2] dma-buf: Add support for debugfs

by Sumit Semwal

The patch series adds a much-missed support for debugfs to dma-buf framework. Based on the feedback received on v1 of this patch series, support is also added to allow exporters to provide name-strings that will prove useful while debugging. Some more magic can be added for more advanced debugging, but we'll leave that for the time being. Best regards, ~Sumit. --- changes since v2: (based on review comments from Laurent Pinchart) - reordered functions to avoid forward declaration - added __exitcall for dma_buf_deinit() changes since v1: - added patch to replace dma_buf_export() with dma_buf_export_named(), per suggestion from Daniel Vetter. - fixes on init and warnings as reported and corrected by Dave Airlie. - added locking while walking attachment list - reported by Daniel Vetter. Sumit Semwal (2): dma-buf: replace dma_buf_export() with dma_buf_export_named() dma-buf: Add debugfs support Documentation/dma-buf-sharing.txt | 13 ++- drivers/base/dma-buf.c | 170 ++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 16 +++- 3 files changed, 190 insertions(+), 9 deletions(-) -- 1.7.10.4

12 years, 2 months

[PATCH v2 0/2] dma-buf: Add support for debugfs

by Sumit Semwal

12 years, 3 months

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

by Benjamin Gaignard

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 10: - stop adding private field in ion_heap structure - put ion_heap into struct ion_cma_heap patches version 9: - rebased on Android kernel - make cma heap able to support ION_FLAG_CACHED flag patches version 8: - fix memory leak when release sg_table - remove virt_to_phys from ion_cma_phys patches version 7: - rebased on Android kernel - fix ion Makefile - add ion_cma_map_kernel function - remove CONFIG_CMA compilation flags from ion_heap.c patches version 6: - add private field in ion_platform_heap to pass the device linked with CMA. - rework CMA heap to use private field. - prepare CMA heap for incoming dma_common_get_sgtable function http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html - simplify ion-ux500 driver. patches version 5: - port patches on android kernel 3.4 where ION use dmabuf - add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions patches version 4: - add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum. - CMA heap is now a "native" ION heap. - add ion_heap_create_full function to keep backward compatibilty. - clean up included files in CMA heap - ux500-ion is using ion_heap_create_full instead of ion_heap_create 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 (2): gpu: ion: fix ion_platform_data definition gpu: ion: add CMA heap drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/ion_cma_heap.c | 234 ++++++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion_heap.c | 6 ++ drivers/gpu/ion/ion_priv.h | 14 +++ include/linux/ion.h | 5 +- 5 files changed, 259 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/ion/ion_cma_heap.c -- 1.7.10

12 years, 3 months

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

by Benjamin Gaignard

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 9: - rebased on Android kernel - make cma heap able to support ION_FLAG_CACHED flag patches version 8: - fix memory leak when release sg_table - remove virt_to_phys from ion_cma_phys patches version 7: - rebased on Android kernel - fix ion Makefile - add ion_cma_map_kernel function - remove CONFIG_CMA compilation flags from ion_heap.c patches version 6: - add private field in ion_platform_heap to pass the device linked with CMA. - rework CMA heap to use private field. - prepare CMA heap for incoming dma_common_get_sgtable function http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html - simplify ion-ux500 driver. patches version 5: - port patches on android kernel 3.4 where ION use dmabuf - add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions patches version 4: - add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum. - CMA heap is now a "native" ION heap. - add ion_heap_create_full function to keep backward compatibilty. - clean up included files in CMA heap - ux500-ion is using ion_heap_create_full instead of ion_heap_create 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 (3): gpu: ion: fix ion_platform_data definition gpu: ion: add private field in ion_heap and ion_platform_heap structure gpu: ion: add CMA heap drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/ion_cma_heap.c | 221 ++++++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion_heap.c | 7 ++ drivers/gpu/ion/ion_priv.h | 16 +++ include/linux/ion.h | 5 +- 5 files changed, 249 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/ion/ion_cma_heap.c -- 1.7.10

12 years, 3 months

[PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)

by Marek Szyprowski

Hello, Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. Contiguous Memory Allocator is a framework, which lets to provide a large contiguous memory buffers for (usually a multimedia) devices. The contiguous memory is reserved during early boot and then shared with kernel, which is allowed to allocate it for movable pages. Then, when device driver requests a contigouous buffer, the framework migrates movable pages out of contiguous region and gives it to the driver. When device driver frees the buffer, it is added to kernel memory pool again. For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57 ("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895 (CMA merge commit). Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Marek Szyprowski (2): drivers: dma-contiguous: clean source code and prepare for device tree drivers: dma-contiguous: add initialization from device tree Documentation/devicetree/bindings/memory.txt | 101 ++++++++++ arch/arm/boot/dts/skeleton.dtsi | 7 +- drivers/base/dma-contiguous.c | 278 +++++++++++++++++++------- include/asm-generic/dma-contiguous.h | 4 +- include/linux/dma-contiguous.h | 32 ++- 5 files changed, 338 insertions(+), 84 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory.txt -- 1.7.9.5

12 years, 3 months

lists.linaro.org maintenance completed

by IT Services

This is to let you know that the migration of lists.linaro.org has been successfully completed. As per the email I sent on Wednesday, it may take some time for the new address of the server to be seen by your computer. You can check this by trying to connect to the web site: http://lists.linaro.org/ If you are able to connect and you do not get an error, this means you are connecting to the new server and you can send email to the lists. If you experience any problems after the weekend and you find that you still cannot connect to the server, please reply to this email to let us know. Regards Philip IT Services Manager Linaro

12 years, 3 months

Planned maintenance - lists.linaro.org

by IT Services

Hello You are receiving this email because you are subscribed to one or more mailing lists provided by the lists.linaro.org server. IT Services are announcing planned maintenance for this server scheduled for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work is to move the service to another server. There will be some disruption during this maintenance. In order to ensure that you do not accidentally try to use the service while it is being moved, the current server will be shut down at 2pm. A further email will be sent on Friday afternoon to confirm that the migration of the service is completed. However, due to the way servers are found, it may take a while before your computer is able to connect to the relocated service. After the old server has been shut down, email sent to any of the lists will be queued, but it is possible that the sending server will still trying to deliver the email to the old server rather than the new one when it is started. It is therefore *strongly* recommended that you do not send any email to an @lists.linaro.org email address until you can connect to the new service, which you will be able to test by trying to use a web browser to connect to http://lists.linaro.org after you receive the email confirming that the migration has been completed. Since the old service will be shut down, if you are able to connect, you can be sure you have connected to the new service. If by Monday you are still unable to connect to the service or you are not able to send email to an @lists.linaro.org email address, please send an email to its(a)linaro.org. Thank you. Regards Philip IT Services Manager Linaro

12 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig