[PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
Here is my initial proposal for device tree integration for Contiguous
Memory Allocator. The code is quite straightforward, however I expect
that the memory bindings require some discussion.
The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.
Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (2):
drivers: dma-contiguous: clean source code and prepare for device
tree
drivers: dma-contiguous: add initialization from device tree
Documentation/devicetree/bindings/memory.txt | 101 ++
arch/arm/boot/dts/skeleton.dtsi |7 +-
drivers/base/dma-contiguous.c| 278 +++---
include/asm-generic/dma-contiguous.h |4 +-
include/linux/dma-contiguous.h | 32 ++-
5 files changed, 338 insertions(+), 84 deletions(-)
create mode 100644 Documentation/devicetree/bindings/memory.txt
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hi Marek, On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: > Hello, > > Here is my initial proposal for device tree integration for Contiguous > Memory Allocator. The code is quite straightforward, however I expect > that the memory bindings require some discussion. > > The proposed bindings allows to define contiguous memory regions of > specified base address and size. Then, the defined regions can be > assigned to the given device(s) by adding a property with a phanle to > the defined contiguous memory region. From the device tree perspective > that's all. Once the bindings are added, all the memory allocations from > dma-mapping subsystem will be served from the defined contiguous memory > regions. > I think CMA regions should not be described in the devicetre at all. The devicetree is about hardware description and it should be OS agnostic, but CMA is only a Linux specific implementation detail. It's not even specific to a particular board, it's specific to a particular usecase of a board. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hi, On 02/14/2013 10:30 PM, Sascha Hauer wrote: On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: ... Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. I think CMA regions should not be described in the devicetre at all. The devicetree is about hardware description and it should be OS agnostic, but CMA is only a Linux specific implementation detail. It's not even specific to a particular board, it's specific to a particular usecase of a board. I disagree. For example, in a multiprocessor system describing the memory regions this way allows to assign memory to each subsystem, e.g. shared memory, so that the memory region constraints are satisfied. CMA just happens to be an implementation of a method of assigning memory to each device in Linux. The constraints on the memory are real hardware constraints, resulting from a particular subsystem architecture. --- Thanks, Sylwester ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
On Thu, Feb 14, 2013 at 11:08:54PM +0100, Sylwester Nawrocki wrote: > Hi, > > On 02/14/2013 10:30 PM, Sascha Hauer wrote: > >On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: > ... > >>Here is my initial proposal for device tree integration for Contiguous > >>Memory Allocator. The code is quite straightforward, however I expect > >>that the memory bindings require some discussion. > >> > >>The proposed bindings allows to define contiguous memory regions of > >>specified base address and size. Then, the defined regions can be > >>assigned to the given device(s) by adding a property with a phanle to > >>the defined contiguous memory region. From the device tree perspective > >>that's all. Once the bindings are added, all the memory allocations from > >>dma-mapping subsystem will be served from the defined contiguous memory > >>regions. > >> > > > >I think CMA regions should not be described in the devicetre at all. The > >devicetree is about hardware description and it should be OS agnostic, > >but CMA is only a Linux specific implementation detail. It's not even > >specific to a particular board, it's specific to a particular usecase of > >a board. > > I disagree. For example, in a multiprocessor system describing the memory > regions this way allows to assign memory to each subsystem, e.g. shared > memory, so that the memory region constraints are satisfied. > > CMA just happens to be an implementation of a method of assigning memory > to each device in Linux. The constraints on the memory are real hardware > constraints, resulting from a particular subsystem architecture. If you are talking about DMA controllers which can only access a certain memory area, then yes, that's a hardware constraint, I'm not sure though if describing this as CMA in the devicetree is the way to go. If you are talking about 'on this board I want to have 128MiB for this device because I'm doing 1080p while on another board 64MiB are enough because I'm doing 720p', then this is not a hardware constraint. There may be valid scenarios for putting CMA into the devicetrees, but doing this also opens the door for abuse of this binding. I for once don't want to find areas being allocated for CMA in the devicetree for devices I don't care about. I know I can always exchange a devicetree, but I think the devicetree should be seen as firmware to a certain degree. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
On 02/15/2013 02:33 AM, Sascha Hauer wrote: > On Thu, Feb 14, 2013 at 11:08:54PM +0100, Sylwester Nawrocki wrote: >> Hi, >> >> On 02/14/2013 10:30 PM, Sascha Hauer wrote: >>> On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: >> ... Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. >>> >>> I think CMA regions should not be described in the devicetre at all. The >>> devicetree is about hardware description and it should be OS agnostic, >>> but CMA is only a Linux specific implementation detail. It's not even >>> specific to a particular board, it's specific to a particular usecase of >>> a board. >> >> I disagree. For example, in a multiprocessor system describing the memory >> regions this way allows to assign memory to each subsystem, e.g. shared >> memory, so that the memory region constraints are satisfied. >> >> CMA just happens to be an implementation of a method of assigning memory >> to each device in Linux. The constraints on the memory are real hardware >> constraints, resulting from a particular subsystem architecture. > > If you are talking about DMA controllers which can only access a certain > memory area, then yes, that's a hardware constraint, I'm not sure though > if describing this as CMA in the devicetree is the way to go. > > If you are talking about 'on this board I want to have 128MiB for this > device because I'm doing 1080p while on another board 64MiB are enough > because I'm doing 720p', then this is not a hardware constraint. > > There may be valid scenarios for putting CMA into the devicetrees, but > doing this also opens the door for abuse of this binding. I for once > don't want to find areas being allocated for CMA in the devicetree for > devices I don't care about. I know I can always exchange a devicetree, > but I think the devicetree should be seen as firmware to a certain > degree. I agree this does not belong in DT. As a kernel developer, the DT comes from firmware. Can the firmware author decide how much CMA memory is needed? I don't think so. I would suggest a kernel command line parameter instead if that does not already exist. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
On 02/15/2013 09:33 AM, Sascha Hauer wrote: On Thu, Feb 14, 2013 at 11:08:54PM +0100, Sylwester Nawrocki wrote: On 02/14/2013 10:30 PM, Sascha Hauer wrote: On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote: ... Here is my initial proposal for device tree integration for Contiguous Memory Allocator. The code is quite straightforward, however I expect that the memory bindings require some discussion. The proposed bindings allows to define contiguous memory regions of specified base address and size. Then, the defined regions can be assigned to the given device(s) by adding a property with a phanle to the defined contiguous memory region. From the device tree perspective that's all. Once the bindings are added, all the memory allocations from dma-mapping subsystem will be served from the defined contiguous memory regions. I think CMA regions should not be described in the devicetre at all. The devicetree is about hardware description and it should be OS agnostic, but CMA is only a Linux specific implementation detail. It's not even specific to a particular board, it's specific to a particular usecase of a board. I disagree. For example, in a multiprocessor system describing the memory regions this way allows to assign memory to each subsystem, e.g. shared memory, so that the memory region constraints are satisfied. CMA just happens to be an implementation of a method of assigning memory to each device in Linux. The constraints on the memory are real hardware constraints, resulting from a particular subsystem architecture. If you are talking about DMA controllers which can only access a certain memory area, then yes, that's a hardware constraint, I'm not sure though if describing this as CMA in the devicetree is the way to go. My context was a multiprocessor SoC, where one of the processors is somehow application specific (e.g. camera ISP) and can be considered as a slave subsystem, running it's firmware and sharing system memory with the main processor. The slave subsystem can have insane constraints on the memory region where its firmware is located and which it also uses as its generic purpose RAM. While the region assigned to such a slave device would also likely include a memory for its DMA buffers, the main concern here was an allocation of a working memory for the slave processor. Perhaps the device tree is not a perfect place for defining exact memory regions. If we happen to decide against it, then I guess some set of properties would be needed, that would allow CMA to assign appropriate memory region(s) to a device. If you are talking about 'on this board I want to have 128MiB for this device because I'm doing 1080p while on another board 64MiB are enough because I'm doing 720p', then this is not a hardware constraint. No, that's not something I was referring to. There may be valid scenarios for putting CMA into the devicetrees, but doing this also opens the door for abuse of this binding. I for once don't want to find areas being allocated for CMA in the devicetree for devices I don't care about. I know I can always exchange a devicetree, but I think the device tree should be seen as firmware to a certain degree. I agree. You're likely aware of it, I just want to remind that the CMA memory can be used by the OS in a normal way, until a device driver actually allocates and uses it. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
On Mon, Feb 18, 2013 at 2:25 PM, Sylwester Nawrocki wrote: > My context was a multiprocessor SoC, where one of the processors is somehow > application specific (e.g. camera ISP) and can be considered as a slave > subsystem, running it's firmware and sharing system memory with the main > processor. > > The slave subsystem can have insane constraints on the memory region where > its firmware is located and which it also uses as its generic purpose RAM. > > While the region assigned to such a slave device would also likely include > a memory for its DMA buffers, the main concern here was an allocation of > a working memory for the slave processor. > > Perhaps the device tree is not a perfect place for defining exact memory > regions. If we happen to decide against it, then I guess some set of > properties would be needed, that would allow CMA to assign appropriate > memory region(s) to a device. The place to add such constraints are in the bindings for the camera ISP. This isn't that different from how dma-window properties used on some of the PowerPC platforms; it specifies (among other things) the available address space as seen from the bus/device side. -Olof ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
It took me some time to get back to this topic due to my holidays and other
urgent issues. I hope that this I will be able to participate a bit more
actively.
On 2/14/2013 10:30 PM, Sascha Hauer wrote:
Hi Marek,
On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote:
> Hello,
>
> Here is my initial proposal for device tree integration for Contiguous
> Memory Allocator. The code is quite straightforward, however I expect
> that the memory bindings require some discussion.
>
> The proposed bindings allows to define contiguous memory regions of
> specified base address and size. Then, the defined regions can be
> assigned to the given device(s) by adding a property with a phanle to
> the defined contiguous memory region. From the device tree perspective
> that's all. Once the bindings are added, all the memory allocations from
> dma-mapping subsystem will be served from the defined contiguous memory
> regions.
>
I think CMA regions should not be described in the devicetre at all. The
devicetree is about hardware description and it should be OS agnostic,
but CMA is only a Linux specific implementation detail. It's not even
specific to a particular board, it's specific to a particular usecase of
a board.
Well, I see your point. The main problem is the fact that board files
consisted
of both hw related definitions AND particular kernel configuration for
the device
drivers (like the dma_declare_contiguous() calls for example). Now hw
related
definitions are being moved to device tree, but what should we do with the
kernel configuration data, which was previously in the board files? I
know that
in the ideal scenario there should be no such data at all and all
drivers should
be able to automatically configure all related parameters or give
userspace a
method for changing them in runtime. The real world is not ideal
however. There
is a set of kernel configuration data/parameters which can be set only once,
usually early in the boot process. How should we handle it?
There is kernel command line parameter (surprisingly stored also in
device tree,
which should not have such data...), but it intended mainly for
debug/development
purposes and simple, usually one value parameters.
There have been discussion about CMA configuration via kernel cmd line
long time
ago (in early CMA development days), but such attempt has been rejected,
because
it introduced too complicated kernel parameters, see
http://thread.gmane.org/gmane.linux.kernel.mm/50669/focus=50679
So we need another solution. I'm aware of the idea that DT should be
limited to
hw description. This principle is good and it might let us to find some
better,
more generic approach. However, we already have some of Linux kernel
specific
attributes ("git grep 'linux,' -- Documentation/devicetree | wc -l"
gives 71,
most of them are in keypad and buttons drivers).
Are there any KNOWN use cases for using exiting DTS from Linux kernel
with other
operating systems? I believe that 99% of the DTS files will be both
developed and
used only together with Linux kernel. I'm also seeing the DT as a generic
way of describing different variants of the same hardware (what is quite
common
in the development process) and a method for standardizing the hw
description
to ease the developers (for a good example please just compare some old
OMAP and
Exynos board files - each used completely different way of describing
the same
things).
The CMA DT patches are quite short and lets anyone to put the required
kernel
configuration together with the respective HW definitions in a very
convenient
way. Especially referencing regions and device entries by phandle
pointers allows
us to avoid any text-based config entries and in-kernel parsers for them.
If the presented approach is definitely prohibited then what way should
we go?
As an alternative I'm thinking about extending 'chosen' node for such cases.
Embedding the CMA configuration data into a few sub-nodes and attributes
there
should not be a problem. It would also keep all the config related
entries in
a single place. The another advantage I see is the possibility to update
'chosen' node from the extended dt-aware bootloaders, which might also
let one
to edit them. What's your opinion?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Linaro-mm-sig] [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
On 02/16/2013 11:18 PM, Nishanth Peethambaran wrote: > Limiting the scope of the product to a particular use-case (720p or > 1080p video playback) will be part of firmware mostly OTP-ed in the > SoC. Firmware author could decide the amount of CMA memory needed and > put this as part of DT. What kernel developer would want a firmware author deciding how much memory is needed? It is not a decision that can be made without knowledge of the OS. While the frame size could be determined easily enough based on resolution, the number of buffers needed cannot. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
