Linaro-mm-sig September 2013

linaro-mm-sig@lists.linaro.org

15 participants
8 discussions

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

by Marek Szyprowski

Hello, I thought that v6 series is really ready for merging, but I found today a stupid bug which broke compilation when CONFIG_CMA was not enabled, so another respin is needed. I've also took the opportunity and fixed some minor issues in the documentation (renamed all nodes to 'region') and rebased the patches onto Aneesh Kumar K.V patch queued earlier for merging. For more information, please refer to the V6 patches thread: http://thread.gmane.org/gmane.linux.ports.arm.kernel/261518 Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v7: - fixed compilation break when CMA support has been disabled - rebased onto Aneesh Kumar K.V CMA patches queued earlier for merging - more cleanups in the binding documentation (thanks to Stephen Warren) v6: http://thread.gmane.org/gmane.linux.ports.arm.kernel/261518 - added support for 'status' property, so memory regions can be disabled like any other nodes - fixed issues pointed by Rob: removed annotations from function declarations and replaced macros with static inline functions. - restored of_scan_flat_dt_by_path() function to simplify reserved memory scanning function - the code now uses #size-cells/#address-cells properties from root node for interpreting 'reg' property in reserved memory regions - fixed some issues in dt binding documentation v5: http://thread.gmane.org/gmane.linux.ports.arm.kernel/259278 - renamed "contiguous-memory-region" compatibility string to "linux,contiguous-memory-region" (this one is really specific to Linux kernel implementation) - renamed "dma-memory-region" property to "memory-region" (suggested by Kumar Gala) - added support for #address-cells, #size-cells for memory regions (thanks to Rob Herring for suggestion) - removed generic code to scan specific path in flat device tree (cannot be used to fdt one-pass scan based initialization of memory regions with #address-cells and #size-cells parsing) - replaced dma_contiguous_set_default_area() and dma_contiguous_add_device() functions with dev_set_cma_area() call v4: http://thread.gmane.org/gmane.linux.ports.arm.kernel/256491 - corrected Devcie Tree mailing list address (resend) - moved back contiguous-memory bindings from /chosen/contiguous-memory to /memory nodes as suggested by Grant (see http://article.gmane.org/gmane.linux.drivers.devicetree/41030 for more details) - added support for DMA reserved memory with dma_declare_coherent() - moved code to drivers/of/of_reserved_mem.c - added generic code to scan specific path in flat device tree v3: http://thread.gmane.org/gmane.linux.drivers.devicetree/40013/ - fixed issues pointed by Laura and updated documentation v2: http://thread.gmane.org/gmane.linux.drivers.devicetree/34075 - moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/ node to avoid spreading Linux specific parameters over the whole device tree definitions - added support for autoconfigured regions (use zero base) - fixes minor bugs v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/ - initial proposal Patch summary: Marek Szyprowski (4): drivers: dma-contiguous: clean source code and prepare for device tree drivers: of: add function to scan fdt nodes given by path drivers: of: add initialization code for dma reserved memory ARM: init: add support for reserved memory defined by device tree Documentation/devicetree/bindings/memory.txt | 168 +++++++++++++++++++++++++ arch/arm/include/asm/dma-contiguous.h | 1 - arch/arm/mm/init.c | 3 + arch/x86/include/asm/dma-contiguous.h | 1 - drivers/base/dma-contiguous.c | 119 +++++++----------- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/fdt.c | 76 +++++++++++ drivers/of/of_reserved_mem.c | 175 ++++++++++++++++++++++++++ drivers/of/platform.c | 4 + include/asm-generic/dma-contiguous.h | 28 ----- include/linux/device.h | 2 +- include/linux/dma-contiguous.h | 62 ++++++++- include/linux/of_fdt.h | 3 + include/linux/of_reserved_mem.h | 14 +++ 15 files changed, 555 insertions(+), 108 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory.txt create mode 100644 drivers/of/of_reserved_mem.c delete mode 100644 include/asm-generic/dma-contiguous.h create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 2 months

[PATCH] gpu: ion: fix missing unmap_kernel function in CMA heap

by Benjamin Gaignard

After calling dma_alloc_coherent memory is mapped in kernel space. CMA heap doesn't map/unmap so only create a function to avoid segfault when ion call it without check it. Add a check at heap creation to be sure that unmap_kernel ops is implemented. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/ion/ion.c | 2 +- drivers/gpu/ion/ion_cma_heap.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c index 71b650e..5dd0ea2 100644 --- a/drivers/gpu/ion/ion.c +++ b/drivers/gpu/ion/ion.c @@ -1390,7 +1390,7 @@ DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get, void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap) { if (!heap->ops->allocate || !heap->ops->free || !heap->ops->map_dma || - !heap->ops->unmap_dma) + !heap->ops->unmap_dma || !heap->ops->unmap_kernel) pr_err("%s: can not add heap with invalid ops struct.\n", __func__); diff --git a/drivers/gpu/ion/ion_cma_heap.c b/drivers/gpu/ion/ion_cma_heap.c index 1eaa8c1..b98dcc4a 100644 --- a/drivers/gpu/ion/ion_cma_heap.c +++ b/drivers/gpu/ion/ion_cma_heap.c @@ -170,6 +170,12 @@ void *ion_cma_map_kernel(struct ion_heap *heap, struct ion_buffer *buffer) return info->cpu_addr; } +void ion_cma_unmap_kernel(struct ion_heap *heap, struct ion_buffer *buffer) +{ + /* do nothing because we keep the mapping*/ + return; +} + static struct ion_heap_ops ion_cma_ops = { .allocate = ion_cma_allocate, .free = ion_cma_free, @@ -178,6 +184,7 @@ static struct ion_heap_ops ion_cma_ops = { .phys = ion_cma_phys, .map_user = ion_cma_mmap, .map_kernel = ion_cma_map_kernel, + .unmap_kernel = ion_cma_unmap_kernel, }; struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data) -- 1.7.9.5

11 years, 3 months

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

by Marek Szyprowski

Hello, This is a third version of my proposal for device tree integration for Contiguous Memory Allocator. Over 2 month has passed from the time I've posted the second version, but now some things about using /chosen device tree node has been clarified, so I expect to get this code merged soon this time. Just a few words for those who see this code for the first time: 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). Why we need device tree bindings for CMA at all? Older ARM kernels used so called board-based initialization. Those board files contained a definition of all hardware blocks available on the target system and particular kernel and driver software configuration selected by the board maintainer. In the new approach the board files will be removed completely and Device Tree approach is used to describe all hardware blocks available on the target system. By definition, the bindings should be software independent, so at least in theory it should be possible to use those bindings with other operating systems than Linux kernel. However we also need to pass somehow the information about kernel and device driver software-only configuration data, which were earlier encoded in the board file. For such data I decided to use /chosen node, where kernel command line has been already stored. Future bootloaders will allow to modify or replace particular nodes and one will be able to use custom /chosen node to configure his system. The proposed patches introduce /chosen/contiguous-memory node and related bindings, to avoid complicated encoding of CMA related configuration to kernel command line. Some rationale for using /chosen/ node for kernel configuration entities has been already suggested by Grant Likely in the following thread: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/155296/focus=34363 Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v3: - fixed issues pointed by Laura and updated documentation v2: http://thread.gmane.org/gmane.linux.drivers.devicetree/34075 - moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/ node to avoid spreading Linux specific parameters over the whole device tree definitions - added support for autoconfigured regions (use zero base) - fixes minor bugs v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/ - initial proposal Patch summary: Marek Szyprowski (2): drivers: dma-contiguous: clean source code and prepare for device tree drivers: dma-contiguous: add initialization from device tree .../devicetree/bindings/contiguous-memory.txt | 94 ++++++ arch/arm/boot/dts/skeleton.dtsi | 7 +- drivers/base/dma-contiguous.c | 325 +++++++++++++------- include/asm-generic/dma-contiguous.h | 2 - include/linux/dma-contiguous.h | 32 +- 5 files changed, 352 insertions(+), 108 deletions(-) create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt -- 1.7.9.5

11 years, 3 months

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

by Daniel Stone

Hi, On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote: > > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey <tom.cooksey(a)arm.com> > > >> wrote: > > that was part of the reason to punt this problem to userspace ;-) > > > > In practice, the kernel drivers doesn't usually know too much about > > the dimensions/format/etc.. that is really userspace level knowledge. > > There are a few exceptions when the kernel needs to know how to setup > > GTT/etc for tiled buffers, but normally this sort of information is up > > at the next level up (userspace, and drm_framebuffer in case of > > scanout). Userspace media frameworks like GStreamer already have a > > concept of format/caps negotiation. For non-display<->gpu sharing, I > > think this is probably where this sort of constraint negotiation > > should be handled. Egads. GStreamer's caps negotiation is already close to unbounded time; seems like most of the optimisation work that goes into it these days is all about _reducing_ the complexity of caps negotiation! > I agree that user-space will know which devices will access the buffer > and thus can figure out at least a common pixel format. Hm, are you sure about that? The answer is yes for 'userspace' as a broad handwave, but not necessarily for individual processes. Take, for instance, media decode through GStreamer, being displayed by Wayland using a KMS plane/overlay/sprite/cursor/etc. The media player knows that the buffers are coming from the decode engine, and Wayland knows that the buffers are going to a KMS plane, but neither of them knows the full combination of the two. Though this kinda feeds into an idea I've been kicking around for a while, which is an 'optimal hint' mechanism in the Wayland protocol. So for our hypothetical dmabuf-using protocol, we'd start off with buffers which satisfied all the constraints of our media decode engine, but perhaps just the GPU rather than display controller. At this point, we'd note that we could place the video in a plane if only the buffers were better-allocated, and send an event to the client letting it know how to tweak its buffer allocation for more optimal display. But ... > Though I'm not > so sure userspace can figure out more low-level details like alignment > and placement in physical memory, etc. > > Anyway, assuming user-space can figure out how a buffer should be > stored in memory, how does it indicate this to a kernel driver and > actually allocate it? Which ioctl on which device does user-space > call, with what parameters? Are you suggesting using something like > ION which exposes the low-level details of how buffers are laid out in > physical memory to userspace? If not, what? ... this is still rather unresolved. ;) Cheers, Daniel > > Cheers, > > Tom > > > > > > > _______________________________________________ > Linaro-mm-sig mailing list > Linaro-mm-sig(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig

11 years, 3 months

[PATCH] drivers: of: fix build break if asm/dma-contiguous.h is missing

by Marek Szyprowski

It is not needed to include asm/dma-contiguous.h header to compile reserved memory initialization code, so remove it to avoid build break on architectures without CMA support. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/of/of_reserved_mem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c index a754b84..0fe40c7 100644 --- a/drivers/of/of_reserved_mem.c +++ b/drivers/of/of_reserved_mem.c @@ -11,8 +11,6 @@ * License or (at your optional) any later version of the license. */ -#include <asm/dma-contiguous.h> - #include <linux/memblock.h> #include <linux/err.h> #include <linux/of.h> -- 1.7.9.5

11 years, 3 months

[GIT PULL]: dma-buf updates for 3.12

by Sumit Semwal

Hi Linus, Here's the 3.12 pull request for dma-buf framework updates. Its yet another small one - dma-buf framework now supports size discovery of the buffer via llseek. Could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 26b0332e30c7f93e780aaa054bd84e3437f84354: Merge tag 'dmaengine-3.12' of git:// git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine (2013-09-09 18:07:15 -0700) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/for-3.12 for you to fetch changes up to 19e8697ba45e7bcdb04f2adf6110fbf4882863e5: dma-buf: Expose buffer size to userspace (v2) (2013-09-10 11:36:45 +0530) ---------------------------------------------------------------- dma-buf updates for 3.12 ---------------------------------------------------------------- Christopher James Halse Rogers (1): dma-buf: Expose buffer size to userspace (v2) Tuomas Tynkkynen (1): dma-buf: Check return value of anon_inode_getfile Documentation/dma-buf-sharing.txt | 12 ++++++++++++ drivers/base/dma-buf.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+)

11 years, 3 months

[PATCH] dma-buf: Expose buffer size to userspace (v2)

by Christopher James Halse Rogers

Each dma-buf has an associated size and it's reasonable for userspace to want to know what it is. Since userspace already has an fd, expose the size using the size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0); idiom. v2: Added Daniel's sugeested documentation, with minor fixups Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Tested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Documentation/dma-buf-sharing.txt | 12 ++++++++++++ drivers/base/dma-buf.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261..849e982 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: interesting ways depending upong the exporter (if userspace starts depending upon this implicit synchronization). +Other Interfaces Exposed to Userspace on the dma-buf FD +------------------------------------------------------ + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + Miscellaneous notes ------------------- diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 6687ba7..c33a857 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) return dmabuf->ops->mmap(dmabuf, vma); } +static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) +{ + struct dma_buf *dmabuf; + loff_t base; + + if (!is_dma_buf_file(file)) + return -EBADF; + + dmabuf = file->private_data; + + /* only support discovering the end of the buffer, + but also allow SEEK_SET to maintain the idiomatic + SEEK_END(0), SEEK_CUR(0) pattern */ + if (whence == SEEK_END) + base = dmabuf->size; + else if (whence == SEEK_SET) + base = 0; + else + return -EINVAL; + + if (offset != 0) + return -EINVAL; + + return base + offset; +} + static const struct file_operations dma_buf_fops = { .release = dma_buf_release, .mmap = dma_buf_mmap_internal, + .llseek = dma_buf_llseek, }; /* @@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, dmabuf->exp_name = exp_name; file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags); + file->f_mode |= FMODE_LSEEK; dmabuf->file = file; -- 1.8.3.2

11 years, 3 months

[RFC 0/4] Atomic Display Framework

by Greg Hackmann

Hi, ADF is an experimental display framework that I designed after experimenting with a KMS-based hardware composer for Android. ADF started as an proof-of-concept implemented from scratch, so right now it's a separate framework rather than a patchstack on top of KMS. If there's community interest, moving forward I'd like to merge its functionality into KMS rather than keep it as a separate thing. I'm going to talk about ADF at the Android and Graphics session at Linux Plumbers. The documentation's not done but I wanted to post these patches to people a heads-up about ADF. If there's interest I can write up some more formal documentation ahead of Plumbers. I designed ADF to deal with some serious issues I had working with KMS: 1. The API is geared toward updating one object at a time. Android's graphics stack needs the entire screen updated atomically to avoid tearing, and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic modeset patchset worked, but copy/update/commit design meant the driver had to keep a lot more internal state. 2. Some SoCs don't map well to KMS's CRTC + planes + encoders + connector model. At the time I was dealing with hardware where the blending engines didn't have their own framebuffer (they could only scan out constant colors or mix the output of other blocks), and you needed to gang several mixers together to drive high-res displays. 3. KMS doesn't support custom pixel formats, which a lot of newer SoCs use internally to cut down on bandwidth between hardware blocks. 4. KMS doesn't have a way to exchange sync fences. As a hack I managed to pass sync fences into the kernel as properties of the atomic pageflip, but there was no good way to get them back out of the kernel without a side channel. ADF represents display devices as collections of overlay engines and interfaces. Overlay engines (struct adf_overlay_engine) scan out images and interfaces (struct adf_interface) display those images. Overlay engines and interfaces can be connected in any n-to-n configuration that the hardware supports. Clients issue atomic updates to the screen by passing in a list of buffers (struct adf_buffer) consisting of dma-buf handles, sync fences, and basic metadata like format and size. If this involves composing multiple buffers, clients include a block of custom data describing the actual composition (scaling, z-order, blending, etc.) in a driver-specific format. Drivers provide hooks to validate these custom data blocks and commit the new configuration to hardware. ADF handles importing the dma-bufs and fences, waiting on incoming sync fences before committing, advancing the display's sync timeline, and releasing dma-bufs once they're removed from the screen. ADF represents pixel formats using DRM-style fourccs, and automatically sanity-checks buffer sizes when using one of the formats listed in drm_fourcc.h. Drivers can support custom fourccs if they provide hooks to validate buffers that use them. ADF also provides driver hooks for modesetting, managing and reporting hardware events like vsync, and changing DPMS state. These are documented in struct adf_{obj,overlay_engine,interface,device}_ops, and are similar to the equivalent DRM ops. Greg Hackmann (3): video: add atomic display framework video: adf: add display core helper video: adf: add memblock helper Laurent Pinchart (1): video: Add generic display entity core drivers/video/Kconfig | 2 + drivers/video/Makefile | 2 + drivers/video/adf/Kconfig | 15 + drivers/video/adf/Makefile | 14 + drivers/video/adf/adf.c | 1013 ++++++++++++++++++++++++++++++++++ drivers/video/adf/adf.h | 49 ++ drivers/video/adf/adf_client.c | 853 ++++++++++++++++++++++++++++ drivers/video/adf/adf_display.c | 123 +++++ drivers/video/adf/adf_fops.c | 982 ++++++++++++++++++++++++++++++++ drivers/video/adf/adf_fops.h | 37 ++ drivers/video/adf/adf_fops32.c | 217 ++++++++ drivers/video/adf/adf_fops32.h | 78 +++ drivers/video/adf/adf_memblock.c | 150 +++++ drivers/video/adf/adf_sysfs.c | 291 ++++++++++ drivers/video/adf/adf_sysfs.h | 33 ++ drivers/video/adf/adf_trace.h | 93 ++++ drivers/video/display/Kconfig | 4 + drivers/video/display/Makefile | 1 + drivers/video/display/display-core.c | 362 ++++++++++++ include/video/adf.h | 743 +++++++++++++++++++++++++ include/video/adf_client.h | 61 ++ include/video/adf_display.h | 31 ++ include/video/adf_format.h | 282 ++++++++++ include/video/adf_memblock.h | 20 + include/video/display.h | 150 +++++ 25 files changed, 5606 insertions(+) create mode 100644 drivers/video/adf/Kconfig create mode 100644 drivers/video/adf/Makefile create mode 100644 drivers/video/adf/adf.c create mode 100644 drivers/video/adf/adf.h create mode 100644 drivers/video/adf/adf_client.c create mode 100644 drivers/video/adf/adf_display.c create mode 100644 drivers/video/adf/adf_fops.c create mode 100644 drivers/video/adf/adf_fops.h create mode 100644 drivers/video/adf/adf_fops32.c create mode 100644 drivers/video/adf/adf_fops32.h create mode 100644 drivers/video/adf/adf_memblock.c create mode 100644 drivers/video/adf/adf_sysfs.c create mode 100644 drivers/video/adf/adf_sysfs.h create mode 100644 drivers/video/adf/adf_trace.h create mode 100644 drivers/video/display/Kconfig create mode 100644 drivers/video/display/Makefile create mode 100644 drivers/video/display/display-core.c create mode 100644 include/video/adf.h create mode 100644 include/video/adf_client.h create mode 100644 include/video/adf_display.h create mode 100644 include/video/adf_format.h create mode 100644 include/video/adf_memblock.h create mode 100644 include/video/display.h -- 1.8.0

11 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig September 2013