Linaro-mm-sig August 2013

linaro-mm-sig@lists.linaro.org

26 participants
22 discussions

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

by Tom Cooksey

Hi Rob, +linux-media, +linaro-mm-sig for discussion of video/camera buffer constraints... > On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey <tom.cooksey(a)arm.com> > wrote: > >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also > >> > allocate buffers for the GPU. Still not sure how to resolve > >> > this as we don't use DRM for our GPU driver. > >> > >> any thoughts/plans about a DRM GPU driver? Ideally long term (esp. > >> once the dma-fence stuff is in place), we'd have gpu-specific drm > >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver, > >> using prime/dmabuf to share between the two. > > > > The "extra" buffers we were allocating from armsoc DDX were really > > being allocated through DRM/GEM so we could get an flink name > > for them and pass a reference to them back to our GPU driver on > > the client side. If it weren't for our need to access those > > extra off-screen buffers with the GPU we wouldn't need to > > allocate them with DRM at all. So, given they are really "GPU" > > buffers, it does absolutely make sense to allocate them in a > > different driver to the display driver. > > > > However, to avoid unnecessary memcpys & related cache > > maintenance ops, we'd also like the GPU to render into buffers > > which are scanned out by the display controller. So let's say > > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan > > out buffers with the display's DRM driver but a custom ioctl > > on the GPU's DRM driver to allocate non scanout, off-screen > > buffers. Sounds great, but I don't think that really works > > with DRI2. If we used two drivers to allocate buffers, which > > of those drivers do we return in DRI2ConnectReply? Even if we > > solve that somehow, GEM flink names are name-spaced to a > > single device node (AFAIK). So when we do a DRI2GetBuffers, > > how does the EGL in the client know which DRM device owns GEM > > flink name "1234"? We'd need some pretty dirty hacks. > > You would return the name of the display driver allocating the > buffers. On the client side you can use generic ioctls to go from > flink -> handle -> dmabuf. So the client side would end up opening > both the display drm device and the gpu, but without needing to know > too much about the display. I think the bit I was missing was that a GEM bo for a buffer imported using dma_buf/PRIME can still be flink'd. So the display controller's DRM driver allocates scan-out buffers via the DUMB buffer allocate ioctl. Those scan-out buffers than then be exported from the dispaly's DRM driver and imported into the GPU's DRM driver using PRIME. Once imported into the GPU's driver, we can use flink to get a name for that buffer within the GPU DRM driver's name-space to return to the DRI2 client. That same namespace is also what DRI2 back-buffers are allocated from, so I think that could work... Except... > > Anyway, that latter case also gets quite difficult. The "GPU" > > DRM driver would need to know the constraints of the display > > controller when allocating buffers intended to be scanned out. > > For example, pl111 typically isn't behind an IOMMU and so > > requires physically contiguous memory. We'd have to teach the > > GPU's DRM driver about the constraints of the display HW. Not > > exactly a clean driver model. :-( > > > > I'm still a little stuck on how to proceed, so any ideas > > would greatly appreciated! My current train of thought is > > having a kind of SoC-specific DRM driver which allocates > > buffers for both display and GPU within a single GEM > > namespace. That SoC-specific DRM driver could then know the > > constraints of both the GPU and the display HW. We could then > > use PRIME to export buffers allocated with the SoC DRM driver > > and import them into the GPU and/or display DRM driver. > > Usually if the display drm driver is allocating the buffers that might > be scanned out, it just needs to have minimal knowledge of the GPU > (pitch alignment constraints). I don't think we need a 3rd device > just to allocate buffers. While Mali can render to pretty much any buffer, there is a mild performance improvement to be had if the buffer stride is aligned to the AXI bus's max burst length when drawing to the buffer. So in some respects, there is a constraint on how buffers which will be drawn to using the GPU are allocated. I don't really like the idea of teaching the display controller DRM driver about the GPU buffer constraints, even if they are fairly trivial like this. If the same display HW IP is being used on several SoCs, it seems wrong somehow to enforce those GPU constraints if some of those SoCs don't have a GPU. We may also then have additional constraints when sharing buffers between the display HW and video decode or even camera ISP HW. Programmatically describing buffer allocation constraints is very difficult and I'm not sure you can actually do it - there's some pretty complex constraints out there! E.g. I believe there's a platform where Y and UV planes of the reference frame need to be in separate DRAM banks for real-time 1080p decode, or something like that? Anyway, I guess my point is that even if we solve how to allocate buffers which will be shared between the GPU and display HW such that both sets of constraints are satisfied, that may not be the end of the story. Cheers, Tom

11 years, 4 months

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

by Marek Szyprowski

Hello, This is a fourth version of my proposal for device tree integration for reserved memory and Contiguous Memory Allocator. After the comments from Grant Likely I moved back memory region definitions back to /memory node (as it was in the first version of this proposal). I've also extended the code and made it more generic, added support for so called reserved dma memory (special dma memory regions created by dma_alloc_coherent() function, for exclusive usage for dma allocation for the given device). Just a few words for those who see this code for the first time: The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. Contiguous Memory Allocator is a framework, which lets to provide a large contiguous memory buffers for (usually a multimedia) devices. The contiguous memory is reserved during early boot and then shared with kernel, which is allowed to allocate it for movable pages. Then, when device driver requests a contigouous buffer, the framework migrates movable pages out of contiguous region and gives it to the driver. When device driver frees the buffer, it is added to kernel memory pool again. For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57 ("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895 (CMA merge commit). Why we need device tree bindings for CMA at all? Older ARM kernels used so called board-based initialization. Those board files contained a definition of all hardware blocks available on the target system and particular kernel and driver software configuration selected by the board maintainer. In the new approach the board files will be removed completely and Device Tree approach is used to describe all hardware blocks available on the target system. By definition, the bindings should be software independent, so at least in theory it should be possible to use those bindings with other operating systems than Linux kernel. Reserved memory configuration belongs to the grey area. It might depend on hardware restriction of the board or modules and low-level configuration done by bootloader. Putting reserved and contiguous memory regions to /memory node and having phandles to those regions in the device nodes however matches well with the device-tree typical style of linking devices with other resources like clocks, interrupts, regulators, power domains, etc. This is the main reason to use such approach instead of putting everything to /chosen node as it has been proposed in v2 and v3. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v4: - corrected Devcie Tree mailing list address (resend) - moved back contiguous-memory bindings from /chosen/contiguous-memory to /memory nodes as suggested by Grant (see http://article.gmane.org/gmane.linux.drivers.devicetree/41030 for more details) - added support for DMA reserved memory with dma_declare_coherent() - moved code to drivers/of/of_reserved_mem.c - added generic code to scan specific path in flat device tree v3: http://thread.gmane.org/gmane.linux.drivers.devicetree/40013/ - fixed issues pointed by Laura and updated documentation v2: http://thread.gmane.org/gmane.linux.drivers.devicetree/34075 - moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/ node to avoid spreading Linux specific parameters over the whole device tree definitions - added support for autoconfigured regions (use zero base) - fixes minor bugs v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/ - initial proposal Patch summary: Marek Szyprowski (4): drivers: dma-contiguous: clean source code and prepare for device tree drivers: of: add function to scan fdt nodes given by path drivers: of: add initialization code for dma reserved memory ARM: init: add support for reserved memory defined by device tree Documentation/devicetree/bindings/memory.txt | 152 ++++++++++++++++++++++ arch/arm/mm/init.c | 3 + drivers/base/dma-contiguous.c | 147 +++++++++++----------- drivers/of/Kconfig | 6 + drivers/of/Makefile | 1 + drivers/of/fdt.c | 76 +++++++++++ drivers/of/of_reserved_mem.c | 175 ++++++++++++++++++++++++++ include/asm-generic/dma-coherent.h | 6 + include/asm-generic/dma-contiguous.h | 2 - include/linux/dma-contiguous.h | 49 +++++++- include/linux/of_fdt.h | 3 + 11 files changed, 541 insertions(+), 79 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory.txt create mode 100644 drivers/of/of_reserved_mem.c -- 1.7.9.5

11 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig August 2013