- Linaro-mm-sig - lists.linaro.org

[GIT PULL]: few dma-buf updates for 3.17-rc3

by Sumit Semwal

Hi Linus, The major changes for 3.17 already went via Greg-KH's tree this time as well; this is a small pull request for dma-buf - all documentation related. Could you please pull? The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d: Merge branch 'sec-v3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security (2014-08-27 17:32:37 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/for-3.17-rc3 for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295: dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530) ---------------------------------------------------------------- Small dma-buf pull request for 3.17-rc3 ---------------------------------------------------------------- Gioh Kim (1): Documentation/dma-buf-sharing.txt: update API descriptions Thierry Reding (2): dma-buf/fence: Fix a kerneldoc warning dma-buf/fence: Fix one more kerneldoc warning Documentation/dma-buf-sharing.txt | 14 ++++++++------ drivers/dma-buf/fence.c | 2 +- include/linux/seqno-fence.h | 1 + 3 files changed, 10 insertions(+), 7 deletions(-)

10 years, 9 months

1
0
0 0

[PATCH 0/2] ARM: Remove lowmem limit for default CMA region

by Marek Szyprowski

Hello, Russell King recently noticed that limiting default CMA region only to low memory on ARM architecture causes serious memory management issues with machines having a lot of memory (which is mainly available as high memory). More information can be found the following thread: http://thread.gmane.org/gmane.linux.ports.arm.kernel/348441/ Those two patches removes this limit letting kernel to put default CMA region into high memory when this is possible (there is enough high memory available and architecture specific DMA limit fits). This should solve strange OOM issues on systems with lots of RAM (i.e. >1GiB) and large (>256M) CMA area. Best regards Marek Szyprowski Samsung R&D Institute Poland Marek Szyprowski (2): mm: cma: adjust address limit to avoid hitting low/high memory boundary ARM: mm: don't limit default CMA region only to low memory arch/arm/mm/init.c | 2 +- mm/cma.c | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) -- 1.9.2

10 years, 9 months

6
15
0 0

[PATCH v2 0/4] CMA & device tree, once again

by Marek Szyprowski

Hello, This is one more respin of the patches which add support for creating reserved memory regions defined in device tree. The last attempt (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html) ended in merging only half of the code, so right now we have complete documentation merged and only basic code, which implements a half of it is written in the documentation. Although the merged patches allow to reserve memory, there is no way of using it for devices and drivers. This situation makes CMA rather useless, as the main architecture (ARM), which used it, has been converted from board-file based system initialization to device tree. Thus there is no place to use direct calls to dma_declare_contiguous() and some new solution, which bases on device tree, is urgently needed. This patch series fixes this issue. It provides two, already widely discussed and already present in the kernel, drivers for reserved memory: first based on DMA-coherent allocator, second using Contiguous Memory Allocator. The first one nicely implements typical 'carved out' reserved memory way of allocating contiguous buffers in a kernel-style way. The memory is used exclusively by devices assigned to the given memory region. The second one allows to reuse reserved memory for movable kernel pages (like disk buffers, anonymous memory) and migrates it out when device to allocates contiguous memory buffer. Both driver provides memory buffers via standard dma-mapping API. The patches have been rebased on top of latest CMA and mm changes merged to akmp kernel tree. To define a 64MiB CMA region following node is needed: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; reusable; size = <0x4000000>; alignment = <0x400000>; }; Similarly, one can define 64MiB region with DMA coherent memory: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; no-map; size = <0x4000000>; alignment = <0x400000>; }; Then the defined region can be assigned to devices: scaler: scaler@12500000 { memory-region = <&multimedia_reserved>; /* ... */ }; codec: codec@12600000 { memory-region = <&multimedia_reserved>; /* ... */ }; Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg343702.html) - fixed possible memory leak in case of reserved memory allocation failure (thanks to Joonsoo Kim) Changes since the version posted in '[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again' thread http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html: - rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code' patch series on v3.16-rc3 - improved dma-coherent driver, now it correctly handles assigning more than one device to the given memory region Patch summary: Marek Szyprowski (4): drivers: of: add automated assignment of reserved regions to client devices drivers: of: initialize and assign reserved memory to newly created devices drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 40 +++++++++++++++++++++++ drivers/base/dma-contiguous.c | 60 +++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 70 +++++++++++++++++++++++++++++++++++++++++ drivers/of/platform.c | 7 +++++ include/linux/cma.h | 3 ++ include/linux/of_reserved_mem.h | 7 +++++ mm/cma.c | 62 +++++++++++++++++++++++++++++------- 7 files changed, 238 insertions(+), 11 deletions(-) -- 1.9.2

10 years, 9 months

2
8
0 0

[git pull] sti driver fixes 3.17-rc2

by Benjamin Gaignard

Hello David, I have tested the 6 patches send on mailing list since you merge the sti driver. I haven't seen issue with those patches except for the missing dependency on Kconfig where I have change "depends on" to "select". You can found the patches in this directory: git://git.linaro.org/people/benjamin.gaignard/kernel.git on drm-3.17-rc2-sti-fixes branch. Regards, Benjamin Jingoo Han (1): drm: sti: Add missing dependency on RESET_CONTROLLER Kiran Padwal (1): drm: sti: Make of_device_id array const Wei Yongjun (4): drm: sti: tvout: fix return value check in sti_tvout_probe() drm: sti: hdmi: fix return value check in sti_hdmi_probe() drm: sti: hda: fix return value check in sti_hda_probe() drm: sti: Fix return value check in sti_drm_platform_probe() drivers/gpu/drm/sti/Kconfig | 1 + drivers/gpu/drm/sti/sti_drm_drv.c | 4 ++-- drivers/gpu/drm/sti/sti_hda.c | 10 +++++----- drivers/gpu/drm/sti/sti_hdmi.c | 10 +++++----- drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- 5 files changed, 16 insertions(+), 15 deletions(-) -- 1.9.1

10 years, 9 months

1
0
0 0

[PATCH 0/7] CMA & device tree, another approach

by Marek Szyprowski

Hello, This is another approach to finish support for reserved memory regions defined in device tree. Previous attempts (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html and https://lkml.org/lkml/2014/7/14/108) ended in merging parts of the code and documentation. Merged patches allow to reserve memory, but there is still no reserved memory drivers nor any code that actually uses reserved memory regions. The final conclusion from the above mentioned threads is that there is no automated reserved memory initialization. All drivers that want to use reserved memory, should initialize it on their own. This patch series provides two driver for reserved memory regions (one based on CMA and one based on dma_coherent allocator). The main improvement comparing to the previous version is removal of automated reserved memory for every device and support for named memory regions. Support for more than one reserved memory region can be considered as a separate DMA address space, so support for more than one region per device has been implemented the same way as support for separate IO/DMA address spaces in my Exynos IOMMU dma-mapping proposal: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/36079 Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since '[PATCH v2 RESEND 0/4] CMA & device tree, once again' version: (https://lkml.org/lkml/2014/7/14/108) - added return error value to of_reserved_mem_device_init() - added support for named memory regions (so more than one region can be defined per device) - added usage example - converted custom reserved memory code used by s5p-mfc driver to the generic reserved memory handling code Patch summary: Marek Szyprowski (7): drivers: of: add return value to of_reserved_mem_device_init drivers: of: add support for named memory regions drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree media: s5p-mfc: replace custom reserved memory init code with generic one ARM: Exynos: convert MFC to generic reserved memory bindings ARM: DTS: exynos4412-odroid*: enable MFC device .../devicetree/bindings/media/s5p-mfc.txt | 16 +-- .../bindings/reserved-memory/reserved-memory.txt | 6 +- arch/arm/boot/dts/exynos4210-origen.dts | 22 +++- arch/arm/boot/dts/exynos4210-smdkv310.dts | 22 +++- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 ++++ arch/arm/boot/dts/exynos4412-origen.dts | 22 +++- arch/arm/boot/dts/exynos4412-smdk4412.dts | 22 +++- arch/arm/boot/dts/exynos5250-arndale.dts | 22 +++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 +++- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 22 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 22 +++- arch/arm/mach-exynos/exynos.c | 18 --- arch/arm/mach-exynos/mfc.h | 16 --- arch/arm/plat-samsung/Kconfig | 5 - arch/arm/plat-samsung/Makefile | 1 - arch/arm/plat-samsung/s5p-dev-mfc.c | 94 -------------- drivers/base/dma-coherent.c | 138 ++++++++++++++++++--- drivers/base/dma-contiguous.c | 71 +++++++++++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 102 ++++++--------- drivers/of/of_reserved_mem.c | 102 ++++++++++----- include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 9 +- mm/cma.c | 62 +++++++-- 23 files changed, 552 insertions(+), 291 deletions(-) delete mode 100644 arch/arm/mach-exynos/mfc.h delete mode 100644 arch/arm/plat-samsung/s5p-dev-mfc.c -- 1.9.2

10 years, 9 months

1
7
0 0

[PATCH v2] dma-mapping: Provide write-combine allocations

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> Provide an implementation for dma_{alloc,free,mmap}_writecombine() when the architecture supports DMA attributes. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- Changes in v2: - Add a generic dma_mmap_writecombine() function arch/arm/include/asm/dma-mapping.h | 16 ---------------- include/asm-generic/dma-mapping-common.h | 8 -------- include/linux/dma-mapping.h | 26 ++++++++++++++++++++++++++ 3 files changed, 26 insertions(+), 24 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index c45b61a4b4a5..85738b200023 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -265,22 +265,6 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs); -static inline void *dma_alloc_writecombine(struct device *dev, size_t size, - dma_addr_t *dma_handle, gfp_t flag) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_alloc_attrs(dev, size, dma_handle, flag, &attrs); -} - -static inline void dma_free_writecombine(struct device *dev, size_t size, - void *cpu_addr, dma_addr_t dma_handle) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_free_attrs(dev, size, cpu_addr, dma_handle, &attrs); -} - /* * This can be called during early boot to increase the size of the atomic * coherent DMA pool above the default value of 256KiB. It must be called diff --git a/include/asm-generic/dma-mapping-common.h b/include/asm-generic/dma-mapping-common.h index de8bf89940f8..d137431bf26f 100644 --- a/include/asm-generic/dma-mapping-common.h +++ b/include/asm-generic/dma-mapping-common.h @@ -205,14 +205,6 @@ dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL) -static inline int dma_mmap_writecombine(struct device *dev, struct vm_area_struct *vma, - void *cpu_addr, dma_addr_t dma_addr, size_t size) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs); -} - int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr, size_t size); diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 931b70986272..d5d388160f42 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -263,6 +263,32 @@ struct dma_attrs; #define dma_unmap_sg_attrs(dev, sgl, nents, dir, attrs) \ dma_unmap_sg(dev, sgl, nents, dir) +#else +static inline void *dma_alloc_writecombine(struct device *dev, size_t size, + dma_addr_t *dma_addr, gfp_t gfp) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_alloc_attrs(dev, size, dma_addr, gfp, &attrs); +} + +static inline void dma_free_writecombine(struct device *dev, size_t size, + void *cpu_addr, dma_addr_t dma_addr) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_free_attrs(dev, size, cpu_addr, dma_addr, &attrs); +} + +static inline int dma_mmap_writecombine(struct device *dev, + struct vm_area_struct *vma, + void *cpu_addr, dma_addr_t dma_addr, + size_t size) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs); +} #endif /* CONFIG_HAVE_DMA_ATTRS */ #ifdef CONFIG_NEED_DMA_MAP_STATE -- 2.0.0

10 years, 9 months

4
5
0 0

Re: [Linaro-mm-sig] [PATCH] dma-buf: fix <linux/seqno-fence.h> kernel-doc warning

by Sumit Semwal

Hi Randy, ~ typing on a mobile device, kindly excuse any typos On Aug 17, 2014 2:45 AM, "Randy Dunlap" <rdunlap(a)infradead.org> wrote: > > From: Randy Dunlap <rdunlap(a)infradead.org> > > Fix kernel-doc warning, missing parameter description: > > Warning(..//include/linux/seqno-fence.h:99): No description found for parameter 'cond' Thanks for your patch; this is already fixed by Thierry Reading's patch and is queued in for-next. [1] > > Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> > Cc: Rob Clark <robdclark(a)gmail.com> > Cc: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> > --- > include/linux/seqno-fence.h | 1 + > 1 file changed, 1 insertion(+) > > Index: lnx-317-rc1/include/linux/seqno-fence.h > =================================================================== > --- lnx-317-rc1.orig/include/linux/seqno-fence.h > +++ lnx-317-rc1/include/linux/seqno-fence.h > @@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence) > * @context: the execution context this fence is a part of > * @seqno_ofs: the offset within @sync_buf > * @seqno: the sequence # to signal on > + * @cond: the fence condition to check > * @ops: the fence_ops for operations on this seqno fence > * > * This function initializes a struct seqno_fence with passed parameters, Best regards, Sumit. [1]: https://lkml.org/lkml/2014/8/8/191

10 years, 9 months

1
0
0 0

[PATCH] dma-buf/fence: Fix one more kerneldoc warning

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> The seqno_fence_init() function's cond argument isn't described in the kerneldoc comment. Fix that to silence a warning when building DocBook documentation. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- include/linux/seqno-fence.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h index 3d6003de4b0d..a1ba6a5ccdd6 100644 --- a/include/linux/seqno-fence.h +++ b/include/linux/seqno-fence.h @@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence) * @context: the execution context this fence is a part of * @seqno_ofs: the offset within @sync_buf * @seqno: the sequence # to signal on + * @cond: fence wait condition * @ops: the fence_ops for operations on this seqno fence * * This function initializes a struct seqno_fence with passed parameters, -- 2.0.4

10 years, 10 months

1
0
0 0

[PATCH] dma-buf/fence: Fix a kerneldoc warning

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> kerneldoc doesn't know how to parse variables, so don't let it try. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/dma-buf/fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index 4222cb2aa96a..7bb9d65d9a2c 100644 --- a/drivers/dma-buf/fence.c +++ b/drivers/dma-buf/fence.c @@ -29,7 +29,7 @@ EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on); EXPORT_TRACEPOINT_SYMBOL(fence_emit); -/** +/* * fence context counter: each execution context should have its own * fence context, this allows checking if fences belong to the same * context or not. One device can have multiple separate contexts, -- 2.0.4

10 years, 10 months

1
0
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by pintu_agarwal

Dear Joonsoo, I tried your changes which are present at the below link. https://github.com/JoonsooKim/linux/tree/cma-fix-up-v3.0-next-20140625 But unfortunately for me it did not help much. After running various apps that uses ION nonmovable memory, it fails to allocate memory after some time. When I see the pagetypeinfo shows lots of CMA pages available and non-movable were very less and thus nonmovable allocation were failing. However I noticed the failure was little delayed. Also I noticed that the CMA utilized and the CMA free is not matching with total CMA size. In my system RAM is 256MB and CMA configured is 56MB. And free memory was hanging around 30-40MB during failure. Am I missing something? My kernel version is 3.10 and I applied the changes manually. If there are other sets of patches that needs to be applied, please let me know. Note, I did not apply the ALLOC_CMA removal patches. Now I am experimenting more and will share if I have any findings. Thank you! Pintu Sent from Samsung Mobile -------- Original message -------- From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Date: 29/07/2014 5:06 PM (GMT+09:00) To: 'pintu_agarwal' <pintu_agarwal(a)yahoo.com>,linux-mm@kvack.org,linux-arm-kernel@lists.infradead.org,linaro-mm-sig@lists.linaro.org,ritesh.list@gmail.com Cc: pintu.k@outlook.com,pintu.k@samsung.com,vishu_1385@yahoo.com,m.szyprowski@samsung.com,mina86@mina86.com,ngupta@vflare.org,iqbalblr@gmail.com Subject: RE: [linux-3.10.17] Could not allocate memory from free CMA areas From: pintu_agarwal [mailto:pintu_agarwal@yahoo.com] Sent: Friday, July 25, 2014 12:15 AM To: PINTU KUMAR; linux-mm(a)kvack.org; linux-arm-kernel(a)lists.infradead.org; linaro-mm-sig(a)lists.linaro.org; iamjoonsoo.kim(a)lge.com; ritesh.list(a)gmail.com Cc: pintu.k(a)outlook.com; pintu.k(a)samsung.com; vishu_1385(a)yahoo.com; m.szyprowski(a)samsung.com; mina86(a)mina86.com; ngupta(a)vflare.org; iqbalblr(a)gmail.com Subject: RE: [linux-3.10.17] Could not allocate memory from free CMA areas Dear joonsoo kim, > I have your patches for: Aggressively allocate memory from cma .... > We are facing almost similar problem here. > If any of your patches still working for you please let us know here. > I would like to try those approach. Hello, I stopped to implement it, because there are other bugs on CMA related codes. Although aggressively allocate... doesn't have bugs itself, it enlarges existing freepage counting bugs significantly so I'm first trying to fix those bugs. See the below link. https://lkml.org/lkml/2014/7/4/79 I will restart to implement aggressively... after fixing these bugs. If you have interest on next version of aggressively allocate..., see the following link. https://github.com/JoonsooKim/linux/tree/cma-fix-up-v3.0-next-20140625 Thanks.

10 years, 10 months

3
3
0 0

[PATCH v2 RESEND 0/4] CMA & device tree, once again

by Marek Szyprowski

Hello, (please ignore previous patchset, I've attached wrong version of patches) This is one more respin of the patches which add support for creating reserved memory regions defined in device tree. The last attempt (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html) ended in merging only half of the code, so right now we have complete documentation merged and only basic code, which implements a half of it is written in the documentation. Although the merged patches allow to reserve memory, there is no way of using it for devices and drivers. This situation makes CMA rather useless, as the main architecture (ARM), which used it, has been converted from board-file based system initialization to device tree. Thus there is no place to use direct calls to dma_declare_contiguous() and some new solution, which bases on device tree, is urgently needed. This patch series fixes this issue. It provides two, already widely discussed and already present in the kernel, drivers for reserved memory: first based on DMA-coherent allocator, second using Contiguous Memory Allocator. The first one nicely implements typical 'carved out' reserved memory way of allocating contiguous buffers in a kernel-style way. The memory is used exclusively by devices assigned to the given memory region. The second one allows to reuse reserved memory for movable kernel pages (like disk buffers, anonymous memory) and migrates it out when device to allocates contiguous memory buffer. Both driver provides memory buffers via standard dma-mapping API. The patches have been rebased on top of latest CMA and mm changes merged to akmp kernel tree. To define a 64MiB CMA region following node is needed: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; reusable; size = <0x4000000>; alignment = <0x400000>; }; Similarly, one can define 64MiB region with DMA coherent memory: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; no-map; size = <0x4000000>; alignment = <0x400000>; }; Then the defined region can be assigned to devices: scaler: scaler@12500000 { memory-region = <&multimedia_reserved>; /* ... */ }; codec: codec@12600000 { memory-region = <&multimedia_reserved>; /* ... */ }; Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg343702.html) - fixed possible memory leak in case of reserved memory allocation failure (thanks to Joonsoo Kim) Changes since the version posted in '[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again' thread http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html: - rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code' patch series on v3.16-rc3 - improved dma-coherent driver, now it correctly handles assigning more than one device to the given memory region Patch summary: Marek Szyprowski (4): drivers: of: add automated assignment of reserved regions to client devices drivers: of: initialize and assign reserved memory to newly created devices drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 137 ++++++++++++++++++++++++++++++++++------ drivers/base/dma-contiguous.c | 67 ++++++++++++++++++++ drivers/of/of_reserved_mem.c | 70 ++++++++++++++++++++ drivers/of/platform.c | 7 ++ include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 7 ++ mm/cma.c | 62 ++++++++++++++---- 7 files changed, 323 insertions(+), 30 deletions(-) -- 1.9.2

10 years, 10 months

2
13
0 0

[PATCH v5 00/11] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. version 5: - Rework sti_drm_drv probes functions to support deferred probe. This allow hdmi to delayed framebuffer creation until I2C is available. - Add ops functsions in sti_layer structure to simpify GDP and VID code. - Add NOTES file to describe how the DRM concepts are mapped on hardware. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v5 version 4: - Remove depency between TVout it subdevices HDMI and HDA - Rework and simplify VTG and VTAC code - Fix numbers of typo and indentation - Remove debug (will be push in separate patches) - Fix remarks done in previous patcheset patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v4 version 3: - Correctly split code between probe and bind funtions - Squash some commits - remove HQ-VDP device code to have a smaller patcheset, we will introduce it later. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v3 version 2: - Use componentized device instead of register sub-devices in master driver probe function - Fix Makefile and Kconfig to only allow built-in compilation patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v2 version 1: - First path submission Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (11): drm: sti: add bindings for DRM driver drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: Add DRM driver itself .../devicetree/bindings/gpu/st,stih4xx.txt | 189 +++++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 14 + drivers/gpu/drm/sti/Makefile | 17 + drivers/gpu/drm/sti/NOTES | 58 ++ drivers/gpu/drm/sti/sti_compositor.c | 264 +++++++ drivers/gpu/drm/sti/sti_compositor.h | 90 +++ drivers/gpu/drm/sti/sti_drm_crtc.c | 419 +++++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 21 + drivers/gpu/drm/sti/sti_drm_drv.c | 244 +++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 29 + drivers/gpu/drm/sti/sti_drm_plane.c | 192 +++++ drivers/gpu/drm/sti/sti_drm_plane.h | 17 + drivers/gpu/drm/sti/sti_gdp.c | 549 ++++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 16 + drivers/gpu/drm/sti/sti_hda.c | 790 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.c | 808 +++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 88 +++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 +++++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 + drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 211 ++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h | 14 + drivers/gpu/drm/sti/sti_layer.c | 206 ++++++ drivers/gpu/drm/sti/sti_layer.h | 125 ++++ drivers/gpu/drm/sti/sti_mixer.c | 249 +++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 ++ drivers/gpu/drm/sti/sti_tvout.c | 657 +++++++++++++++++ drivers/gpu/drm/sti/sti_vid.c | 138 ++++ drivers/gpu/drm/sti/sti_vid.h | 12 + drivers/gpu/drm/sti/sti_vtac.c | 211 ++++++ drivers/gpu/drm/sti/sti_vtg.c | 356 +++++++++ drivers/gpu/drm/sti/sti_vtg.h | 28 + 33 files changed, 6419 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/NOTES create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h -- 1.9.1

10 years, 10 months

5
26
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by pintu_agarwal

Dear joonsoo kim, I have your patches for: Aggressively allocate memory from cma .... We are facing almost similar problem here. If any of your patches still working for you please let us know here. I would like to try those approach. Thank you Sent from Samsung Mobile -------- Original message -------- From: PINTU KUMAR <pintu_agarwal(a)yahoo.com> Date: 09/07/2014 8:41 AM (GMT+09:00) To: linux-mm@kvack.org,linux-mm@kvack.org,linux-arm-kernel@lists.infradead.org,linaro-mm-sig@lists.linaro.org Cc: pintu.k@outlook.com,pintu.k@samsung.com,vishu_1385@yahoo.com,m.szyprowski@samsung.com,mina86@mina86.com,ngupta@vflare.org,iqbalblr@gmail.com Subject: [linux-3.10.17] Could not allocate memory from free CMA areas Hi, We are facing one problem on linux 3.10 when we try to use CMA as large as 56MB for 256MB RAM device. We found that after certain point of time (during boot), min watermark check is failing when "free_pages" and "free_cma_pages" are almost equal and falls below the min level. system details: ARM embedded device: RAM: 256MB Kernel version: 3.10.17 Fixed Reserved memory: ~40MB Available memory: 217MB CMA reserved 1 : 56MB ZRAM configured: 128MB or 64MB min_free_kbytes: 1625 (default) Memory controller group enabled (MEMCG) After boot-up the "free -tm" command shows free memory as: ~50MB CMA is used for all UI display purposes. CMA used during bootup is close to ~6MB. Thus most of the free memory is in the form of CMA free memory. ZRAM getting uses was around ~5MB. During boot-up itself we observe that the following conditions are met. if (free_pages - free_cma <= min + lowmem_reserve) { printk"[PINTU]: __zone_watermark_ok: failed !\n"); return false; } Here: free_pages was: 12940, free_cma was: 12380, min: 566, lowmem: 0 Thus is condition is met most of the time. And because of this watermark failure, Kswapd is waking up frequently. The /proc/pagetypeinfo reports that most of the higher order pages are from CMA regions. We also observed that ZRAM is trying to allocate memory from CMA region and failing. We also tried by decreasing the CMA region to 20MB. With this the watermark failure is not happening in boot time. But if we launch more than 3 apps {Browser, music-player etc}, again the watermark started failing. Also we tried decreasing the min_free_kbytes=256, and with this also watermark is passed. Our observation is that ZRAM/zsmalloc trying to allocate memory from CMA areas and failed. Please let us know if anybody have come across the same problem and how to resolve this issue. Thank You! Regards, Pintu

10 years, 10 months

2
1
0 0

[RFC PATCH] mm: cma: allow O_DIRECT I/O on CMA pages

by Marc Carino

It is desirable to perform "zero copy" operations on the numerous embedded systems that run the Linux kernel, to enable efficient performance on resource-constrained systems. Usually such embedded systems leverage mechanisms like CMA to carve-out regions of contiguous physical memory for use by bus-mastering peripherals. This patch adds some logic which determines if user-space is attempting to perform direct I/O mapping on CMA pages, and if so, ensures the mapping succeeds. This patch is a 1st attempt to allow O_DIRECT on the memory carved-out by CMA. Any suggestions or comments are appreciated! Signed-off-by: Marc Carino <marc.ceeeee(a)gmail.com> --- mm/gup.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/mm/gup.c b/mm/gup.c index cc5a9e7..5fd1bfa 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -353,6 +353,61 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) return 0; } +static int cma_get_page(struct mm_struct *mm, struct vm_area_struct *vma, + unsigned long start, struct page **page) +{ +#ifdef CONFIG_CMA + const unsigned long pg = start & PAGE_MASK; + unsigned long pfn; + int ret = -EFAULT; + pgd_t *pgd; + pud_t *pud; + pmd_t *pmd; + pte_t *pte; + struct page *tmp_page; + + pgd = pgd_offset(mm, pg); + BUG_ON(pgd_none(*pgd)); + pud = pud_offset(pgd, pg); + BUG_ON(pud_none(*pud)); + pmd = pmd_offset(pud, pg); + if (pmd_none(*pmd)) + return ret; + + pte = pte_offset_map(pmd, pg); + if (!pte) + return ret; + + if (pte_none(*pte)) + goto out; + + tmp_page = pte_page(*pte); + if (!tmp_page) + goto out; + + if (!page_count(tmp_page)) + goto out; + + if (page_mapped(tmp_page)) + goto out; + + if (get_pageblock_migratetype(tmp_page) != MIGRATE_CMA) + goto out; + + if (page) { + *page = tmp_page; + get_page(*page); + } + ret = 0; + +out: + pte_unmap(pte); + return ret; +#else + return 0; +#endif +} + /** * __get_user_pages() - pin user pages in memory * @tsk: task_struct of target task @@ -443,6 +498,16 @@ long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm, goto next_page; } + if (!cma_get_page(mm, vma, start, + pages ? &pages[i] : NULL)) { + if (vmas) + vmas[i] = vma; + i++; + start += PAGE_SIZE; + nr_pages--; + continue; + } + if (!vma || check_vma_flags(vma, gup_flags)) return i ? : -EFAULT; if (is_vm_hugetlb_page(vma)) { -- 1.8.1.3

10 years, 10 months

3
2
0 0

Re: [Linaro-mm-sig] [PATCH 00/83] AMD HSA kernel driver

by Daniel Vetter

On Tue, Jul 15, 2014 at 7:53 PM, Bridgman, John <John.Bridgman(a)amd.com> wrote: [snip away the discussion about hsa device discover, I'm hijacking this thread just for the event/fence stuff here.] > ... There's an event mechanism still to come - mostly for communicating fences and shader interrupts back to userspace, but also used for "device change" notifications, so no polling of sysfs. That could would be interesting. On i915 my plan is to internally use the recently added struct fence from Maarten. For the external interface for userspace that wants explicit control over fences I'm leaning towards polishing the android syncpt stuff (currently in staging). But in any case I _really_ want to avoid that we end up with multiple different and incompatible explicit fencing interfaces on linux. Adding relevant people. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

10 years, 10 months

2
1
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by Marek Szyprowski

Hello, On 2014-07-09 01:41, PINTU KUMAR wrote: > Hi, > > We are facing one problem on linux 3.10 when we try to use CMA as large as 56MB for 256MB RAM device. > We found that after certain point of time (during boot), min watermark check is failing when "free_pages" and "free_cma_pages" are almost equal and falls below the min level. > > system details: > ARM embedded device: RAM: 256MB > Kernel version: 3.10.17 > Fixed Reserved memory: ~40MB > Available memory: 217MB > CMA reserved 1 : 56MB > ZRAM configured: 128MB or 64MB > min_free_kbytes: 1625 (default) > Memory controller group enabled (MEMCG) > > > After boot-up the "free -tm" command shows free memory as: ~50MB > CMA is used for all UI display purposes. CMA used during bootup is close to ~6MB. > Thus most of the free memory is in the form of CMA free memory. > ZRAM getting uses was around ~5MB. > > > During boot-up itself we observe that the following conditions are met. > > > if (free_pages - free_cma <= min + lowmem_reserve) { > printk"[PINTU]: __zone_watermark_ok: failed !\n"); > > return false; > } > Here: free_pages was: 12940, free_cma was: 12380, min: 566, lowmem: 0 > > > Thus is condition is met most of the time. > And because of this watermark failure, Kswapd is waking up frequently. > The /proc/pagetypeinfo reports that most of the higher order pages are from CMA regions. > > > We also observed that ZRAM is trying to allocate memory from CMA region and failing. > > We also tried by decreasing the CMA region to 20MB. With this the watermark failure is not happening in boot time. But if we launch more than 3 apps {Browser, music-player etc}, again the watermark started failing. > > Also we tried decreasing the min_free_kbytes=256, and with this also watermark is passed. > > Our observation is that ZRAM/zsmalloc trying to allocate memory from CMA areas and failed. > > > Please let us know if anybody have come across the same problem and how to resolve this issue. Frankly I really have no idea what is going on. ZRAM/zsmalloc should not try to alloc memory from CMA. I don't have access you the mentioned source code. What flags are passed to alloc_pages() in zram/zsmalloc? It should get pages from non-movable pool. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

10 years, 10 months

1
0
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by Pintu Kumar

Hi All, No reply on the below. Does anybody came across with the similar issues? Please let me know if any fixes are already available. Issues: 1) When free memory pages and CMA free pages are almost equal, min watermark check is failing, resulting in swapping. 2) Almost all the free memory in system is CMA free memory. 3) When ZRAM tries to allocate pages from CMA free areas, the allocation fails. Please refer below for more details. Thank you! Regards, Pintu > Date: Tue, 8 Jul 2014 16:41:40 -0700 > From: pintu_agarwal(a)yahoo.com > Subject: [linux-3.10.17] Could not allocate memory from free CMA areas > To: linux-mm(a)kvack.org; linux-mm(a)kvack.org; linux-arm-kernel(a)lists.infradead.org; linaro-mm-sig(a)lists.linaro.org > CC: pintu.k(a)outlook.com; pintu.k(a)samsung.com; vishu_1385(a)yahoo.com; m.szyprowski(a)samsung.com; mina86(a)mina86.com; ngupta(a)vflare.org; iqbalblr(a)gmail.com > > Hi, > > We are facing one problem on linux 3.10 when we try to use CMA as large as 56MB for 256MB RAM device. > We found that after certain point of time (during boot), min watermark check is failing when "free_pages" and "free_cma_pages" are almost equal and falls below the min level. > > system details: > ARM embedded device: RAM: 256MB > Kernel version: 3.10.17 > Fixed Reserved memory: ~40MB > Available memory: 217MB > CMA reserved 1 : 56MB > ZRAM configured: 128MB or 64MB > min_free_kbytes: 1625 (default) > Memory controller group enabled (MEMCG) > > > After boot-up the "free -tm" command shows free memory as: ~50MB > CMA is used for all UI display purposes. CMA used during bootup is close to ~6MB. > Thus most of the free memory is in the form of CMA free memory. > ZRAM getting uses was around ~5MB. > > > During boot-up itself we observe that the following conditions are met. > > > if (free_pages - free_cma <= min + lowmem_reserve) { > printk"[PINTU]: __zone_watermark_ok: failed !\n"); > > return false; > } > Here: free_pages was: 12940, free_cma was: 12380, min: 566, lowmem: 0 > > > Thus is condition is met most of the time. > And because of this watermark failure, Kswapd is waking up frequently. > The /proc/pagetypeinfo reports that most of the higher order pages are from CMA regions. > > > We also observed that ZRAM is trying to allocate memory from CMA region and failing. > > We also tried by decreasing the CMA region to 20MB. With this the watermark failure is not happening in boot time. But if we launch more than 3 apps {Browser, music-player etc}, again the watermark started failing. > > Also we tried decreasing the min_free_kbytes=256, and with this also watermark is passed. > > Our observation is that ZRAM/zsmalloc trying to allocate memory from CMA areas and failed. > > > Please let us know if anybody have come across the same problem and how to resolve this issue. > > > > > > Thank You! > Regards, > Pintu

10 years, 11 months

1
0
0 0

Re: [Linaro-mm-sig] [RFC] dma-buf: Implement test module

by Thierry Reding

On Tue, Mar 25, 2014 at 07:01:10PM +0100, Sam Ravnborg wrote: > > > > There are two things that don't work too well with this. First this > > causes the build to break if the build machine doesn't have the new > > public header (include/uapi/linux/dma-buf.h) installed yet. So the only > > way to make this work would be by building the kernel once with SAMPLES > > disabled, install the headers and then build again with SAMPLES enabled. > > Which really isn't very nice. > > > > One other option that I've tried is to modify the include path so that > > the test program would get the in-tree copy of the public header file, > > but that didn't build properly either because the header files aren't > > properly sanitized and therefore the compiler complains about it > > (include/uapi/linux/types.h). > > > > One other disadvantage of carrying the sample program in the tree is > > that there's only infrastructure to build programs natively on the build > > machine. That's somewhat unfortunate because if you want to run the test > > program on a different architecture you have to either compile the > > kernel natively on that architecture (which isn't very practical on many > > embedded devices) or cross-compile manually. > > > > I think a much nicer solution would be to add infrastructure to cross- > > compile these test programs, so that they end up being built for the > > same architecture as the kernel image (i.e. using CROSS_COMPILE). > > > > Adding Michal and the linux-kbuild mailing list, perhaps this has been > > discussed before, or maybe somebody has a better idea on how to solve > > this. > I actually looked into this some time ago. > May try to dust off the patch. > IIRC the kernel provided headers were used for building - not the one installed on the machine. > And crosscompile were supported. That sounds exactly like what I'd want for this. If you need any help, please let me know. Thanks, Thierry

10 years, 11 months

2
2
0 0

[PATCH v2 0/9] Updated fence patch series

by Maarten Lankhorst

So after some more hacking I've moved dma-buf to its own subdirectory, drivers/dma-buf and applied the fence patches to its new place. I believe that the first patch should be applied regardless, and the rest should be ready now. :-) Changes to the fence api: - release_fence -> fence_release etc. - __fence_init -> fence_init - __fence_signal -> fence_signal_locked - __fence_is_signaled -> fence_is_signaled_locked - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers. Android can expose fences to userspace. It's possible to make the new fence mechanism expose the same fences to userspace by changing sync_fence_create to take a struct fence instead of a struct sync_pt. No other change is needed, because only the fence parts of struct sync_pt are used. But because the userspace fences are a separate problem and I haven't really looked at it yet I feel it should stay in staging, for now. --- Maarten Lankhorst (9): dma-buf: move to drivers/dma-buf fence: dma-buf cross-device synchronization (v18) seqno-fence: Hardware dma-buf implementation of fencing (v6) dma-buf: use reservation objects android: convert sync to fence api, v6 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v3 reservation: update api and add some helpers reservation: add suppport for read-only access using rcu Documentation/DocBook/device-drivers.tmpl | 8 MAINTAINERS | 4 drivers/Makefile | 1 drivers/base/Kconfig | 9 drivers/base/Makefile | 1 drivers/base/dma-buf.c | 743 -------------------- drivers/base/reservation.c | 39 - drivers/dma-buf/Makefile | 1 drivers/dma-buf/dma-buf.c | 907 ++++++++++++++++++++++++ drivers/dma-buf/fence.c | 431 +++++++++++ drivers/dma-buf/reservation.c | 477 +++++++++++++ drivers/dma-buf/seqno-fence.c | 73 ++ drivers/gpu/drm/armada/armada_gem.c | 2 drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 drivers/gpu/drm/nouveau/nouveau_gem.h | 1 drivers/gpu/drm/nouveau/nouveau_prime.c | 7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 drivers/gpu/drm/radeon/radeon_drv.c | 2 drivers/gpu/drm/radeon/radeon_prime.c | 8 drivers/gpu/drm/tegra/gem.c | 2 drivers/gpu/drm/ttm/ttm_object.c | 2 drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 drivers/staging/android/Kconfig | 1 drivers/staging/android/Makefile | 2 drivers/staging/android/ion/ion.c | 3 drivers/staging/android/sw_sync.c | 6 drivers/staging/android/sync.c | 913 ++++++++---------------- drivers/staging/android/sync.h | 79 +- drivers/staging/android/sync_debug.c | 247 ++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 3 include/linux/dma-buf.h | 21 - include/linux/fence.h | 360 +++++++++ include/linux/reservation.h | 82 ++ include/linux/seqno-fence.h | 116 +++ include/trace/events/fence.h | 128 +++ 39 files changed, 3258 insertions(+), 1451 deletions(-) delete mode 100644 drivers/base/dma-buf.c delete mode 100644 drivers/base/reservation.c create mode 100644 drivers/dma-buf/Makefile create mode 100644 drivers/dma-buf/dma-buf.c create mode 100644 drivers/dma-buf/fence.c create mode 100644 drivers/dma-buf/reservation.c create mode 100644 drivers/dma-buf/seqno-fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature

10 years, 11 months

5
21
0 0

[REPOST PATCH 0/8] fence synchronization patches

by Maarten Lankhorst

The following series implements fence and converts dma-buf and android sync to use it. Patch 5 and 6 add support for polling to dma-buf, blocking until all fences are signaled. Patch 7 and 8 provide some helpers, and allow use of RCU in the reservation api. The helpers make it easier to convert ttm, and make dealing with rcu less painful. Patches slightly updated to fix compilation with armada and new atomic primitives, but otherwise identical. --- Maarten Lankhorst (8): fence: dma-buf cross-device synchronization (v17) seqno-fence: Hardware dma-buf implementation of fencing (v5) dma-buf: use reservation objects android: convert sync to fence api, v5 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v3 reservation: update api and add some helpers reservation: add suppport for read-only access using rcu Documentation/DocBook/device-drivers.tmpl | 3 drivers/base/Kconfig | 9 drivers/base/Makefile | 2 drivers/base/dma-buf.c | 168 ++++ drivers/base/fence.c | 468 ++++++++++++ drivers/base/reservation.c | 440 ++++++++++++ drivers/gpu/drm/armada/armada_gem.c | 2 drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 drivers/gpu/drm/nouveau/nouveau_gem.h | 1 drivers/gpu/drm/nouveau/nouveau_prime.c | 7 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 drivers/gpu/drm/radeon/radeon_drv.c | 2 drivers/gpu/drm/radeon/radeon_prime.c | 8 drivers/gpu/drm/tegra/gem.c | 2 drivers/gpu/drm/ttm/ttm_object.c | 2 drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 drivers/staging/android/Kconfig | 1 drivers/staging/android/Makefile | 2 drivers/staging/android/ion/ion.c | 3 drivers/staging/android/sw_sync.c | 6 drivers/staging/android/sync.c | 913 ++++++++---------------- drivers/staging/android/sync.h | 79 +- drivers/staging/android/sync_debug.c | 247 ++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 3 include/linux/dma-buf.h | 21 - include/linux/fence.h | 355 +++++++++ include/linux/reservation.h | 82 ++ include/linux/seqno-fence.h | 119 +++ include/trace/events/fence.h | 128 +++ 33 files changed, 2435 insertions(+), 668 deletions(-) create mode 100644 drivers/base/fence.c create mode 100644 drivers/staging/android/sync_debug.c create mode 100644 include/linux/fence.h create mode 100644 include/linux/seqno-fence.h create mode 100644 include/trace/events/fence.h -- Signature

10 years, 11 months

10
44
0 0

[PATCH 0/4] CMA & device tree, once again

by Marek Szyprowski

Hello, This is one more respin of the patches which add support for creating reserved memory regions defined in device tree. The last attempt (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html) ended in merging only half of the code, so right now we have complete documentation merged and only basic code, which implements a half of it is written in the documentation. Although the merged patches allow to reserve memory, there is no way of using it for devices and drivers. This situation makes CMA rather useless, as the main architecture (ARM), which used it, has been converted from board-file based system initialization to device tree. Thus there is no place to use direct calls to dma_declare_contiguous() and some new solution, which bases on device tree, is urgently needed. This patch series fixes this issue. It provides two, already widely discussed and already present in the kernel, drivers for reserved memory: first based on DMA-coherent allocator, second using Contiguous Memory Allocator. The first one nicely implements typical 'carved out' reserved memory way of allocating contiguous buffers in a kernel-style way. The memory is used exclusively by devices assigned to the given memory region. The second one allows to reuse reserved memory for movable kernel pages (like disk buffers, anonymous memory) and migrates it out when device to allocates contiguous memory buffer. Both driver provides memory buffers via standard dma-mapping API. The patches have been rebased on top of latest CMA and mm changes merged to akmp kernel tree. To define a 64MiB CMA region following node is needed: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; reusable; size = <0x4000000>; alignment = <0x400000>; }; Similarly, one can define 64MiB region with DMA coherent memory: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; no-map; size = <0x4000000>; alignment = <0x400000>; }; Then the defined region can be assigned to devices: scaler: scaler@12500000 { memory-region = <&multimedia_reserved>; /* ... */ }; codec: codec@12600000 { memory-region = <&multimedia_reserved>; /* ... */ }; Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since the version posted in '[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again' thread http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html: - rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code' patch series on v3.16-rc3 - improved dma-coherent driver, now it correctly handles assigning more than one device to the given memory region Patch summary: Marek Szyprowski (4): drivers: of: add automated assignment of reserved regions to client devices drivers: of: initialize and assign reserved memory to newly created devices drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 137 ++++++++++++++++++++++++++++++++++------ drivers/base/dma-contiguous.c | 67 ++++++++++++++++++++ drivers/of/of_reserved_mem.c | 70 ++++++++++++++++++++ drivers/of/platform.c | 7 ++ include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 7 ++ mm/cma.c | 69 +++++++++++++++----- 7 files changed, 324 insertions(+), 36 deletions(-) -- 1.9.2

10 years, 11 months

2
6
0 0

DMA buffer sharing between two drivers using DMABUF

by Rahul Dargainya

Hello, I am trying to read a DMA buff ,allocated and manged by driver "A". reader is a different driver "B" (which simply make DMA buffer accessible by /proc to user space). Can dmabuf APIs can be used for all reader and writer synchronization issues ? I want to use dmabuf between two drivers , do i need to go to user space and use "fd" to get struct dma_buf * from dma_buf_get(int fd). there is any way to use dmabuf APIs in kernel space only (between two drivers ) without going to user space ? example code will certainly help. -- Regards Rahul Dargainya

10 years, 11 months

1
0
0 0

Re: [Linaro-mm-sig] Wayland generic dmabuf protocol

by Pekka Paalanen

On Mon, 9 Jun 2014 14:06:33 +0300 Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> wrote: > On Mon, 9 Jun 2014 11:00:04 +0200 > Benjamin Gaignard <benjamin.gaignard(a)linaro.org> wrote: > > > On my hardware the patches you have (+ this one on gstwaylandsink > > https://bugzilla.gnome.org/show_bug.cgi?id=711155) allow me to do zero > > copy between the hardware video decoder and the display engine. I > > don't have implemented GPU yet because my hardware is able to do > > compose few video overlays planes and it was enough for my tests. > > Right. > > What I have been thinking is, that the compositor must be able to use > the new wl_buffer and we need to guarantee that before-hand. If the > compositor fails to use a wl_buffer when the client has already > attached it to a wl_surface and it is time to repaint, it is too late > and the user will see a glitch. Recovering from that requires asking > the client to provide a new wl_buffer of a different kind, which might > take time. Or a very rude compositor would just send a protocol error, > and then we'd get bug reports like "the video player just disappears > when I try to play (and ps. I have an old kernel that doesn't support > importing whatever)". > > I believe we must allow the compositor to test the wl_buffer before it > is usable for the client. That is the reason for the roundtrippy design > of the below proposal. > > Because we do not even try to communicate all the possible restrictions > to the client for it to match, we can leave the validation strictly as > a kernel internal issue. Buffer migration inside the kernel might even > magically solve some of the mismatches. It does leave the problem of > what can the client do, if it doesn't fill all the requirements for the > compositor to be able to import the dmabufs. But what restrictions > other than color format we can or should communicate, and where does > user space get them in the first place... *hand-waving* > > But, this also leaves it up to the compositor to choose how/where it > wants to import the dmabufs. If a compositor is usually compositing > with GL, it will try to import with EGL on whatever GPU it is using. If > the compositor uses a software renderer, it can try to mmap the dmabufs > (or try this as a fallback, if the EGL import fails). If the compositor > is absolutely sure it can rely on the hardware display engine to > composite these buffers (note, buffers! You don't know to which > surfaces these buffers will be attached to), it can import directly > with DRM as FB objects, or V4L, or whatever. A compositor with the > fullscreen shell extension but without the sub-surface extension comes > to mind. > > In summary, the compositor must be able to use the wl_buffer in its > default/fallback compositing path. If the wl_buffer is also suitable > for direct scanout, e.g. on an overlay, that is "just" a bonus. > > With the round-trippy design, I am assuming that you can > export-pass-import a set of dmabufs once, and then reuse them as long > as you don't need to e.g. resize them. Is this a reasonable assumption? > Are there any, for instance, hardware video decoders that just insist on > exporting a new buffer for every frame? > > I am tracking the proposal in > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=linux_dmabuf > > So far I added back the event to advertise the supported > drm_fourcc formats, since that is probably quite crucial. Yeah, about that... https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_i… provides no way for the compositor to query, what formats the EGL implementation might support for importing dmabufs. I'm not sure GBM has that yet either. So there is no way a compositor could advertise the set of supported formats, since it has no way of knowing, has it? Any suggested solutions for this? Or would probing (export dmabuf, send to compositor, wait for compositor to ack/reject) for suitable formats be enough? Thanks, pq > > 2014-06-06 17:30 GMT+02:00 Pekka Paalanen <pekka.paalanen(a)collabora.co.uk>: > > > Hi, > > > > > > the previous attempt at introducing a generic wl_dmabuf protocol to > > > Wayland didn't end too well: > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012390.ht… > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012455.ht… > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012566.ht… > > > http://lists.freedesktop.org/archives/wayland-devel/2014-January/012727.html > > > > > > We are again interested in this, and I did a quick Friday evening draft > > > to open the discussion again. The base of the draft was a quick look at > > > https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_i… > > > > > > The basic idea is, that a client has one or more dmabufs it wants to > > > share with the compositor, making up a single logical buffer (a single > > > image). The client chooses where and how to export those dmabufs. The > > > dmabuf fds and metadata are sent to the compositor, the compositor > > > assembles and tries to import them. If the import succeeds, a wl_buffer > > > object is created. If the import fails, the client is notified that the > > > compositor can't use these, it would be better to try something else. > > > > > > I assume that if the "import" succeeds, the compositor is able to use > > > the buffers, e.g. at least turn them into a GL-texture or mmap them, if > > > not also able to scan out or put on a hw overlay. This could be any kind > > > of checking to verify that the buffers are usable. Finding out that it > > > won't work after the client is already using the wl_buffer must not > > > happen, as we have no way to recover from it: the client will get > > > disconnected. So the point is knowing in advance, that the buffers are > > > usable on both sides, preferrably before the client has filled them with > > > data, but I suppose in the usual case the buffer is already filled. > > > > > > As creating a dmabuf-based wl_buffer requires a roundtrip in this > > > scheme, I assume it only needs to be done rarely, and the same buffer > > > can be re-used many times with proper synchronization. > > > > > > The crude draft is below. Some questions: > > > - Does this sound sane to you? > > > - What other metadata would we need? Thierry had some issues with > > > tiling formats I think. > > > - This "check if the dmabuf is really usable" is needed, right? We > > > can't just assume that any dmabuf will work? > > > - Do we need anything for fences here, or is the dmabuf fd enough? > > > - Does someone already have something similar running?

10 years, 11 months

2
2
0 0

Re: [Linaro-mm-sig] Wayland generic dmabuf protocol

by Rob Clark

On Mon, Jun 9, 2014 at 8:44 AM, Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> wrote: > On Mon, 9 Jun 2014 12:23:18 +0100 > Daniel Stone <daniel(a)fooishbar.org> wrote: > >> Hi, >> >> On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> wrote: >> >> > On Mon, 9 Jun 2014 11:00:04 +0200 >> > Benjamin Gaignard <benjamin.gaignard(a)linaro.org> wrote: >> > > One of the main comment on the latest patches was that wl_dmabuf use >> > > DRM for buffer allocation. >> > > This appear to be an issue since wayland doesn't want to rely on one >> > > specific framework (DRM, or V4L2) for buffer allocation, so we have >> > > start working on a "central dmabuf allocation" on kernel side. The >> > > goal is provide some as generic as possible to make it acceptable by >> > > wayland. >> > >> > Why would Wayland need a central allocator for dmabuf? >> > >> >> I think you've just answered your own question further below: >> >> >> > > On my hardware the patches you have (+ this one on gstwaylandsink >> > > https://bugzilla.gnome.org/show_bug.cgi?id=711155) allow me to do zero >> > > copy between the hardware video decoder and the display engine. I >> > > don't have implemented GPU yet because my hardware is able to do >> > > compose few video overlays planes and it was enough for my tests. >> > >> > Right. >> > >> > What I have been thinking is, that the compositor must be able to use >> > the new wl_buffer and we need to guarantee that before-hand. If the >> > compositor fails to use a wl_buffer when the client has already >> > attached it to a wl_surface and it is time to repaint, it is too late >> > and the user will see a glitch. Recovering from that requires asking >> > the client to provide a new wl_buffer of a different kind, which might >> > take time. Or a very rude compositor would just send a protocol error, >> > and then we'd get bug reports like "the video player just disappears >> > when I try to play (and ps. I have an old kernel that doesn't support >> > importing whatever)". >> > >> > I believe we must allow the compositor to test the wl_buffer before it >> > is usable for the client. That is the reason for the roundtrippy design >> > of the below proposal. >> > >> >> A central allocator would solve these issues, by having everyone agree on >> the restrictions upfront, instead of working out which of the media decode >> engine, camera, GPU, or display controller is the lowest common >> denominator, and forcing all allocations through there. >> >> One such solution was discussed a while back WRT ION: >> https://lwn.net/Articles/565469/ >> >> See the 'possible solutions' part for a way for people to agree on >> restrictions wrt tiling, stride, contiguousness, etc. > > Hi, > > that's an excellent article. I didn't know that delayed allocation of > dmabufs was not even possible yet, which would have allowed us to > not think about importing failures and simply let the client fall back > with "ok, don't use dmabuf with this particular device then". hrm? I know of at least a couple drm drivers that defer allocation of backing pages.. > What is the conclusion here? > > Wayland protocol does not need to consider import failures at all, and > can simply punt those as protocol errors, which essentially kill the app > if they ever happen? > > Do we need to wait for the central allocator in kernel to materialize > before we can design the protocol? Is it simply too early to try to do > it now? I do tend to think the ION/central-allocator is just substituting one problem for another. It doesn't really solve the problem of how different devices which don't actually know each other can decide on buffers that they can share. On an phone/tablet/etc you know up front when building the kernel what devices there are and in what uses-cases they will be used, etc. But that isn't really solving the more general case. > Was the idea of dmabuf in-kernel constraint negotiation with delayed > allocation rejected in favour of a central allocator? not really, that I know of. I still think we need to spiff out dma-mapping to better handle placement constraints. (Although still prefer format constraints to be a userspace topic.) pengutronix is doing some work in this area: http://elinux.org/images/b/b0/OSELAS.Presentation-DMABUF-migration.pdf BR, -R > Will Intel, Nouveau and Radeon support the central allocator, or will > it remain for ARM-related devices only? > > > Thanks, > pq

10 years, 12 months

3
3
0 0

Re: [Linaro-mm-sig] Wayland generic dmabuf protocol

by Thomas Hellstrom

On 06/09/2014 01:23 PM, Daniel Stone wrote: > Hi, > > On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen(a)collabora.co.uk > <mailto:pekka.paalanen@collabora.co.uk>> wrote: > > On Mon, 9 Jun 2014 11:00:04 +0200 > Benjamin Gaignard <benjamin.gaignard(a)linaro.org > <mailto:benjamin.gaignard@linaro.org>> wrote: > > One of the main comment on the latest patches was that wl_dmabuf use > > DRM for buffer allocation. > > This appear to be an issue since wayland doesn't want to rely on one > > specific framework (DRM, or V4L2) for buffer allocation, so we have > > start working on a "central dmabuf allocation" on kernel side. The > > goal is provide some as generic as possible to make it acceptable by > > wayland. > > Why would Wayland need a central allocator for dmabuf? > > > I think you've just answered your own question further below: > > > > On my hardware the patches you have (+ this one on gstwaylandsink > > https://bugzilla.gnome.org/show_bug.cgi?id=711155 > <https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.gnome.org/show_…>) > allow me to do zero > > copy between the hardware video decoder and the display engine. I > > don't have implemented GPU yet because my hardware is able to do > > compose few video overlays planes and it was enough for my tests. > > Right. > > What I have been thinking is, that the compositor must be able to use > the new wl_buffer and we need to guarantee that before-hand. If the > compositor fails to use a wl_buffer when the client has already > attached it to a wl_surface and it is time to repaint, it is too late > and the user will see a glitch. Recovering from that requires asking > the client to provide a new wl_buffer of a different kind, which might > take time. Or a very rude compositor would just send a protocol error, > and then we'd get bug reports like "the video player just disappears > when I try to play (and ps. I have an old kernel that doesn't support > importing whatever)". > > I believe we must allow the compositor to test the wl_buffer before it > is usable for the client. That is the reason for the roundtrippy > design > of the below proposal. > > > A central allocator would solve these issues, by having everyone agree > on the restrictions upfront, instead of working out which of the media > decode engine, camera, GPU, or display controller is the lowest common > denominator, and forcing all allocations through there. > > One such solution was discussed a while back WRT ION: > https://lwn.net/Articles/565469/ > <https://urldefense.proofpoint.com/v1/url?u=https://lwn.net/Articles/565469/…> > > See the 'possible solutions' part for a way for people to agree on > restrictions wrt tiling, stride, contiguousness, etc. Hi! I think before deciding on something like this, one needs also to account for the virtual drivers like vmwgfx. Here, a dma-buf internally holds an opaque handle to an object on the host / hypervisor, and the actual memory buffer is only temporarily allocated for dma-buf operations that strictly need it. Not to hold the data while transferring it between devices or applications. Let's say you'd want to use a USB display controller in a virtual machine with the vmwgfx exported prime objects, for example. There's no common denominator. The vmwgfx driver would need to read the dma-buf data from the host object at sg-table export (dma-buf map) time. Whereas if you just want to share data between a wayland server and client, no pages are ever allocated and the only thing passed around is in effect the opaque handle to the host / hypervisor object. I'm currently having trouble seeing how a central allocator would be able to deal with this? /Thomas > > Cheers, > Daniel > > > _______________________________________________ > wayland-devel mailing list > wayland-devel(a)lists.freedesktop.org > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mai…

10 years, 12 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig