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

[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hello again! Here is another update of the support for reserved memory regions in device tree. I've fixes a few more minor issues pointed by Grant. See changelog for more details. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog and links below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v6: - removed the need for "#memory-region-cells" property - fixed compilation issues on some systems - some other minor code cleanups v5: https://lkml.org/lkml/2014/2/21/147 - sliced main patch into several smaller patches on Grant's request - fixed coding style issues pointed by Grant - use node->phandle value directly instead of parsing properties manually v4: https://lkml.org/lkml/2014/2/20/150 - dynamic allocations are processed after all static reservations has been done - moved code for handling static reservations to drivers/of/fdt.c - removed node matching by string comparison, now phandle values are used directly - moved code for DMA and CMA handling directly to drivers/base/dma-{coherent,contiguous}.c - added checks for proper #size-cells, #address-cells, ranges properties in /reserved-memory node - even more code cleanup - added init code for ARM64 and PowerPC v3: http://article.gmane.org/gmane.linux.documentation/20169/ - refactored memory reservation code, created common code to parse reg, size, align, alloc-ranges properties - added support for multiple tuples in 'reg' property - memory is reserved regardless of presence of the driver for its compatible - prepared arch specific hooks for memory reservation (defaults use memblock calls) - removed node matching by string during device initialization - CMA init code: added checks for required region alignment - more code cleanup here and there v2: http://thread.gmane.org/gmane.linux.documentation/19870/ - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Marek Szyprowski (10): drivers: of: add initialization code for static reserved memory drivers: of: add initialization code for dynamic reserved memory drivers: of: add support for custom reserved memory drivers 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 arm: add support for reserved memory defined by device tree arm64: add support for reserved memory defined by device tree powerpc: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 136 ++++++++++ arch/arm/Kconfig | 1 + arch/arm/mm/init.c | 2 + arch/arm64/Kconfig | 1 + arch/arm64/mm/init.c | 1 + arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/prom.c | 3 + drivers/base/dma-coherent.c | 40 +++ drivers/base/dma-contiguous.c | 129 +++++++-- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/fdt.c | 140 ++++++++++ drivers/of/of_reserved_mem.c | 287 ++++++++++++++++++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/of_fdt.h | 3 + include/linux/of_reserved_mem.h | 60 ++++ 17 files changed, 807 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 2 months

3
19
0 0

[PATCH 0/6] dma-buf synchronization patches

by Maarten Lankhorst

The following series implements fence and converts dma-buf and android sync to use it. Patch 6 and 7 add support for polling to dma-buf, blocking until all fences are signaled. I've dropped the extra patch to copy an export from the core, and instead use the public version of it. I've had to fix some fallout from the rebase, hopefully everything's clean now, and ready for -next. --- Maarten Lankhorst (6): fence: dma-buf cross-device synchronization (v17) seqno-fence: Hardware dma-buf implementation of fencing (v4) dma-buf: use reservation objects android: convert sync to fence api, v3 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support, v2 Documentation/DocBook/device-drivers.tmpl | 3 drivers/base/Kconfig | 9 drivers/base/Makefile | 2 drivers/base/dma-buf.c | 123 +++ drivers/base/fence.c | 465 +++++++++++++ drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 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/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/sw_sync.c | 4 drivers/staging/android/sync.c | 892 ++++++++---------------- drivers/staging/android/sync.h | 80 +- drivers/staging/android/sync_debug.c | 245 +++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 2 include/linux/dma-buf.h | 21 - include/linux/fence.h | 329 +++++++++ include/linux/reservation.h | 18 include/linux/seqno-fence.h | 109 +++ include/trace/events/fence.h | 125 +++ 29 files changed, 1822 insertions(+), 657 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

11 years, 3 months

5
22
0 0

Re: [Linaro-mm-sig] [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)

by Maarten Lankhorst

op 17-02-14 19:41, Christian König schreef: > Am 17.02.2014 19:24, schrieb Rob Clark: >> On Mon, Feb 17, 2014 at 12:36 PM, Christian König >> <deathsimple(a)vodafone.de> wrote: >>> Am 17.02.2014 18:27, schrieb Rob Clark: >>> >>>> On Mon, Feb 17, 2014 at 11:56 AM, Christian König >>>> <deathsimple(a)vodafone.de> wrote: >>>>> Am 17.02.2014 16:56, schrieb Maarten Lankhorst: >>>>> >>>>>> This type of fence can be used with hardware synchronization for simple >>>>>> hardware that can block execution until the condition >>>>>> (dma_buf[offset] - value) >= 0 has been met. >>>>> >>>>> Can't we make that just "dma_buf[offset] != 0" instead? As far as I know >>>>> this way it would match the definition M$ uses in their WDDM >>>>> specification >>>>> and so make it much more likely that hardware supports it. >>>> well 'buf[offset] >= value' at least means the same slot can be used >>>> for multiple operations (with increasing values of 'value').. not sure >>>> if that is something people care about. >>>> >>>>> =value seems to be possible with adreno and radeon. I'm not really sure >>>>> about others (although I presume it as least supported for nv desktop >>>>> stuff). For hw that cannot do >=value, we can either have a different fence >>>>> implementation which uses the !=0 approach. Or change seqno-fence >>>>> implementation later if needed. But if someone has hw that can do !=0 but >>>>> not >=value, speak up now ;-) >>> >>> Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD >>> or VCE. And for the 3D engine it means draining the pipe, which isn't really >>> a good idea. >> hmm, ok.. forgot you have a few extra rings compared to me. Is UVD >> re-ordering from decode-order to display-order for you in hw? If not, >> I guess you need sw intervention anyways when a frame is done for >> frame re-ordering, so maybe hw->hw sync doesn't really matter as much >> as compared to gpu/3d->display. For dma<->3d interactions, seems like >> you would care more about hw<->hw sync, but I guess you aren't likely >> to use GPU A to do a resolve blit for GPU B.. > > No UVD isn't reordering, but since frame reordering is predictable you usually end up with pipelining everything to the hardware. E.g. you send the decode commands in decode order to the UVD block and if you have overlay active one of the frames are going to be the first to display and then you want to wait for it on the display side. > >> For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a >> CP_MEM_WRITE to update fence value in memory (for the one signalling >> the fence). But why would you need that before a CP_WAIT_REG_MEM (for >> the one waiting for the fence)? I don't exactly have documentation >> for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME >> appear to be same instruction set as r600, so I'm pretty sure they >> should have similar capabilities.. CP_WAIT_REG_MEM appears to be same >> but with 32bit gpu addresses vs 64b. > > You shouldn't use any of the CP commands for engine synchronization (neither for wait nor for signal). The PFP and ME are just the top of a quite deep pipeline and when you use any of the CP_WAIT functions you block them for something and that's draining the pipeline. > > With the semaphore and fence commands the values are just attached as prerequisite to the draw command, e.g. the CP setups the draw environment and issues the command, but the actual execution of it is delayed until the "!= 0" condition hits. And in the meantime the CP already prepares the next draw operation. > > But at least for compute queues wait semaphore aren't the perfect solution either. What you need then is a GPU scheduler that uses a kernel task for setting up the command submission for you when all prerequisites are meet. nouveau has sort of a scheduler in hardware. It can yield when waiting on a semaphore. And each process gets their own context and the timeslices can be adjusted. ;-) But I don't mind changing this patch when an actual user pops up. Nouveau can do a wait for (*sema & mask) != 0 only on nvc0 and newer, where mask can be chosen. But it can do == somevalue and >= somevalue on older relevant optimus hardware, so if we know that it was zero before and we know the sign of the new value that could work too. Adding ops and a separate mask later on when users pop up is fine with me, the original design here was chosen so I could map the intel status page read-only into the process specific nvidia vm. ~Maarten

11 years, 3 months

2
1
0 0

How to manage cached dmabuf importer private data?

by Hiroshi Doyu

Hi, We have a problem about how to manage cached dmabuf importer private data, where to keep, how to reuse and how to clean up. We want to keep some data in dmabuf importer side until an buffer is free'ed actually since a buffer can be reused again later in that importer subsystem so that that cache data doesn't have to be regenerated. This can be considered as some kind of caching this data. The scenario is: (1) Exporter passes a dmabuf to Importer. (2) Importer attaches a dev to a dmabuf. (3) Importer generates some data for a buffer for its own use. (4) Importer finishes its use of a buffer. (5) Importer detaches a dev from a dmabuf. (6) Again, Exporter passes a dmabuf fd to the same Importer. (7) Again, Importer attaches a dev to a dmabuf. (8) Importer wants to use the previously cached data from (2) without regenerating. (9) Again, Importer detaches a dev from a dmabuf. (10) Exporter free's a buffer along with a cached data from (2)/(8). At first I considered to use attachmenet private data, but apparently a life time of the attachment isn't equal to one of a buffer. A buffer lives longer than an attachment. Also Neither private data from dmabuf nor from attachment are for /Importer/. They are for Exporter's use from the comment in the header file. /** * struct dma_buf - shared buffer object .... * @priv: exporter specific private data for this buffer object. */ /** * struct dma_buf_attachment - holds device-buffer attachment data ... * @priv: exporter specific attachment data. ... */ This leads to the following 2 questions: One question is how to clean up the cached data at (10) since there's no way for Importer to trigger clean up at that time. I am considering to embed an /notifier/ in dmabuf when it's called at dmabuf release. Importer could register any callback in that notifier. At least this requires a dmabuf to have an notifier to be called at release. Does this sound acceptable? Or can we do the same outside of dmabuf framework? If there's more appropriate way, please let me know since I'm not so familier with drm side yet. Another question is where to keep that cached data. Usually that data is only valid within Impoter subsystem. So Imoporter could keep the list of that data in it as a global list along with a dmabuf pointer. When a dmabuf is imported, Importer can look up a global list if it's already cached. This list needs to be kept till a buffer is free'ed. Those can be implemented in the dmabuf exporter backend but we want to allow multiple allocators/exporters to do the same, and I want to avoid having something related to importer in exporter side. Any comment would be really appreciated.

11 years, 3 months

2
1
0 0

[PATCH v5 00/11] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hi all! Ok, I hope that this is the last update of the patches which add basic support for dynamic allocation of memory reserved regions defined in device tree. This time I've mainly sliced the main patch into several smaller pieces to make the changes easier to understand and fixes some minor coding style issues. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog and links below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v5: - sliced main patch into several smaller patches on Grant's request - fixed coding style issues pointed by Grant - use node->phandle value directly instead of parsing properties manually v4: https://lkml.org/lkml/2014/2/20/150 - dynamic allocations are processed after all static reservations has been done - moved code for handling static reservations to drivers/of/fdt.c - removed node matching by string comparison, now phandle values are used directly - moved code for DMA and CMA handling directly to drivers/base/dma-{coherent,contiguous}.c - added checks for proper #size-cells, #address-cells, ranges properties in /reserved-memory node - even more code cleanup - added init code for ARM64 and PowerPC v3: http://article.gmane.org/gmane.linux.documentation/20169/ - refactored memory reservation code, created common code to parse reg, size, align, alloc-ranges properties - added support for multiple tuples in 'reg' property - memory is reserved regardless of presence of the driver for its compatible - prepared arch specific hooks for memory reservation (defaults use memblock calls) - removed node matching by string during device initialization - CMA init code: added checks for required region alignment - more code cleanup here and there v2: http://thread.gmane.org/gmane.linux.documentation/19870/ - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Marek Szyprowski (10): drivers: of: add initialization code for static reserved memory drivers: of: add initialization code for dynamic reserved memory drivers: of: add support for custom reserved memory drivers 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 arm: add support for reserved memory defined by device tree arm64: add support for reserved memory defined by device tree powerpc: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++ arch/arm/Kconfig | 1 + arch/arm/mm/init.c | 2 + arch/arm64/Kconfig | 1 + arch/arm64/mm/init.c | 1 + arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/prom.c | 3 + drivers/base/dma-coherent.c | 41 +++ drivers/base/dma-contiguous.c | 130 +++++++-- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/fdt.c | 134 +++++++++ drivers/of/of_reserved_mem.c | 291 ++++++++++++++++++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/of_fdt.h | 3 + include/linux/of_reserved_mem.h | 61 ++++ 17 files changed, 810 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 3 months

3
20
0 0

Use of dma_buf_unmap_attachment in interrupt context?

by Hans Verkuil

A quick question: can dma_buf_unmap_attachment be called from interrupt context? It is the dmabuf equivalent to e.g. dma_sync_sg_for_cpu or dma_unmap_sg, and those can be called from interrupt context. I cannot see anything specific about this in the sources or dma-buf-sharing.txt. If it turns out that dma_buf_unmap_attachment can be called from atomic context, then that should be documented, I think. Regards, Hans

11 years, 3 months

1
0
0 0

CMA on AArch64

by Laura Abbott

Hi, I noticed there is currently no CMA support for AArch64. Is this already on someone's TODO list or is this still open? Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

11 years, 3 months

4
5
0 0

[PATCH 0/2] arm: dma-mapping: add dynamic resize of IOVA bitmap

by Marek Szyprowski

Hello, This patchset is a continuation of the work started by Andreas Herrmann to add support for dynamically resized bitmaps for IOMMU based DMA-mapping implementation for ARM architecture. Some more discussion and rationale has been discussed in the following thread: http://www.spinics.net/lists/arm-kernel/msg303732.html The first patch adds support for on-demand extending IO address space bitmap. It is based on the original work by Andreas Herrmann, but I decided to drop arm_iommu_create_mapping() api change part. The second patch removes the 'order' hack, which was used to reduce the size of a bitmap. The first patch solved the problem of too large io address space bitmaps, so the 'order' hack is no longer needed. The parameters of the arm_iommu_create_mapping() function can be then simplified by dropping 'order' parameter without any functional change of the whole subsystem. This parameter was already a bit misunderstood, so the overall result is also a little improvement of the API. Best regards Marek Szyprowski, PhD Samsung R&D Institute Poland Andreas Herrmann (1): arm: dma-mapping: Add support to extend DMA IOMMU mappings Marek Szyprowski (1): arm: dma-mapping: remove order parameter from arm_iommu_create_mapping() arch/arm/include/asm/dma-iommu.h | 12 ++- arch/arm/mm/dma-mapping.c | 144 +++++++++++++++++++++++------ drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_iommu.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 - drivers/iommu/shmobile-iommu.c | 2 +- 6 files changed, 124 insertions(+), 43 deletions(-) -- 1.7.9.5

11 years, 3 months

1
2
0 0

[PATCH v4 0/7] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hi all! This is another quick update of the patches which add basic support for dynamic allocation of memory reserved regions defined in device tree. This time I hope I've really managed to address all the issues reported by Grant Likely, see the change log for more details. As a bonus, I've added support for ARM64 and PowerPC, as those architectures had quite well defined place where early memory reservation can be done. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v4: - dynamic allocations are processed after all static reservations has been done - moved code for handling static reservations to drivers/of/fdt.c - removed node matching by string comparison, now phandle values are used directly - moved code for DMA and CMA handling directly to drivers/base/dma-{coherent,contiguous}.c - added checks for proper #size-cells, #address-cells, ranges properties in /reserved-memory node - even more code cleanup - added init code for ARM64 and PowerPC v3: http://article.gmane.org/gmane.linux.documentation/20169/ - refactored memory reservation code, created common code to parse reg, size, align, alloc-ranges properties - added support for multiple tuples in 'reg' property - memory is reserved regardless of presence of the driver for its compatible - prepared arch specific hooks for memory reservation (defaults use memblock calls) - removed node matching by string during device initialization - CMA init code: added checks for required region alignment - more code cleanup here and there v2: http://thread.gmane.org/gmane.linux.documentation/19870/ - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Marek Szyprowski (6): drivers: of: add initialization code for reserved memory drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree arm: add support for reserved memory defined by device tree arm64: add support for reserved memory defined by device tree powerpc: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 138 +++++++++ arch/arm/Kconfig | 1 + arch/arm/mm/init.c | 3 + arch/arm64/Kconfig | 1 + arch/arm64/mm/init.c | 2 + arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/prom.c | 3 + drivers/base/dma-coherent.c | 41 +++ drivers/base/dma-contiguous.c | 130 +++++++-- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/fdt.c | 145 ++++++++++ drivers/of/of_reserved_mem.c | 296 ++++++++++++++++++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/of_reserved_mem.h | 65 +++++ 16 files changed, 829 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 3 months

2
11
0 0

[PATCH v3 0/6] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hi all! This is yet another update of the second attempt to add basic support for dynamic allocation of memory reserved regions defined in device tree. This time I've tried to address all the issues reported by Grant Likely. The side-effect of it is a complete rewrite of memory reservation code, which results in added support for for multiple tuples in 'reg' property and complete support for 'size', 'align' and 'alloc-ranges' properties. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v3: - refactored memory reservation code, created common code to parse reg, size, align, alloc-ranges properties - added support for multiple tuples in 'reg' property - memory is reserved regardless of presence of the driver for its compatible - prepared arch specific hooks for memory reservation (defaults use memblock calls) - removed node matching by string during device initialization - CMA init code: added checks for required region alignment - more code cleanup here and there v2: http://thread.gmane.org/gmane.linux.documentation/19870/ - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Josh Cartwright (2): drivers: of: implement reserved-memory handling for dma drivers: of: implement reserved-memory handling for cma Marek Szyprowski (3): base: dma-contiguous: add dma_contiguous_init_reserved_mem() function drivers: of: add initialization code for reserved memory ARM: init: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 138 +++++++ arch/arm/Kconfig | 1 + arch/arm/mm/init.c | 3 + drivers/base/dma-contiguous.c | 70 ++-- drivers/of/Kconfig | 19 + drivers/of/Makefile | 3 + drivers/of/fdt.c | 2 + drivers/of/of_reserved_mem.c | 390 ++++++++++++++++++++ drivers/of/of_reserved_mem_cma.c | 68 ++++ drivers/of/of_reserved_mem_dma.c | 65 ++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/dma-contiguous.h | 7 + include/linux/of_reserved_mem.h | 65 ++++ 14 files changed, 827 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 drivers/of/of_reserved_mem_cma.c create mode 100644 drivers/of/of_reserved_mem_dma.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 3 months

2
11
0 0

Re: [Linaro-mm-sig] [PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)

by Rob Clark

On Mon, Feb 17, 2014 at 12:36 PM, Christian König <deathsimple(a)vodafone.de> wrote: > Am 17.02.2014 18:27, schrieb Rob Clark: > >> On Mon, Feb 17, 2014 at 11:56 AM, Christian König >> <deathsimple(a)vodafone.de> wrote: >>> >>> Am 17.02.2014 16:56, schrieb Maarten Lankhorst: >>> >>>> This type of fence can be used with hardware synchronization for simple >>>> hardware that can block execution until the condition >>>> (dma_buf[offset] - value) >= 0 has been met. >>> >>> >>> Can't we make that just "dma_buf[offset] != 0" instead? As far as I know >>> this way it would match the definition M$ uses in their WDDM >>> specification >>> and so make it much more likely that hardware supports it. >> >> well 'buf[offset] >= value' at least means the same slot can be used >> for multiple operations (with increasing values of 'value').. not sure >> if that is something people care about. >> >>> =value seems to be possible with adreno and radeon. I'm not really sure >>> about others (although I presume it as least supported for nv desktop >>> stuff). For hw that cannot do >=value, we can either have a different fence >>> implementation which uses the !=0 approach. Or change seqno-fence >>> implementation later if needed. But if someone has hw that can do !=0 but >>> not >=value, speak up now ;-) > > > Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD > or VCE. And for the 3D engine it means draining the pipe, which isn't really > a good idea. hmm, ok.. forgot you have a few extra rings compared to me. Is UVD re-ordering from decode-order to display-order for you in hw? If not, I guess you need sw intervention anyways when a frame is done for frame re-ordering, so maybe hw->hw sync doesn't really matter as much as compared to gpu/3d->display. For dma<->3d interactions, seems like you would care more about hw<->hw sync, but I guess you aren't likely to use GPU A to do a resolve blit for GPU B.. For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a CP_MEM_WRITE to update fence value in memory (for the one signalling the fence). But why would you need that before a CP_WAIT_REG_MEM (for the one waiting for the fence)? I don't exactly have documentation for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME appear to be same instruction set as r600, so I'm pretty sure they should have similar capabilities.. CP_WAIT_REG_MEM appears to be same but with 32bit gpu addresses vs 64b. BR, -R > Christian. > > >> >>> Apart from that I still don't like the idea of leaking a drivers IRQ >>> context >>> outside of the driver, but without a proper GPU scheduler there probably >>> isn't much alternative. >> >> I guess it will be not uncommon scenario for gpu device to just need >> to kick display device to write a few registers for a page flip.. >> probably best not to schedule a worker just for this (unless the >> signalled device otherwise needs to). I think it is better in this >> case to give the signalee some rope to hang themselves, and make it >> the responsibility of the callback to kick things off to a worker if >> needed. >> >> BR, >> -R >> >>> Christian. >>> >>>> A software fallback still has to be provided in case the fence is used >>>> with a device that doesn't support this mechanism. It is useful to >>>> expose >>>> this for graphics cards that have an op to support this. >>>> >>>> Some cards like i915 can export those, but don't have an option to wait, >>>> so they need the software fallback. >>>> >>>> I extended the original patch by Rob Clark. >>>> >>>> v1: Original >>>> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since >>>> not much was left of the file. Lots of documentation added. >>>> v3: Use fence_ops instead of custom callbacks. Moved to own file >>>> to avoid circular dependency between dma-buf.h and fence.h >>>> v4: Add spinlock pointer to seqno_fence_init >>>> >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> >>>> --- >>>> Documentation/DocBook/device-drivers.tmpl | 1 >>>> drivers/base/fence.c | 50 +++++++++++++ >>>> include/linux/seqno-fence.h | 109 >>>> +++++++++++++++++++++++++++++ >>>> 3 files changed, 160 insertions(+) >>>> create mode 100644 include/linux/seqno-fence.h >>>> >>>> diff --git a/Documentation/DocBook/device-drivers.tmpl >>>> b/Documentation/DocBook/device-drivers.tmpl >>>> index 7a0c9ddb4818..8c85c20942c2 100644 >>>> --- a/Documentation/DocBook/device-drivers.tmpl >>>> +++ b/Documentation/DocBook/device-drivers.tmpl >>>> @@ -131,6 +131,7 @@ X!Edrivers/base/interface.c >>>> !Edrivers/base/dma-buf.c >>>> !Edrivers/base/fence.c >>>> !Iinclude/linux/fence.h >>>> +!Iinclude/linux/seqno-fence.h >>>> !Edrivers/base/reservation.c >>>> !Iinclude/linux/reservation.h >>>> !Edrivers/base/dma-coherent.c >>>> diff --git a/drivers/base/fence.c b/drivers/base/fence.c >>>> index 12df2bf62034..cd0937127a89 100644 >>>> --- a/drivers/base/fence.c >>>> +++ b/drivers/base/fence.c >>>> @@ -25,6 +25,7 @@ >>>> #include <linux/export.h> >>>> #include <linux/atomic.h> >>>> #include <linux/fence.h> >>>> +#include <linux/seqno-fence.h> >>>> #define CREATE_TRACE_POINTS >>>> #include <trace/events/fence.h> >>>> @@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct >>>> fence_ops *ops, >>>> trace_fence_init(fence); >>>> } >>>> EXPORT_SYMBOL(__fence_init); >>>> + >>>> +static const char *seqno_fence_get_driver_name(struct fence *fence) { >>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence); >>>> + return seqno_fence->ops->get_driver_name(fence); >>>> +} >>>> + >>>> +static const char *seqno_fence_get_timeline_name(struct fence *fence) { >>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence); >>>> + return seqno_fence->ops->get_timeline_name(fence); >>>> +} >>>> + >>>> +static bool seqno_enable_signaling(struct fence *fence) >>>> +{ >>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence); >>>> + return seqno_fence->ops->enable_signaling(fence); >>>> +} >>>> + >>>> +static bool seqno_signaled(struct fence *fence) >>>> +{ >>>> + struct seqno_fence *seqno_fence = to_seqno_fence(fence); >>>> + return seqno_fence->ops->signaled && >>>> seqno_fence->ops->signaled(fence); >>>> +} >>>> + >>>> +static void seqno_release(struct fence *fence) >>>> +{ >>>> + struct seqno_fence *f = to_seqno_fence(fence); >>>> + >>>> + dma_buf_put(f->sync_buf); >>>> + if (f->ops->release) >>>> + f->ops->release(fence); >>>> + else >>>> + kfree(f); >>>> +} >>>> + >>>> +static long seqno_wait(struct fence *fence, bool intr, signed long >>>> timeout) >>>> +{ >>>> + struct seqno_fence *f = to_seqno_fence(fence); >>>> + return f->ops->wait(fence, intr, timeout); >>>> +} >>>> + >>>> +const struct fence_ops seqno_fence_ops = { >>>> + .get_driver_name = seqno_fence_get_driver_name, >>>> + .get_timeline_name = seqno_fence_get_timeline_name, >>>> + .enable_signaling = seqno_enable_signaling, >>>> + .signaled = seqno_signaled, >>>> + .wait = seqno_wait, >>>> + .release = seqno_release, >>>> +}; >>>> +EXPORT_SYMBOL(seqno_fence_ops); >>>> diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h >>>> new file mode 100644 >>>> index 000000000000..952f7909128c >>>> --- /dev/null >>>> +++ b/include/linux/seqno-fence.h >>>> @@ -0,0 +1,109 @@ >>>> +/* >>>> + * seqno-fence, using a dma-buf to synchronize fencing >>>> + * >>>> + * Copyright (C) 2012 Texas Instruments >>>> + * Copyright (C) 2012 Canonical Ltd >>>> + * Authors: >>>> + * Rob Clark <robdclark(a)gmail.com> >>>> + * Maarten Lankhorst <maarten.lankhorst(a)canonical.com> >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> it >>>> + * under the terms of the GNU General Public License version 2 as >>>> published by >>>> + * the Free Software Foundation. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY >>>> or >>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>> License >>>> for >>>> + * more details. >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> along with >>>> + * this program. If not, see <http://www.gnu.org/licenses/>. >>>> + */ >>>> + >>>> +#ifndef __LINUX_SEQNO_FENCE_H >>>> +#define __LINUX_SEQNO_FENCE_H >>>> + >>>> +#include <linux/fence.h> >>>> +#include <linux/dma-buf.h> >>>> + >>>> +struct seqno_fence { >>>> + struct fence base; >>>> + >>>> + const struct fence_ops *ops; >>>> + struct dma_buf *sync_buf; >>>> + uint32_t seqno_ofs; >>>> +}; >>>> + >>>> +extern const struct fence_ops seqno_fence_ops; >>>> + >>>> +/** >>>> + * to_seqno_fence - cast a fence to a seqno_fence >>>> + * @fence: fence to cast to a seqno_fence >>>> + * >>>> + * Returns NULL if the fence is not a seqno_fence, >>>> + * or the seqno_fence otherwise. >>>> + */ >>>> +static inline struct seqno_fence * >>>> +to_seqno_fence(struct fence *fence) >>>> +{ >>>> + if (fence->ops != &seqno_fence_ops) >>>> + return NULL; >>>> + return container_of(fence, struct seqno_fence, base); >>>> +} >>>> + >>>> +/** >>>> + * seqno_fence_init - initialize a seqno fence >>>> + * @fence: seqno_fence to initialize >>>> + * @lock: pointer to spinlock to use for fence >>>> + * @sync_buf: buffer containing the memory location to signal on >>>> + * @context: the execution context this fence is a part of >>>> + * @seqno_ofs: the offset within @sync_buf >>>> + * @seqno: the sequence # to signal on >>>> + * @ops: the fence_ops for operations on this seqno fence >>>> + * >>>> + * This function initializes a struct seqno_fence with passed >>>> parameters, >>>> + * and takes a reference on sync_buf which is released on fence >>>> destruction. >>>> + * >>>> + * A seqno_fence is a dma_fence which can complete in software when >>>> + * enable_signaling is called, but it also completes when >>>> + * (s32)((sync_buf)[seqno_ofs] - seqno) >= 0 is true >>>> + * >>>> + * The seqno_fence will take a refcount on the sync_buf until it's >>>> + * destroyed, but actual lifetime of sync_buf may be longer if one of >>>> the >>>> + * callers take a reference to it. >>>> + * >>>> + * Certain hardware have instructions to insert this type of wait >>>> condition >>>> + * in the command stream, so no intervention from software would be >>>> needed. >>>> + * This type of fence can be destroyed before completed, however a >>>> reference >>>> + * on the sync_buf dma-buf can be taken. It is encouraged to re-use the >>>> same >>>> + * dma-buf for sync_buf, since mapping or unmapping the sync_buf to the >>>> + * device's vm can be expensive. >>>> + * >>>> + * It is recommended for creators of seqno_fence to call fence_signal >>>> + * before destruction. This will prevent possible issues from >>>> wraparound >>>> at >>>> + * time of issue vs time of check, since users can check >>>> fence_is_signaled >>>> + * before submitting instructions for the hardware to wait on the >>>> fence. >>>> + * However, when ops.enable_signaling is not called, it doesn't have to >>>> be >>>> + * done as soon as possible, just before there's any real danger of >>>> seqno >>>> + * wraparound. >>>> + */ >>>> +static inline void >>>> +seqno_fence_init(struct seqno_fence *fence, spinlock_t *lock, >>>> + struct dma_buf *sync_buf, uint32_t context, uint32_t >>>> seqno_ofs, >>>> + uint32_t seqno, const struct fence_ops *ops) >>>> +{ >>>> + BUG_ON(!fence || !sync_buf || !ops); >>>> + BUG_ON(!ops->wait || !ops->enable_signaling || >>>> !ops->get_driver_name || !ops->get_timeline_name); >>>> + >>>> + /* >>>> + * ops is used in __fence_init for get_driver_name, so needs to >>>> be >>>> + * initialized first >>>> + */ >>>> + fence->ops = ops; >>>> + __fence_init(&fence->base, &seqno_fence_ops, lock, context, >>>> seqno); >>>> + get_dma_buf(sync_buf); >>>> + fence->sync_buf = sync_buf; >>>> + fence->seqno_ofs = seqno_ofs; >>>> +} >>>> + >>>> +#endif /* __LINUX_SEQNO_FENCE_H */ >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel(a)lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel(a)lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > >

11 years, 3 months

1
0
0 0

[PATCH v2 0/5] reserved-memory regions/CMA in devicetree, again

by Marek Szyprowski

Hi all! This is an updated version of the second attempt to add basic support for dynamic allocation of memory reserved regions defined in device tree. The initial code for this feature were posted here [1], merged as commit 9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add initialization code for dma reserved memory") and later reverted by commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information, see [2]. Finally a new bindings has been proposed [3] and Josh Cartwright a few days ago prepared some code which implements those bindings [4]. This finally pushed me again to find some time to finish this task and review the code. Josh agreed to give me the ownership of this series to continue preparing them for mainline inclusion. For more information please refer to the changlelog below. [1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski@sams… [2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski@sam… [3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca [4]: http://thread.gmane.org/gmane.linux.documentation/19579 Changelog: v2: - removed copying of the node name - split shared-dma-pool handling into separate files (one for CMA and one for dma_declare_coherent based implementations) for making the code easier to understand - added support for AMBA devices, changed prototypes to use struct decice instead of struct platform_device - renamed some functions to better match other names used in drivers/of/ - restructured the rest of the code a bit for better readability - added 'reusable' property to exmaple linux,cma node in documentation - exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool' regions without 'reusable' property and CMA is used only for handling 'shared-dma-pool' regions with 'reusable' property. v1: http://thread.gmane.org/gmane.linux.documentation/19579 - initial version prepared by Josh Cartwright Summary: Grant Likely (1): of: document bindings for reserved-memory nodes Josh Cartwright (2): drivers: of: implement reserved-memory handling for dma drivers: of: implement reserved-memory handling for cma Marek Szyprowski (2): drivers: of: add initialization code for reserved memory ARM: init: add support for reserved memory defined by device tree .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++ arch/arm/mm/init.c | 3 + drivers/of/Kconfig | 20 ++ drivers/of/Makefile | 3 + drivers/of/of_reserved_mem.c | 219 ++++++++++++++++++++ drivers/of/of_reserved_mem_cma.c | 75 +++++++ drivers/of/of_reserved_mem_dma.c | 78 +++++++ drivers/of/platform.c | 7 + include/asm-generic/vmlinux.lds.h | 11 + include/linux/of_reserved_mem.h | 62 ++++++ 10 files changed, 616 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt create mode 100644 drivers/of/of_reserved_mem.c create mode 100644 drivers/of/of_reserved_mem_cma.c create mode 100644 drivers/of/of_reserved_mem_dma.c create mode 100644 include/linux/of_reserved_mem.h -- 1.7.9.5

11 years, 3 months

7
26
0 0

[GIT PULL]: dma-buf updates for 3.14

by Sumit Semwal

Hi Linus, Here's another tiny pull request for dma-buf framework updates; just some debugfs output updates. (There's another patch related to dma-buf, but it'll get upstreamed via Greg-kh's pull request). Could you please pull? The following changes since commit 45f7fdc2ffb9d5af4dab593843e89da70d1259e3: Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2014-02-11 22:28:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-3.14 for you to fetch changes up to c0b00a525c127d0055c1df6283300e17f601a1a1: dma-buf: update debugfs output (2014-02-13 10:08:52 +0530) ---------------------------------------------------------------- Small dma-buf pull request for 3.14 ---------------------------------------------------------------- Sumit Semwal (1): dma-buf: update debugfs output drivers/base/dma-buf.c | 25 ++++++++++++------------- include/linux/dma-buf.h | 2 +- 2 files changed, 13 insertions(+), 14 deletions(-)

11 years, 3 months

1
0
0 0

KSM and Android

by Pradeep Sawlani

Hello, In pursuit of saving memory on Android, I started experimenting with Kernel Same Page Merging(KSM). Number of pages shared because of KSM is reported by /sys/kernel/mm/pages_sharing. Documentation/vm/ksm.txt explains this as: "pages_sharing - how many more sites are sharing them i.e. how much saved" After enabling KSM on Android device, this number was reported as 19666 pages. Obvious optimization is to find out source of sharing and see if we can avoid duplicate pages at first place. In order to collect the data needed, It needed few modifications(trace_printk) statement in mm/ksm.c. Data should be collected from second cycle because that's when ksm starts merging pages. First KSM cycle is only used to calculate the checksum, pages are added to unstable tree and eventually moved to stable tree after this. After analyzing data from second KSM cycle, few things which stood out: 1. In the same cycle, KSM can scan same page multiple times. Scanning a page involves comparing page with pages in stable tree, if no match is found checksum is calculated. From the look of it, it seems to be cpu intensive operation and impacts dcache as well. 2. Same page which is already shared by multiple process can be replaced by KSM page. In this case, let say a particular page is mapped 24 times and is replaced by KSM page then eventually all 24 entries will point to KSM page. pages_sharing will account for all 24 pages. so pages _sharing does not actually report amount of memory saved.From the above example actual savings is one page. Both cases happen very often with Android because of its architecture - Zygote spawning(fork) multipleapplications. To calculate actual savings, we should account for same page(pfn)replaced by same KSM page only once. In the case 2 example, page_sharing should account only one page.After recalculating memory saving comes out to be 8602 pages (~34MB). I am trying to find out right solution to fix pages_sharing and eventually optimize KSM to scan pageonce even if it is mapped multiple times. Comments? Has anyone tried this before? Thanks, Pradeep

11 years, 3 months

2
2
0 0

[PATCH] dma-buf: avoid using IS_ERR_OR_NULL

by Colin Cross

dma_buf_map_attachment and dma_buf_vmap can return NULL or ERR_PTR on a error. This encourages a common buggy pattern in callers: sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); if (IS_ERR_OR_NULL(sgt)) return PTR_ERR(sgt); This causes the caller to return 0 on an error. IS_ERR_OR_NULL is almost always a sign of poorly-defined error handling. This patch converts dma_buf_map_attachment to always return ERR_PTR, and fixes the callers that incorrectly handled NULL. There are a few more callers that were not checking for NULL at all, which would have dereferenced a NULL pointer later. There are also a few more callers that correctly handled NULL and ERR_PTR differently, I left those alone but they could also be modified to delete the NULL check. This patch also converts dma_buf_vmap to always return NULL. All the callers to dma_buf_vmap only check for NULL, and would have dereferenced an ERR_PTR and panic'd if one was ever returned. This is not consistent with the rest of the dma buf APIs, but matches the expectations of all of the callers. Signed-off-by: Colin Cross <ccross(a)android.com> --- drivers/base/dma-buf.c | 18 +++++++++++------- drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +- 4 files changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 1e16cbd61da2..cfe1d8bc7bb8 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * @dmabuf: [in] buffer to attach device to. * @dev: [in] device to be attached. * - * Returns struct dma_buf_attachment * for this attachment; may return negative - * error codes. - * + * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR on + * error. */ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev) @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach); * @attach: [in] attachment whose scatterlist is to be returned * @direction: [in] direction of DMA transfer * - * Returns sg_table containing the scatterlist to be returned; may return NULL - * or ERR_PTR. - * + * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR + * on error. */ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, enum dma_data_direction direction) @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return ERR_PTR(-EINVAL); sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + if (!sg_table) + sg_table = ERR_PTR(-ENOMEM); return sg_table; } @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap); * These calls are optional in drivers. The intended use for them * is for mapping objects linear in kernel space for high use objects. * Please attempt to use kmap/kunmap before thinking about these interfaces. + * + * Returns NULL on error. */ void *dma_buf_vmap(struct dma_buf *dmabuf) { @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf) BUG_ON(dmabuf->vmap_ptr); ptr = dmabuf->ops->vmap(dmabuf); - if (IS_ERR_OR_NULL(ptr)) + if (WARN_ON_ONCE(IS_ERR(ptr))) + ptr = NULL; + if (!ptr) goto out_unlock; dmabuf->vmap_ptr = ptr; diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 56805c39c906..bb516fdd195d 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -471,7 +471,7 @@ struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev, get_dma_buf(dma_buf); sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); goto fail_detach; } diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index 59827cc5e770..c786cd4f457b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c @@ -224,7 +224,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev, get_dma_buf(dma_buf); sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); goto err_buf_detach; } diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 33d3871d1e13..880be0782dd9 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -719,7 +719,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv) /* get the associated scatterlist for this buffer */ sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir); - if (IS_ERR_OR_NULL(sgt)) { + if (IS_ERR(sgt)) { pr_err("Error getting dmabuf scatterlist\n"); return -EINVAL; } -- 1.8.5.1

11 years, 4 months

4
5
0 0

IOMMU DMA-mapping API for arm64 ?

by Ritesh Harjani

Hi everyone, I tried looking for IOMMU support in ARM64 but what I was able to see is only swiotlb is currently supported. Based on my understanding for IOMMU support, we need DMA-MAPPING API to have IOMMU ops field, similar to what is present in arm32. I could see the iommu field added in dev_archdata in below mentioned patch (arch/arm64/include/asm/device.h), but there is no ops field in arch/arm64/mm/dma-mapping.c ? I also saw one mail discussion between you guys on what is the best place for adding iommu support in ARM64, but couldn't see any followed up patches for the same. Please tell us the current status/updates on the same. Your feedback will be greatly appreciated. commit 73150c983ac1f9b7653cfd3823b1ad4a44aad3bf Author: Will Deacon <will.deacon(a)arm.com> Date: Mon Jun 10 19:34:42 2013 +0100 arm64: device: add iommu pointer to device archdata When using an IOMMU for device mappings, it is necessary to keep a pointer between the device and the IOMMU to which it is attached in order to obtain the correct IOMMU when attaching the device to a domain. This patch adds an iommu pointer to the dev_archdata structure, in a similar manner to other architectures (ARM, PowerPC, x86, ...). Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Thanks Ritesh

11 years, 4 months

2
1
0 0

[PATCH] dma-buf: update debugfs output

by Sumit Semwal

Russell King observed 'wierd' looking output from debugfs, and also suggested better ways of getting device names (use KBUILD_MODNAME, dev_name()) This patch addresses these issues to make the debugfs output correct and better looking. Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- drivers/base/dma-buf.c | 18 ++++++++---------- include/linux/dma-buf.h | 2 +- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index cfe1d8b..bf89fe3 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -621,7 +621,7 @@ static int dma_buf_describe(struct seq_file *s) return ret; seq_printf(s, "\nDma-buf Objects:\n"); - seq_printf(s, "\texp_name\tsize\tflags\tmode\tcount\n"); + seq_printf(s, "size\tflags\tmode\tcount\texp_name\n"); list_for_each_entry(buf_obj, &db_list.head, list_node) { ret = mutex_lock_interruptible(&buf_obj->lock); @@ -632,24 +632,22 @@ static int dma_buf_describe(struct seq_file *s) continue; } - seq_printf(s, "\t"); - - seq_printf(s, "\t%s\t%08zu\t%08x\t%08x\t%08ld\n", - buf_obj->exp_name, buf_obj->size, + seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n", + buf_obj->size, buf_obj->file->f_flags, buf_obj->file->f_mode, - (long)(buf_obj->file->f_count.counter)); + (long)(buf_obj->file->f_count.counter), buf_obj->exp_name); - seq_printf(s, "\t\tAttached Devices:\n"); + seq_printf(s, "\tAttached Devices:\n"); attach_count = 0; list_for_each_entry(attach_obj, &buf_obj->attachments, node) { - seq_printf(s, "\t\t"); + seq_printf(s, "\t"); - seq_printf(s, "%s\n", attach_obj->dev->init_name); + seq_printf(s, "%s\n", dev_name(attach_obj->dev)); attach_count++; } - seq_printf(s, "\n\t\tTotal %d devices attached\n", + seq_printf(s, "\nTotal %d devices attached\n", attach_count); count++; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index dfac5ed..f886985 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -171,7 +171,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, size_t size, int flags, const char *); #define dma_buf_export(priv, ops, size, flags) \ - dma_buf_export_named(priv, ops, size, flags, __FILE__) + dma_buf_export_named(priv, ops, size, flags, KBUILD_MODNAME) int dma_buf_fd(struct dma_buf *dmabuf, int flags); struct dma_buf *dma_buf_get(int fd); -- 1.8.3.2

11 years, 4 months

1
0
0 0

[PATCH 0/7] dma-buf synchronization patches

by Maarten Lankhorst

The following series implements fence and converts dma-buf and android sync to use it. Patch 6 and 7 add support for polling to dma-buf, blocking until all fences are signaled. --- Maarten Lankhorst (7): sched: allow try_to_wake_up to be used internally outside of core.c fence: dma-buf cross-device synchronization (v16) seqno-fence: Hardware dma-buf implementation of fencing (v4) dma-buf: use reservation objects android: convert sync to fence api, v3 reservation: add support for fences to enable cross-device synchronisation dma-buf: add poll support Documentation/DocBook/device-drivers.tmpl | 3 drivers/base/Kconfig | 9 drivers/base/Makefile | 2 drivers/base/dma-buf.c | 124 +++ drivers/base/fence.c | 465 ++++++++++++ drivers/gpu/drm/drm_prime.c | 8 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 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/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/sw_sync.c | 4 drivers/staging/android/sync.c | 895 ++++++++---------------- drivers/staging/android/sync.h | 85 +- drivers/staging/android/sync_debug.c | 245 +++++++ drivers/staging/android/trace/sync.h | 12 include/drm/drmP.h | 2 include/linux/dma-buf.h | 21 - include/linux/fence.h | 329 +++++++++ include/linux/reservation.h | 18 include/linux/seqno-fence.h | 109 +++ include/linux/wait.h | 1 include/trace/events/fence.h | 125 +++ kernel/sched/core.c | 2 31 files changed, 1825 insertions(+), 666 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

11 years, 4 months

3
10
0 0

[RFC] dma-mapping: Provide write-combine allocations

by Thierry Reding

Provide an implementation for dma_{alloc,free}_writecombine() when the architecture supports DMA attributes. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- arch/arm/include/asm/dma-mapping.h | 16 ---------------- include/linux/dma-mapping.h | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index e701a4d9aa59..96b7634a7edc 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -242,22 +242,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/linux/dma-mapping.h b/include/linux/dma-mapping.h index fd4aee29ad10..8475e02b4bd1 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -249,6 +249,22 @@ 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); +} #endif /* CONFIG_HAVE_DMA_ATTRS */ #ifdef CONFIG_NEED_DMA_MAP_STATE -- 1.8.4.2

11 years, 4 months

2
1
0 0

[PATCH v4 0/3] Add support of dmabuf in wayland/weston

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> The goal of this serie of patches is to add a way to use dmabuf file descriptor inside wayland and weston. In a context where there is no Mesa EGL (and so no wl_drm protocol) wl_dmabuf could be used as an alternative to shm to share buffers between hardware devices. If your hardware device (video decoder, renderer, etc...) need physical contiguous memory (obviously don't have MMU) wl_dmabuf may save the cost of one copy compare to shm. shm case: videodecoder --(copy into shm_buffer)--> weston(+pixman) --> HW renderer dmabuf case: videodecoder --(directly write in dmabuf buffer)--> weston(+pixman) --> HW renderer The server is responsible to send its supported pixel formats and the device name to be used by the client to allocate buffers. While mmap() call on dmabuf file descriptor result isn't guaranty on all architectures both server and client should take care of it before accessing to buffer data to avoid segfault. This series of patches include wayland and weston modifications. An example of how use wl_dmabuf is provided in weston/clients/simple-dmabuf.c === Wayland === Benjamin Gaignard (1): Add wl_dmabuf protocol protocol/Makefile.am | 6 +- protocol/wayland-dmabuf.xml | 128 ++++++++++++++++++++++++ src/Makefile.am | 12 ++- src/wayland-dmabuf.c | 231 +++++++++++++++++++++++++++++++++++++++++++ src/wayland-dmabuf.h | 123 +++++++++++++++++++++++ 5 files changed, 496 insertions(+), 4 deletions(-) create mode 100644 protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c create mode 100644 src/wayland-dmabuf.h === Weston === Benjamin Gaignard (2): compositor-drm: allow to be a wl_dmabuf server add simple-dmabuf client clients/Makefile.am | 11 ++ clients/simple-dmabuf.c | 469 +++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 5 + src/compositor-drm.c | 83 ++++++++- src/compositor.c | 4 +- src/compositor.h | 2 + src/pixman-renderer.c | 93 +++++++--- 7 files changed, 637 insertions(+), 30 deletions(-) create mode 100644 clients/simple-dmabuf.c -- 1.7.9.5

11 years, 4 months

6
13
0 0

Specifying subrect properties in dma-buf

by Sundareson, Prabindh

Hello all, I have an use-case, where a buffer "B" needs to be further operated upon by an additional operator (ex, CPU or 2D HW). The further operation is typically in smaller subrects of "B". While looking through the dma-buf API, I do not see a way by which I can specify properties of subrects in a buffer which can be specified as "read-only" to one user of the buffer, while the other user can go ahead and update it. If we have this mechanism, we can do below steps to reduce latency of locking/waiting for one full buffer update, and then making it available to the next consumer. (1) Create dma-buf using usual methods (2) Exported to 2 users - ex GPU, and 2D HW (3) GPU updates specific subrects (4) 2D HW updates specific subrects (5) When both (3) and (4) are complete, the buffer is available to next consumer. Since (3) and (4) can run in parallel, latency can be reduced. If there is a way by which this can already be done, I would appreciate if someone can point me to it. regards Prabindh

11 years, 5 months

2
2
0 0

[PATCH v3] Add support of dmabuf in wayland/weston

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> The goal of this serie of patches is to add a way to use dmabuf file descriptor inside wayland and weston. In a context where there is no Mesa EGL (and so no wl_drm protocol) wl_dmabuf could be used as an alternative to shm to share buffers between hardware devices. If your hardware device (video decoder, renderer, etc...) need physical contiguous memory (obviously don't have MMU) wl_dmabuf may save the cost of one copy compare to shm. shm case: videodecoder --(copy into shm_buffer)--> weston(+pixman) --> HW renderer dmabuf case: videodecoder --(directly write in dmabuf buffer)--> weston(+pixman) --> HW renderer The server is responsible to send its supported pixel formats and the device name to be used by the client to allocate buffers. While mmap() call on dmabuf file descriptor result isn't guaranty on all architectures both server and client should take care of it before accessing to buffer data to avoid segfault. === Wayland === Benjamin Gaignard (1): Add wl_dmabuf protocol protocol/Makefile.am | 6 +- protocol/wayland-dmabuf.xml | 133 +++++++++++++++++++++ src/Makefile.am | 12 +- src/wayland-dmabuf.c | 279 +++++++++++++++++++++++++++++++++++++++++++ src/wayland-dmabuf.h | 136 +++++++++++++++++++++ 5 files changed, 562 insertions(+), 4 deletions(-) create mode 100644 protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c create mode 100644 src/wayland-dmabuf.h === Weston === Benjamin Gaignard (1): compositor-drm: allow to be a wl_dmabuf server src/compositor-drm.c | 168 +++++++++++++++++++++++++++++++++++++++++++++++-- src/compositor.c | 4 +- src/compositor.h | 2 + src/pixman-renderer.c | 86 ++++++++++++++++++------- 4 files changed, 230 insertions(+), 30 deletions(-) -- 1.7.9.5

11 years, 5 months

1
2
0 0

[PATCH] Add wl_dmabuf protocol

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> It allow to use a dmabuf file descriptor in a wayland protocol. To make as generic as possible it is up to the server to call wl_dmabuf_send_format() and/or wl_dmabuf_send_capabilities() to signal it capabilities. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- protocol/Makefile.am | 6 +- protocol/wayland-dmabuf.xml | 134 +++++++++++++++++++++ src/Makefile.am | 12 +- src/wayland-dmabuf.c | 275 +++++++++++++++++++++++++++++++++++++++++++ src/wayland-dmabuf.h | 134 +++++++++++++++++++++ 5 files changed, 557 insertions(+), 4 deletions(-) create mode 100644 protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c create mode 100644 src/wayland-dmabuf.h diff --git a/protocol/Makefile.am b/protocol/Makefile.am index e8b6290..8c9499f 100644 --- a/protocol/Makefile.am +++ b/protocol/Makefile.am @@ -1,4 +1,4 @@ -dist_pkgdata_DATA = wayland.xml wayland.dtd +dist_pkgdata_DATA = wayland.xml wayland-dmabuf.xml wayland.dtd if HAVE_XMLLINT .PHONY: validate @@ -6,9 +6,9 @@ if HAVE_XMLLINT .%.xml.valid: %.xml $(AM_V_GEN)$(XMLLINT) --noout --dtdvalid $(srcdir)/wayland.dtd $^ > $@ -validate: .wayland.xml.valid +validate: .wayland.xml.valid .wayland-dmabuf.xml.valid all-local: validate -CLEANFILES = .wayland.xml.valid +CLEANFILES = .wayland.xml.valid .wayland-dmabuf.xml.valid endif diff --git a/protocol/wayland-dmabuf.xml b/protocol/wayland-dmabuf.xml new file mode 100644 index 0000000..b3b7ded --- /dev/null +++ b/protocol/wayland-dmabuf.xml @@ -0,0 +1,134 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="dmabuf"> + + <copyright> + Copyright © 2008-2011 Kristian Høgsberg + Copyright © 2010-2011 Intel Corporation + + Permission to use, copy, modify, distribute, and sell this + software and its documentation for any purpose is hereby granted + without fee, provided that\n the above copyright notice appear in + all copies and that both that copyright notice and this permission + notice appear in supporting documentation, and that the name of + the copyright holders not be used in advertising or publicity + pertaining to distribution of the software without specific, + written prior permission. The copyright holders make no + representations about the suitability of this software for any + purpose. It is provided "as is" without express or implied + warranty. + + THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS + SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY + SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, + ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF + THIS SOFTWARE. + </copyright> + +  + <interface name="wl_dmabuf" version="1"> + <enum name="error"> + <entry name="invalid_format" value="1"/> + <entry name="invalid_file_descriptor" value="2"/> + </enum> + + <enum name="format"> +  + <entry name="c8" value="0x20203843"/> + <entry name="rgb332" value="0x38424752"/> + <entry name="bgr233" value="0x38524742"/> + <entry name="xrgb4444" value="0x32315258"/> + <entry name="xbgr4444" value="0x32314258"/> + <entry name="rgbx4444" value="0x32315852"/> + <entry name="bgrx4444" value="0x32315842"/> + <entry name="argb4444" value="0x32315241"/> + <entry name="abgr4444" value="0x32314241"/> + <entry name="rgba4444" value="0x32314152"/> + <entry name="bgra4444" value="0x32314142"/> + <entry name="xrgb1555" value="0x35315258"/> + <entry name="xbgr1555" value="0x35314258"/> + <entry name="rgbx5551" value="0x35315852"/> + <entry name="bgrx5551" value="0x35315842"/> + <entry name="argb1555" value="0x35315241"/> + <entry name="abgr1555" value="0x35314241"/> + <entry name="rgba5551" value="0x35314152"/> + <entry name="bgra5551" value="0x35314142"/> + <entry name="rgb565" value="0x36314752"/> + <entry name="bgr565" value="0x36314742"/> + <entry name="rgb888" value="0x34324752"/> + <entry name="bgr888" value="0x34324742"/> + <entry name="xrgb8888" value="0x34325258"/> + <entry name="xbgr8888" value="0x34324258"/> + <entry name="rgbx8888" value="0x34325852"/> + <entry name="bgrx8888" value="0x34325842"/> + <entry name="argb8888" value="0x34325241"/> + <entry name="abgr8888" value="0x34324241"/> + <entry name="rgba8888" value="0x34324152"/> + <entry name="bgra8888" value="0x34324142"/> + <entry name="xrgb2101010" value="0x30335258"/> + <entry name="xbgr2101010" value="0x30334258"/> + <entry name="rgbx1010102" value="0x30335852"/> + <entry name="bgrx1010102" value="0x30335842"/> + <entry name="argb2101010" value="0x30335241"/> + <entry name="abgr2101010" value="0x30334241"/> + <entry name="rgba1010102" value="0x30334152"/> + <entry name="bgra1010102" value="0x30334142"/> + <entry name="yuyv" value="0x56595559"/> + <entry name="yvyu" value="0x55595659"/> + <entry name="uyvy" value="0x59565955"/> + <entry name="vyuy" value="0x59555956"/> + <entry name="ayuv" value="0x56555941"/> + <entry name="nv12" value="0x3231564e"/> + <entry name="nv21" value="0x3132564e"/> + <entry name="nv16" value="0x3631564e"/> + <entry name="nv61" value="0x3136564e"/> + <entry name="yuv410" value="0x39565559"/> + <entry name="yvu410" value="0x39555659"/> + <entry name="yuv411" value="0x31315559"/> + <entry name="yvu411" value="0x31315659"/> + <entry name="yuv420" value="0x32315559"/> + <entry name="yvu420" value="0x32315659"/> + <entry name="yuv422" value="0x36315559"/> + <entry name="yvu422" value="0x36315659"/> + <entry name="yuv444" value="0x34325559"/> + <entry name="yvu444" value="0x34325659"/> + </enum> + +  + <request name="create_prime_buffer"> + <arg name="id" type="new_id" interface="wl_buffer"/> + <arg name="name" type="fd"/> + <arg name="width" type="int"/> + <arg name="height" type="int"/> + <arg name="format" type="uint"/> + <arg name="offset0" type="int"/> + <arg name="stride0" type="int"/> + <arg name="offset1" type="int"/> + <arg name="stride1" type="int"/> + <arg name="offset2" type="int"/> + <arg name="stride2" type="int"/> + </request> + + <event name="format"> + <arg name="format" type="uint"/> + </event> + + <enum name="capability"> + <description summary="wl_dmabuf capability bitmask"> + Bitmask of capabilities. + </description> + <entry name="mmap" value="1" summary="wl_dmabuf mmap available"/> + </enum> + + <event name="capabilities"> + <arg name="value" type="uint"/> + </event> + </interface> + +</protocol> diff --git a/src/Makefile.am b/src/Makefile.am index 15f44a5..b3c414c 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -4,8 +4,11 @@ noinst_LTLIBRARIES = libwayland-util.la include_HEADERS = \ wayland-util.h \ wayland-server-protocol.h \ + wayland-dmabuf-server-protocol.h \ wayland-server.h \ + wayland-dmabuf.h \ wayland-client-protocol.h \ + wayland-dmabuf-client-protocol.h \ wayland-client.h \ wayland-egl.h \ wayland-version.h @@ -22,14 +25,17 @@ libwayland_server_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_server_la_LDFLAGS = -version-info 1:0:1 libwayland_server_la_SOURCES = \ wayland-protocol.c \ + wayland-dmabuf-protocol.c \ wayland-server.c \ wayland-shm.c \ + wayland-dmabuf.c \ event-loop.c libwayland_client_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_client_la_LDFLAGS = -version-info 2:0:2 libwayland_client_la_SOURCES = \ wayland-protocol.c \ + wayland-dmabuf-protocol.c \ wayland-client.c pkgconfigdir = $(libdir)/pkgconfig @@ -65,7 +71,11 @@ endif BUILT_SOURCES = \ wayland-server-protocol.h \ wayland-client-protocol.h \ - wayland-protocol.c + wayland-protocol.c \ + wayland-dmabuf-server-protocol.h \ + wayland-dmabuf-client-protocol.h \ + wayland-dmabuf-protocol.c + CLEANFILES = $(BUILT_SOURCES) DISTCLEANFILES = wayland-version.h diff --git a/src/wayland-dmabuf.c b/src/wayland-dmabuf.c new file mode 100644 index 0000000..857d743 --- /dev/null +++ b/src/wayland-dmabuf.c @@ -0,0 +1,275 @@ +/* + * Copyright © 2011 Kristian Høgsberg + * Copyright © 2011 Benjamin Franzke + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Authors: + * Kristian Høgsberg <krh(a)bitplanet.net> + * Benjamin Franzke <benjaminfranzke(a)googlemail.com> + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <stddef.h> +#include <unistd.h> + +#include "wayland-server.h" +#include "wayland-dmabuf.h" +#include "wayland-dmabuf-server-protocol.h" + +struct wl_dmabuf { + struct wl_display *display; + struct wl_global *wl_dmabuf_global; + + void *user_data; + uint32_t flags; + + struct wl_dmabuf_callbacks *callbacks; + + struct wl_buffer_interface buffer_interface; +}; + +static void +destroy_buffer(struct wl_resource *resource) +{ + struct wl_dmabuf_buffer *buffer = resource->data; + struct wl_dmabuf *dmabuf = buffer->dmabuf; + + dmabuf->callbacks->release_buffer(dmabuf->user_data, buffer); + free(buffer); +} + +static void +buffer_destroy(struct wl_client *client, struct wl_resource *resource) +{ + wl_resource_destroy(resource); +} + +static const struct wl_buffer_interface dmabuf_buffer_interface = { + buffer_destroy +}; + +static void +create_buffer(struct wl_client *client, struct wl_resource *resource, + uint32_t id, int fd, + int32_t width, int32_t height, + uint32_t format, + int32_t offset0, int32_t stride0, + int32_t offset1, int32_t stride1, + int32_t offset2, int32_t stride2) +{ + struct wl_dmabuf *dmabuf = resource->data; + struct wl_dmabuf_buffer *buffer; + + buffer = calloc(1, sizeof *buffer); + if (buffer == NULL) { + wl_resource_post_no_memory(resource); + return; + } + + buffer->dmabuf = dmabuf; + buffer->width = width; + buffer->height = height; + buffer->format = format; + buffer->offset[0] = offset0; + buffer->stride[0] = stride0; + buffer->offset[1] = offset1; + buffer->stride[1] = stride1; + buffer->offset[2] = offset2; + buffer->stride[2] = stride2; + + dmabuf->callbacks->reference_buffer(dmabuf->user_data, fd, buffer); + if (buffer->driver_buffer == NULL) { + wl_resource_post_error(resource, + WL_DMABUF_ERROR_INVALID_FILE_DESCRIPTOR, + "invalid file descriptor"); + return; + } + + buffer->resource = + wl_resource_create(client, &wl_buffer_interface, 1, id); + if (!buffer->resource) { + wl_resource_post_no_memory(resource); + free(buffer); + return; + } + + wl_resource_set_implementation(buffer->resource, + (void (**)(void)) &dmabuf->buffer_interface, + buffer, destroy_buffer); +} + +static void +dmabuf_create_prime_buffer(struct wl_client *client, + struct wl_resource *resource, + uint32_t id, int fd, + int32_t width, int32_t height, uint32_t format, + int32_t offset0, int32_t stride0, + int32_t offset1, int32_t stride1, + int32_t offset2, int32_t stride2) +{ + create_buffer(client, resource, id, fd, width, height, format, + offset0, stride0, offset1, stride1, offset2, stride2); + close(fd); +} + +static const struct wl_dmabuf_interface dmabuf_interface = { + dmabuf_create_prime_buffer +}; + +static void +bind_dmabuf(struct wl_client *client, void *data, uint32_t version, uint32_t id) +{ + struct wl_dmabuf *dmabuf = data; + struct wl_resource *resource; + + resource = wl_resource_create(client, &wl_dmabuf_interface, 1, id); + if (!resource) { + wl_client_post_no_memory(client); + return; + } + + dmabuf = resource->data; + + if (dmabuf->callbacks->send_supported_formats) + dmabuf->callbacks->send_supported_formats(dmabuf->user_data, resource); + + if (dmabuf->callbacks->send_capabilities) + dmabuf->callbacks->send_capabilities(dmabuf->user_data, resource); +} + +WL_EXPORT struct wl_dmabuf * +wl_dmabuf_init(struct wl_display *display, struct wl_dmabuf_callbacks *callbacks, + void *user_data, uint32_t flags) +{ + struct wl_dmabuf *dmabuf; + + dmabuf = malloc(sizeof *dmabuf); + + dmabuf->display = display; + dmabuf->callbacks = callbacks; + dmabuf->user_data = user_data; + dmabuf->flags = flags; + + dmabuf->buffer_interface.destroy = buffer_destroy; + + dmabuf->wl_dmabuf_global = + wl_global_create(display, &wl_dmabuf_interface, 1, dmabuf, bind_dmabuf); + + return dmabuf; +} + +WL_EXPORT void +wl_dmabuf_uninit(struct wl_dmabuf *dmabuf) +{ + wl_global_destroy(dmabuf->wl_dmabuf_global); + + free(dmabuf); +} + +WL_EXPORT int +wl_buffer_is_dmabuf(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf = buffer->dmabuf; + + return wl_resource_instance_of(buffer->resource, + &wl_buffer_interface, &dmabuf->buffer_interface); +} + +WL_EXPORT uint32_t +wl_dmabuf_buffer_get_format(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->format; +} + +WL_EXPORT void * +wl_dmabuf_buffer_get_buffer(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return NULL; + + return buffer->driver_buffer; +} + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_stride(struct wl_dmabuf_buffer *buffer, int idx) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->stride[idx]; +} + +WL_EXPORT void * +wl_dmabuf_buffer_get_data(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf; + + if (!wl_buffer_is_dmabuf(buffer)) + return NULL; + + dmabuf = buffer->dmabuf; + + if (dmabuf->callbacks->get_data) + return dmabuf->callbacks->get_data(dmabuf->user_data, buffer); + + return NULL; +} + +WL_EXPORT void +wl_dmabuf_buffer_put_data(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf; + + if (!wl_buffer_is_dmabuf(buffer)) + return; + + dmabuf = buffer->dmabuf; + + if (dmabuf->callbacks->put_data) + dmabuf->callbacks->put_data(dmabuf->user_data, buffer); + + return; +} + + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_width(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->width; +} + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_height(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->height; +} diff --git a/src/wayland-dmabuf.h b/src/wayland-dmabuf.h new file mode 100644 index 0000000..5e3bb5c --- /dev/null +++ b/src/wayland-dmabuf.h @@ -0,0 +1,134 @@ +#ifndef WAYLAND_DMABUF_H +#define WAYLAND_DMABUF_H + +#include <wayland-server.h> + +#ifndef WL_DMABUF_FORMAT_ENUM +#define WL_DMABUF_FORMAT_ENUM + +enum wl_dmabuf_format { + WL_DMABUF_FORMAT_C8 = 0x20203843, + WL_DMABUF_FORMAT_RGB332 = 0x38424752, + WL_DMABUF_FORMAT_BGR233 = 0x38524742, + WL_DMABUF_FORMAT_XRGB4444 = 0x32315258, + WL_DMABUF_FORMAT_XBGR4444 = 0x32314258, + WL_DMABUF_FORMAT_RGBX4444 = 0x32315852, + WL_DMABUF_FORMAT_BGRX4444 = 0x32315842, + WL_DMABUF_FORMAT_ARGB4444 = 0x32315241, + WL_DMABUF_FORMAT_ABGR4444 = 0x32314241, + WL_DMABUF_FORMAT_RGBA4444 = 0x32314152, + WL_DMABUF_FORMAT_BGRA4444 = 0x32314142, + WL_DMABUF_FORMAT_XRGB1555 = 0x35315258, + WL_DMABUF_FORMAT_XBGR1555 = 0x35314258, + WL_DMABUF_FORMAT_RGBX5551 = 0x35315852, + WL_DMABUF_FORMAT_BGRX5551 = 0x35315842, + WL_DMABUF_FORMAT_ARGB1555 = 0x35315241, + WL_DMABUF_FORMAT_ABGR1555 = 0x35314241, + WL_DMABUF_FORMAT_RGBA5551 = 0x35314152, + WL_DMABUF_FORMAT_BGRA5551 = 0x35314142, + WL_DMABUF_FORMAT_RGB565 = 0x36314752, + WL_DMABUF_FORMAT_BGR565 = 0x36314742, + WL_DMABUF_FORMAT_RGB888 = 0x34324752, + WL_DMABUF_FORMAT_BGR888 = 0x34324742, + WL_DMABUF_FORMAT_XRGB8888 = 0x34325258, + WL_DMABUF_FORMAT_XBGR8888 = 0x34324258, + WL_DMABUF_FORMAT_RGBX8888 = 0x34325852, + WL_DMABUF_FORMAT_BGRX8888 = 0x34325842, + WL_DMABUF_FORMAT_ARGB8888 = 0x34325241, + WL_DMABUF_FORMAT_ABGR8888 = 0x34324241, + WL_DMABUF_FORMAT_RGBA8888 = 0x34324152, + WL_DMABUF_FORMAT_BGRA8888 = 0x34324142, + WL_DMABUF_FORMAT_XRGB2101010 = 0x30335258, + WL_DMABUF_FORMAT_XBGR2101010 = 0x30334258, + WL_DMABUF_FORMAT_RGBX1010102 = 0x30335852, + WL_DMABUF_FORMAT_BGRX1010102 = 0x30335842, + WL_DMABUF_FORMAT_ARGB2101010 = 0x30335241, + WL_DMABUF_FORMAT_ABGR2101010 = 0x30334241, + WL_DMABUF_FORMAT_RGBA1010102 = 0x30334152, + WL_DMABUF_FORMAT_BGRA1010102 = 0x30334142, + WL_DMABUF_FORMAT_YUYV = 0x56595559, + WL_DMABUF_FORMAT_YVYU = 0x55595659, + WL_DMABUF_FORMAT_UYVY = 0x59565955, + WL_DMABUF_FORMAT_VYUY = 0x59555956, + WL_DMABUF_FORMAT_AYUV = 0x56555941, + WL_DMABUF_FORMAT_NV12 = 0x3231564e, + WL_DMABUF_FORMAT_NV21 = 0x3132564e, + WL_DMABUF_FORMAT_NV16 = 0x3631564e, + WL_DMABUF_FORMAT_NV61 = 0x3136564e, + WL_DMABUF_FORMAT_YUV410 = 0x39565559, + WL_DMABUF_FORMAT_YVU410 = 0x39555659, + WL_DMABUF_FORMAT_YUV411 = 0x31315559, + WL_DMABUF_FORMAT_YVU411 = 0x31315659, + WL_DMABUF_FORMAT_YUV420 = 0x32315559, + WL_DMABUF_FORMAT_YVU420 = 0x32315659, + WL_DMABUF_FORMAT_YUV422 = 0x36315559, + WL_DMABUF_FORMAT_YVU422 = 0x36315659, + WL_DMABUF_FORMAT_YUV444 = 0x34325559, + WL_DMABUF_FORMAT_YVU444 = 0x34325659, +}; +#endif /* WL_DMABUF_FORMAT_ENUM */ + +struct wl_dmabuf; + +struct wl_dmabuf_buffer { + struct wl_resource *resource; + struct wl_dmabuf *dmabuf; + int32_t width, height; + uint32_t format; + int32_t offset[3]; + int32_t stride[3]; + void *driver_buffer; +}; + +/* struct wl_dmabuf_callbacks + * + * @reference_buffer: take a reference on buffer + * @release_buffer: release a reference on buffer + * @get_data: get access to buffer memory to use it + * @put_data: indicated that buffer memory is no more used + * @send_supported_formats: post the pixel format supported by the server + * @send_capabilities: post the dmabuf capabilities of the server + */ +struct wl_dmabuf_callbacks { + void (*reference_buffer)(void *user_data, int fd, + struct wl_dmabuf_buffer *buffer); + void (*release_buffer)(void *user_data, struct wl_dmabuf_buffer *buffer); + void* (*get_data)(void *user_data, struct wl_dmabuf_buffer *buffer); + void (*put_data)(void *user_data, struct wl_dmabuf_buffer *buffer); + void (*send_supported_formats)(void *user_data, struct wl_resource *resource); + void (*send_capabilities)(void *user_data, struct wl_resource *resource); +}; + +struct wl_dmabuf * +wl_dmabuf_init(struct wl_display *display, + struct wl_dmabuf_callbacks *callbacks, + void *user_data, uint32_t flags); + +void +wl_dmabuf_uninit(struct wl_dmabuf *dmabuf); + +int +wl_buffer_is_dmabuf(struct wl_dmabuf_buffer *buffer); + +uint32_t +wl_dmabuf_buffer_get_format(struct wl_dmabuf_buffer *buffer); + +void * +wl_dmabuf_buffer_get_buffer(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_stride(struct wl_dmabuf_buffer *buffer, int idx); + +void * +wl_dmabuf_buffer_get_data(struct wl_dmabuf_buffer *buffer); + +void +wl_dmabuf_buffer_put_data(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_width(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_height(struct wl_dmabuf_buffer *buffer); + +#endif -- 1.7.9.5

11 years, 5 months

3
2
0 0

[PATCH] Add wl_dmabuf protocol

by benjamin.gaignard＠linaro.org

From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> This protocol is widely derivated of wl_drm protocol but without unneeded function like flink or authentification. It allow to use a dmabuf file descriptor in a wayland protocol which could be useful in case we don't have (or can't use) Mesa EGL. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- protocol/Makefile.am | 6 +- protocol/wayland-dmabuf.xml | 134 ++++++++++++++++++++ src/Makefile.am | 12 +- src/wayland-dmabuf.c | 291 +++++++++++++++++++++++++++++++++++++++++++ src/wayland-dmabuf.h | 126 +++++++++++++++++++ 5 files changed, 565 insertions(+), 4 deletions(-) create mode 100644 protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c create mode 100644 src/wayland-dmabuf.h diff --git a/protocol/Makefile.am b/protocol/Makefile.am index e8b6290..8c9499f 100644 --- a/protocol/Makefile.am +++ b/protocol/Makefile.am @@ -1,4 +1,4 @@ -dist_pkgdata_DATA = wayland.xml wayland.dtd +dist_pkgdata_DATA = wayland.xml wayland-dmabuf.xml wayland.dtd if HAVE_XMLLINT .PHONY: validate @@ -6,9 +6,9 @@ if HAVE_XMLLINT .%.xml.valid: %.xml $(AM_V_GEN)$(XMLLINT) --noout --dtdvalid $(srcdir)/wayland.dtd $^ > $@ -validate: .wayland.xml.valid +validate: .wayland.xml.valid .wayland-dmabuf.xml.valid all-local: validate -CLEANFILES = .wayland.xml.valid +CLEANFILES = .wayland.xml.valid .wayland-dmabuf.xml.valid endif diff --git a/protocol/wayland-dmabuf.xml b/protocol/wayland-dmabuf.xml new file mode 100644 index 0000000..9588514 --- /dev/null +++ b/protocol/wayland-dmabuf.xml @@ -0,0 +1,134 @@ +<?xml version="1.0" encoding="UTF-8"?> +<protocol name="dmabuf"> + + <copyright> + Copyright © 2008-2011 Kristian Høgsberg + Copyright © 2010-2011 Intel Corporation + + Permission to use, copy, modify, distribute, and sell this + software and its documentation for any purpose is hereby granted + without fee, provided that\n the above copyright notice appear in + all copies and that both that copyright notice and this permission + notice appear in supporting documentation, and that the name of + the copyright holders not be used in advertising or publicity + pertaining to distribution of the software without specific, + written prior permission. The copyright holders make no + representations about the suitability of this software for any + purpose. It is provided "as is" without express or implied + warranty. + + THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS + SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY + SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, + ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF + THIS SOFTWARE. + </copyright> + +  + <interface name="wl_dmabuf" version="2"> + <enum name="error"> + <entry name="invalid_format" value="1"/> + <entry name="invalid_name" value="2"/> + </enum> + + <enum name="format"> +  + <entry name="c8" value="0x20203843"/> + <entry name="rgb332" value="0x38424752"/> + <entry name="bgr233" value="0x38524742"/> + <entry name="xrgb4444" value="0x32315258"/> + <entry name="xbgr4444" value="0x32314258"/> + <entry name="rgbx4444" value="0x32315852"/> + <entry name="bgrx4444" value="0x32315842"/> + <entry name="argb4444" value="0x32315241"/> + <entry name="abgr4444" value="0x32314241"/> + <entry name="rgba4444" value="0x32314152"/> + <entry name="bgra4444" value="0x32314142"/> + <entry name="xrgb1555" value="0x35315258"/> + <entry name="xbgr1555" value="0x35314258"/> + <entry name="rgbx5551" value="0x35315852"/> + <entry name="bgrx5551" value="0x35315842"/> + <entry name="argb1555" value="0x35315241"/> + <entry name="abgr1555" value="0x35314241"/> + <entry name="rgba5551" value="0x35314152"/> + <entry name="bgra5551" value="0x35314142"/> + <entry name="rgb565" value="0x36314752"/> + <entry name="bgr565" value="0x36314742"/> + <entry name="rgb888" value="0x34324752"/> + <entry name="bgr888" value="0x34324742"/> + <entry name="xrgb8888" value="0x34325258"/> + <entry name="xbgr8888" value="0x34324258"/> + <entry name="rgbx8888" value="0x34325852"/> + <entry name="bgrx8888" value="0x34325842"/> + <entry name="argb8888" value="0x34325241"/> + <entry name="abgr8888" value="0x34324241"/> + <entry name="rgba8888" value="0x34324152"/> + <entry name="bgra8888" value="0x34324142"/> + <entry name="xrgb2101010" value="0x30335258"/> + <entry name="xbgr2101010" value="0x30334258"/> + <entry name="rgbx1010102" value="0x30335852"/> + <entry name="bgrx1010102" value="0x30335842"/> + <entry name="argb2101010" value="0x30335241"/> + <entry name="abgr2101010" value="0x30334241"/> + <entry name="rgba1010102" value="0x30334152"/> + <entry name="bgra1010102" value="0x30334142"/> + <entry name="yuyv" value="0x56595559"/> + <entry name="yvyu" value="0x55595659"/> + <entry name="uyvy" value="0x59565955"/> + <entry name="vyuy" value="0x59555956"/> + <entry name="ayuv" value="0x56555941"/> + <entry name="nv12" value="0x3231564e"/> + <entry name="nv21" value="0x3132564e"/> + <entry name="nv16" value="0x3631564e"/> + <entry name="nv61" value="0x3136564e"/> + <entry name="yuv410" value="0x39565559"/> + <entry name="yvu410" value="0x39555659"/> + <entry name="yuv411" value="0x31315559"/> + <entry name="yvu411" value="0x31315659"/> + <entry name="yuv420" value="0x32315559"/> + <entry name="yvu420" value="0x32315659"/> + <entry name="yuv422" value="0x36315559"/> + <entry name="yvu422" value="0x36315659"/> + <entry name="yuv444" value="0x34325559"/> + <entry name="yvu444" value="0x34325659"/> + </enum> + +  + <request name="create_prime_buffer" since="2"> + <arg name="id" type="new_id" interface="wl_buffer"/> + <arg name="name" type="fd"/> + <arg name="width" type="int"/> + <arg name="height" type="int"/> + <arg name="format" type="uint"/> + <arg name="offset0" type="int"/> + <arg name="stride0" type="int"/> + <arg name="offset1" type="int"/> + <arg name="stride1" type="int"/> + <arg name="offset2" type="int"/> + <arg name="stride2" type="int"/> + </request> + + <event name="format"> + <arg name="format" type="uint"/> + </event> + + <enum name="capability" since="2"> + <description summary="wl_dmabuf capability bitmask"> + Bitmask of capabilities. + </description> + <entry name="prime" value="1" summary="wl_dmabuf prime available"/> + </enum> + + <event name="capabilities"> + <arg name="value" type="uint"/> + </event> + </interface> + +</protocol> diff --git a/src/Makefile.am b/src/Makefile.am index 15f44a5..b3c414c 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -4,8 +4,11 @@ noinst_LTLIBRARIES = libwayland-util.la include_HEADERS = \ wayland-util.h \ wayland-server-protocol.h \ + wayland-dmabuf-server-protocol.h \ wayland-server.h \ + wayland-dmabuf.h \ wayland-client-protocol.h \ + wayland-dmabuf-client-protocol.h \ wayland-client.h \ wayland-egl.h \ wayland-version.h @@ -22,14 +25,17 @@ libwayland_server_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_server_la_LDFLAGS = -version-info 1:0:1 libwayland_server_la_SOURCES = \ wayland-protocol.c \ + wayland-dmabuf-protocol.c \ wayland-server.c \ wayland-shm.c \ + wayland-dmabuf.c \ event-loop.c libwayland_client_la_LIBADD = $(FFI_LIBS) libwayland-util.la -lrt -lm libwayland_client_la_LDFLAGS = -version-info 2:0:2 libwayland_client_la_SOURCES = \ wayland-protocol.c \ + wayland-dmabuf-protocol.c \ wayland-client.c pkgconfigdir = $(libdir)/pkgconfig @@ -65,7 +71,11 @@ endif BUILT_SOURCES = \ wayland-server-protocol.h \ wayland-client-protocol.h \ - wayland-protocol.c + wayland-protocol.c \ + wayland-dmabuf-server-protocol.h \ + wayland-dmabuf-client-protocol.h \ + wayland-dmabuf-protocol.c + CLEANFILES = $(BUILT_SOURCES) DISTCLEANFILES = wayland-version.h diff --git a/src/wayland-dmabuf.c b/src/wayland-dmabuf.c new file mode 100644 index 0000000..a075996 --- /dev/null +++ b/src/wayland-dmabuf.c @@ -0,0 +1,291 @@ +/* + * Copyright © 2011 Kristian Høgsberg + * Copyright © 2011 Benjamin Franzke + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Authors: + * Kristian Høgsberg <krh(a)bitplanet.net> + * Benjamin Franzke <benjaminfranzke(a)googlemail.com> + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <stddef.h> +#include <unistd.h> + +#include "wayland-server.h" +#include "wayland-dmabuf.h" +#include "wayland-dmabuf-server-protocol.h" + +#define MIN(x,y) (((x)<(y))?(x):(y)) + +struct wl_dmabuf { + struct wl_display *display; + struct wl_global *wl_dmabuf_global; + + void *user_data; + uint32_t flags; + + struct wl_dmabuf_callbacks *callbacks; + + struct wl_buffer_interface buffer_interface; +}; + +static void +destroy_buffer(struct wl_resource *resource) +{ + struct wl_dmabuf_buffer *buffer = resource->data; + struct wl_dmabuf *dmabuf = buffer->dmabuf; + + dmabuf->callbacks->release_buffer(dmabuf->user_data, buffer); + free(buffer); +} + +static void +buffer_destroy(struct wl_client *client, struct wl_resource *resource) +{ + wl_resource_destroy(resource); +} + +static const struct wl_buffer_interface dmabuf_buffer_interface = { + buffer_destroy +}; + +static void +create_buffer(struct wl_client *client, struct wl_resource *resource, + uint32_t id, uint32_t name, int fd, + int32_t width, int32_t height, + uint32_t format, + int32_t offset0, int32_t stride0, + int32_t offset1, int32_t stride1, + int32_t offset2, int32_t stride2) +{ + struct wl_dmabuf *dmabuf = resource->data; + struct wl_dmabuf_buffer *buffer; + + buffer = calloc(1, sizeof *buffer); + if (buffer == NULL) { + wl_resource_post_no_memory(resource); + return; + } + + buffer->dmabuf = dmabuf; + buffer->width = width; + buffer->height = height; + buffer->format = format; + buffer->offset[0] = offset0; + buffer->stride[0] = stride0; + buffer->offset[1] = offset1; + buffer->stride[1] = stride1; + buffer->offset[2] = offset2; + buffer->stride[2] = stride2; + + dmabuf->callbacks->reference_buffer(dmabuf->user_data, name, fd, buffer); + if (buffer->driver_buffer == NULL) { + wl_resource_post_error(resource, + WL_DMABUF_ERROR_INVALID_NAME, + "invalid name"); + return; + } + + buffer->resource = + wl_resource_create(client, &wl_buffer_interface, 1, id); + if (!buffer->resource) { + wl_resource_post_no_memory(resource); + free(buffer); + return; + } + + wl_resource_set_implementation(buffer->resource, + (void (**)(void)) &dmabuf->buffer_interface, + buffer, destroy_buffer); +} + +static void +dmabuf_create_prime_buffer(struct wl_client *client, + struct wl_resource *resource, + uint32_t id, int fd, + int32_t width, int32_t height, uint32_t format, + int32_t offset0, int32_t stride0, + int32_t offset1, int32_t stride1, + int32_t offset2, int32_t stride2) +{ + create_buffer(client, resource, id, 0, fd, width, height, format, + offset0, stride0, offset1, stride1, offset2, stride2); + close(fd); +} + +static const struct wl_dmabuf_interface dmabuf_interface = { + dmabuf_create_prime_buffer +}; + +static void +bind_dmabuf(struct wl_client *client, void *data, uint32_t version, uint32_t id) +{ + struct wl_dmabuf *dmabuf = data; + struct wl_resource *resource; + uint32_t capabilities; + + resource = wl_resource_create(client, &wl_dmabuf_interface, + MIN(version, 2), id); + if (!resource) { + wl_client_post_no_memory(client); + return; + } + + wl_resource_set_implementation(resource, &dmabuf_interface, data, NULL); + + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_ARGB8888); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_XRGB8888); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUV410); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUV411); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUV420); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUV422); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUV444); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_NV12); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_NV16); + wl_resource_post_event(resource, WL_DMABUF_FORMAT, WL_DMABUF_FORMAT_YUYV); + + capabilities = 0; + if (dmabuf->flags & WAYLAND_DMABUF_PRIME) + capabilities |= WL_DMABUF_CAPABILITY_PRIME; + + if (version >= 2) + wl_resource_post_event(resource, WL_DMABUF_CAPABILITIES, capabilities); +} + +WL_EXPORT struct wl_dmabuf * +wl_dmabuf_init(struct wl_display *display, struct wl_dmabuf_callbacks *callbacks, + void *user_data, uint32_t flags) +{ + struct wl_dmabuf *dmabuf; + + dmabuf = malloc(sizeof *dmabuf); + + dmabuf->display = display; + dmabuf->callbacks = callbacks; + dmabuf->user_data = user_data; + dmabuf->flags = flags; + + dmabuf->buffer_interface.destroy = buffer_destroy; + + dmabuf->wl_dmabuf_global = + wl_global_create(display, &wl_dmabuf_interface, 2, dmabuf, bind_dmabuf); + + return dmabuf; +} + +WL_EXPORT void +wl_dmabuf_uninit(struct wl_dmabuf *dmabuf) +{ + wl_global_destroy(dmabuf->wl_dmabuf_global); + + free(dmabuf); +} + +WL_EXPORT int +wl_buffer_is_dmabuf(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf = buffer->dmabuf; + + return wl_resource_instance_of(buffer->resource, + &wl_buffer_interface, &dmabuf->buffer_interface); +} + +WL_EXPORT uint32_t +wl_dmabuf_buffer_get_format(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->format; +} + +WL_EXPORT void * +wl_dmabuf_buffer_get_buffer(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return NULL; + + return buffer->driver_buffer; +} + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_stride(struct wl_dmabuf_buffer *buffer, int idx) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->stride[idx]; +} + +WL_EXPORT void * +wl_dmabuf_buffer_get_data(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf; + + if (!wl_buffer_is_dmabuf(buffer)) + return NULL; + + dmabuf = buffer->dmabuf; + + if (dmabuf->callbacks->get_data) + return dmabuf->callbacks->get_data(dmabuf->user_data, buffer); + + return NULL; +} + +WL_EXPORT void +wl_dmabuf_buffer_put_data(struct wl_dmabuf_buffer *buffer) +{ + struct wl_dmabuf *dmabuf; + + if (!wl_buffer_is_dmabuf(buffer)) + return; + + dmabuf = buffer->dmabuf; + + if (dmabuf->callbacks->put_data) + dmabuf->callbacks->put_data(dmabuf->user_data, buffer); + + return; +} + + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_width(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->width; +} + +WL_EXPORT int32_t +wl_dmabuf_buffer_get_height(struct wl_dmabuf_buffer *buffer) +{ + if (!wl_buffer_is_dmabuf(buffer)) + return 0; + + return buffer->height; +} diff --git a/src/wayland-dmabuf.h b/src/wayland-dmabuf.h new file mode 100644 index 0000000..9e80beb --- /dev/null +++ b/src/wayland-dmabuf.h @@ -0,0 +1,126 @@ +#ifndef WAYLAND_DMABUF_H +#define WAYLAND_DMABUF_H + +#include <wayland-server.h> + +#ifndef WL_DMABUF_FORMAT_ENUM +#define WL_DMABUF_FORMAT_ENUM + +enum wl_dmabuf_format { + WL_DMABUF_FORMAT_C8 = 0x20203843, + WL_DMABUF_FORMAT_RGB332 = 0x38424752, + WL_DMABUF_FORMAT_BGR233 = 0x38524742, + WL_DMABUF_FORMAT_XRGB4444 = 0x32315258, + WL_DMABUF_FORMAT_XBGR4444 = 0x32314258, + WL_DMABUF_FORMAT_RGBX4444 = 0x32315852, + WL_DMABUF_FORMAT_BGRX4444 = 0x32315842, + WL_DMABUF_FORMAT_ARGB4444 = 0x32315241, + WL_DMABUF_FORMAT_ABGR4444 = 0x32314241, + WL_DMABUF_FORMAT_RGBA4444 = 0x32314152, + WL_DMABUF_FORMAT_BGRA4444 = 0x32314142, + WL_DMABUF_FORMAT_XRGB1555 = 0x35315258, + WL_DMABUF_FORMAT_XBGR1555 = 0x35314258, + WL_DMABUF_FORMAT_RGBX5551 = 0x35315852, + WL_DMABUF_FORMAT_BGRX5551 = 0x35315842, + WL_DMABUF_FORMAT_ARGB1555 = 0x35315241, + WL_DMABUF_FORMAT_ABGR1555 = 0x35314241, + WL_DMABUF_FORMAT_RGBA5551 = 0x35314152, + WL_DMABUF_FORMAT_BGRA5551 = 0x35314142, + WL_DMABUF_FORMAT_RGB565 = 0x36314752, + WL_DMABUF_FORMAT_BGR565 = 0x36314742, + WL_DMABUF_FORMAT_RGB888 = 0x34324752, + WL_DMABUF_FORMAT_BGR888 = 0x34324742, + WL_DMABUF_FORMAT_XRGB8888 = 0x34325258, + WL_DMABUF_FORMAT_XBGR8888 = 0x34324258, + WL_DMABUF_FORMAT_RGBX8888 = 0x34325852, + WL_DMABUF_FORMAT_BGRX8888 = 0x34325842, + WL_DMABUF_FORMAT_ARGB8888 = 0x34325241, + WL_DMABUF_FORMAT_ABGR8888 = 0x34324241, + WL_DMABUF_FORMAT_RGBA8888 = 0x34324152, + WL_DMABUF_FORMAT_BGRA8888 = 0x34324142, + WL_DMABUF_FORMAT_XRGB2101010 = 0x30335258, + WL_DMABUF_FORMAT_XBGR2101010 = 0x30334258, + WL_DMABUF_FORMAT_RGBX1010102 = 0x30335852, + WL_DMABUF_FORMAT_BGRX1010102 = 0x30335842, + WL_DMABUF_FORMAT_ARGB2101010 = 0x30335241, + WL_DMABUF_FORMAT_ABGR2101010 = 0x30334241, + WL_DMABUF_FORMAT_RGBA1010102 = 0x30334152, + WL_DMABUF_FORMAT_BGRA1010102 = 0x30334142, + WL_DMABUF_FORMAT_YUYV = 0x56595559, + WL_DMABUF_FORMAT_YVYU = 0x55595659, + WL_DMABUF_FORMAT_UYVY = 0x59565955, + WL_DMABUF_FORMAT_VYUY = 0x59555956, + WL_DMABUF_FORMAT_AYUV = 0x56555941, + WL_DMABUF_FORMAT_NV12 = 0x3231564e, + WL_DMABUF_FORMAT_NV21 = 0x3132564e, + WL_DMABUF_FORMAT_NV16 = 0x3631564e, + WL_DMABUF_FORMAT_NV61 = 0x3136564e, + WL_DMABUF_FORMAT_YUV410 = 0x39565559, + WL_DMABUF_FORMAT_YVU410 = 0x39555659, + WL_DMABUF_FORMAT_YUV411 = 0x31315559, + WL_DMABUF_FORMAT_YVU411 = 0x31315659, + WL_DMABUF_FORMAT_YUV420 = 0x32315559, + WL_DMABUF_FORMAT_YVU420 = 0x32315659, + WL_DMABUF_FORMAT_YUV422 = 0x36315559, + WL_DMABUF_FORMAT_YVU422 = 0x36315659, + WL_DMABUF_FORMAT_YUV444 = 0x34325559, + WL_DMABUF_FORMAT_YVU444 = 0x34325659, +}; +#endif /* WL_DMABUF_FORMAT_ENUM */ + +struct wl_dmabuf; + +struct wl_dmabuf_buffer { + struct wl_resource *resource; + struct wl_dmabuf *dmabuf; + int32_t width, height; + uint32_t format; + int32_t offset[3]; + int32_t stride[3]; + void *driver_buffer; +}; + +struct wl_dmabuf_callbacks { + void (*reference_buffer)(void *user_data, uint32_t name, int fd, + struct wl_dmabuf_buffer *buffer); + + void (*release_buffer)(void *user_data, struct wl_dmabuf_buffer *buffer); + void* (*get_data)(void *user_data, struct wl_dmabuf_buffer *buffer); + void (*put_data)(void *user_data, struct wl_dmabuf_buffer *buffer); +}; + +enum { WAYLAND_DMABUF_PRIME = 0x01 }; + +struct wl_dmabuf * +wl_dmabuf_init(struct wl_display *display, + struct wl_dmabuf_callbacks *callbacks, + void *user_data, uint32_t flags); + +void +wl_dmabuf_uninit(struct wl_dmabuf *dmabuf); + +int +wl_buffer_is_dmabuf(struct wl_dmabuf_buffer *buffer); + +uint32_t +wl_dmabuf_buffer_get_format(struct wl_dmabuf_buffer *buffer); + +void * +wl_dmabuf_buffer_get_buffer(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_stride(struct wl_dmabuf_buffer *buffer, int idx); + +void * +wl_dmabuf_buffer_get_data(struct wl_dmabuf_buffer *buffer); + +void +wl_dmabuf_buffer_put_data(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_width(struct wl_dmabuf_buffer *buffer); + +int32_t +wl_dmabuf_buffer_get_height(struct wl_dmabuf_buffer *buffer); + +#endif -- 1.7.9.5

11 years, 6 months

2
1
0 0

Move wayland-drm protocol from Mesa to wayland-core

by Benjamin Gaignard

Hi all, I'm working for Linaro on enabling a zero copy path in GStreamer by using dmabuf. To make this possible I have patched gst wayland sink to use wayland drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155 Today wayland drm protocol is limited to Mesa so I have decided to move it into wayland-core. My hardware doesn't have gpu support yet so I have patched weston (pixman) to allow usage of wl_drm buffers. With this I able to share/use a buffer allocated by DRM in gstreamer pipeline even if I don't have gpu and EGL. What do you think about make wayland drm protocol available like this ? Please note those patches are for wayland/weston 1.1.0 Regards, Benjamin -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

11 years, 6 months

5
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig