Device Tree support for CMA (Contiguous Memory Allocator)

Add a function to scan the flattened device-tree starting from the node given by the path. It is used to extract information (like reserved memory), which is required on early boot before we can unflatten the tree.

Signed-off-by Marek Szyprowski <[email protected]>

Acked-by Michal Nazarewicz <[email protected]>

Acked-by Tomasz Figa <[email protected]>

Quoted 6 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the 

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Hi Stephen,

Quoted 7 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 6 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the 

respective

Quoted 17 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

Quoted 5 lines

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion on this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

This property is not CMA-specific. Any memory region can be given using the memory-region property and used to allocate buffers for particular device.

Quoted 84 lines · Tomasz Figa

Hi Stephen,

Quoted 8 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 7 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory
regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the

respective

Quoted 19 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------

compatible: One or more of:
- "linux,contiguous-memory-region" - enables binding of this

region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).

- "reserved-memory-region" - compatibility is defined, given

region is assigned for exclusive usage for by the respective devices.

Quoted 7 lines

----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion on this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 4 lines

This property is not CMA-specific. Any memory region can be given using
the memory-region property and used to allocate buffers for particular device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a "memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Quoted 135 lines · On Monday 19 of August 2013 16:17:30 Stephen Warren wrote:

Quoted 84 lines · Tomasz Figa

Hi Stephen,

Quoted 8 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 7 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory
regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the

respective

Quoted 19 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------

compatible: One or more of:
- "linux,contiguous-memory-region" - enables binding of this

region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).

- "reserved-memory-region" - compatibility is defined, given

region is assigned for exclusive usage for by the respective devices.

Quoted 7 lines

----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion on this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 4 lines

This property is not CMA-specific. Any memory region can be given using
the memory-region property and used to allocate buffers for particular device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a "memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Well, such setup simply cannot be handled by Linux today, as one device (aka one struct device) can only have one memory region bound to it. So this is not something we can implement today.

I agree that the device tree should be able to describe such configurations,

though, but I'm not sure if this should be done from this side.

Quoted 21 lines · Tomasz Figa

Quoted 20 lines · On Monday 19 of August 2013 16:17:30 Stephen Warren wrote:

Quoted 19 lines · Tomasz Figa

Hi Stephen,

Quoted 16 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Documentation/devicetree/bindings/memory.txt line 35

Quoted 10 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory
regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +3 -0

 
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where
the "additional" nodes should be placed.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 2 lines

Documentation/devicetree/bindings/memory.txt

Quoted 2 lines

this

Documentation/devicetree/bindings/memory.txt +1 -0

+		region to Contiguous Memory Allocator (special 

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Documentation/devicetree/bindings/memory.txt

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		contiguous memory allocations, shared with movable 

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Documentation/devicetree/bindings/memory.txt

Quoted 2 lines

Documentation/devicetree/bindings/memory.txt +2 -0

+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is 

Quoted 115 lines

Quoted 115 lines

Quoted 62 lines

Quoted 1 line

Documentation/devicetree/bindings/memory.txt

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		region is assigned for exclusive usage for by the

respective

Quoted 19 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------

compatible: One or more of:
- "linux,contiguous-memory-region" - enables binding of this

region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).

- "reserved-memory-region" - compatibility is defined, given

region is assigned for exclusive usage for by the respective devices.

Quoted 8 lines

----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region",
or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this
region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion
on this.

Quoted 5 lines

Quoted 5 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been

defined,
they +can be assigned to device nodes to enable respective device

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt

Quoted 3 lines

drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this
binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 5 lines

This property is not CMA-specific. Any memory region can be given using
the memory-region property and used to allocate buffers for particular
device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a
"memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 8 lines

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Well, such setup simply cannot be handled by Linux today, as one device
(aka one struct device) can only have one memory region bound to it. So
this is not something we can implement today.

Don't you just create "fake" struct devices to make this work, so that the top-level struct device is instantiated from DT, and the others created manually in the top-level device's probe routine, and the memory regions get attached to those "fake" child devices? Seems pretty conceptually easy.

Quoted 2 lines

I agree that the device tree should be able to describe such configurations,

good:-)

Quoted 1 line

though, but I'm not sure if this should be done from this side.

I'm not sure what "from this side" means. It seems pretty simple to adjust this patch to allow such HW to be represented, so shouldn't we just do it and be done with the question?

Quoted 12 lines · On Monday 19 of August 2013 16:27:14 Stephen Warren wrote:

Quoted 11 lines · Tomasz Figa

Quoted 10 lines · On Monday 19 of August 2013 16:17:30 Stephen Warren wrote:

Quoted 9 lines · Tomasz Figa

Hi Stephen,

Quoted 6 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 5 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 22 lines

Quoted 22 lines

Quoted 18 lines

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Well, such setup simply cannot be handled by Linux today, as one

Quoted 2 lines

Quoted 2 lines

I agree that the device tree should be able to describe such configurations,

Well, if it's just about modifying the binding to support such cases, but without actually adding support for them in Linux, then I guess it's fine.

Quoted 74 lines · Tomasz Figa

Hi Stephen,

Quoted 7 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 6 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the

respective

Quoted 17 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

Quoted 5 lines

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion on this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 3 lines

This property is not CMA-specific. Any memory region can be given using the memory-region property and used to allocate buffers for particular device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a "memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Hello,

Quoted 132 lines · Stephen Warren

Quoted 5 lines · Tomasz Figa

Hi Stephen,

Quoted 2 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 1 line · Marek Szyprowski

This patch adds device tree support for contiguous and reserved

memory

Quoted 10 lines

Quoted 10 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 8 lines

regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +3 -0

 
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer

where the

Quoted 30 lines

Quoted 3 lines

"additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+        region to Contiguous Memory Allocator (special region for
+        contiguous memory allocations, shared with movable system
+        memory, Linux kernel-specific), alternatively if
+        "reserved-memory-region" - compatibility is defined, given
+        region is assigned for exclusive usage for by the

respective

Quoted 19 lines

Quoted 1 line

+ devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards

"linux,contiguous-memory-allocator-region", or

Quoted 1 line

Quoted 1 line

perhaps "linux,cma-region" since it's not really describing whether

the

Quoted 4 lines

Quoted 2 lines

memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for

"contiguous-memory-

Quoted 1 line

region". The concept of contiguous memory region is rather OS

independent

Quoted 5 lines

and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that

there

Quoted 4 lines

are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong

opinion on

Quoted 14 lines

this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 3 lines

This property is not CMA-specific. Any memory region can be given using the memory-region property and used to allocate buffers for particular device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a "memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Support for multiple regions is something that need to be discussed separately. In case of Exynos hardware it is also related to iommu bindings and configuration, because each busmuster on the internal memory bus has separate iommu controller. Having each busmaster defined as a separate node,
enables to put there the associated memory region and/or iommu controller as
well as dma window properties (in case of limited dma window).

However right now I would like to focus on the simple case (1 device, 1 memory region) and define bindings which can be extended later. I hope that my current proposal covers this (I will send updated binding documentation asap) and the initial support for reserved memory can be merged to -next soon.

Quoted 147 lines · Marek Szyprowski

Hello,

Quoted 132 lines · Stephen Warren

Quoted 5 lines · Tomasz Figa

Hi Stephen,

Quoted 2 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 1 line · Marek Szyprowski

This patch adds device tree support for contiguous and reserved

memory

Quoted 10 lines

Quoted 10 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 8 lines

regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +3 -0

 
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer

where the

Quoted 30 lines

Quoted 3 lines

"additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+        region to Contiguous Memory Allocator (special region for
+        contiguous memory allocations, shared with movable system
+        memory, Linux kernel-specific), alternatively if
+        "reserved-memory-region" - compatibility is defined, given
+        region is assigned for exclusive usage for by the

respective

Quoted 19 lines

Quoted 1 line

+ devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards

"linux,contiguous-memory-allocator-region", or

Quoted 1 line

Quoted 1 line

perhaps "linux,cma-region" since it's not really describing whether

the

Quoted 4 lines

Quoted 2 lines

memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for

"contiguous-memory-

Quoted 1 line

region". The concept of contiguous memory region is rather OS

independent

Quoted 5 lines

and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that

there

Quoted 4 lines

are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong

opinion on

Quoted 14 lines

this.

Quoted 11 lines

Documentation/devicetree/bindings/memory.txt

Quoted 7 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined,

they +can be assigned to device nodes to enable respective device drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 3 lines

This property is not CMA-specific. Any memory region can be given using the memory-region property and used to allocate buffers for particular device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a "memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they may be referenced by other device nodes. Bindings that wish to reference memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a GPU is forced to allocate displayable surfaces from addresses 0..32M and textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Support for multiple regions is something that need to be discussed separately. In case of Exynos hardware it is also related to iommu bindings and configuration, because each busmuster on the internal memory bus has separate iommu controller. Having each busmaster defined as a separate node,
enables to put there the associated memory region and/or iommu controller as
well as dma window properties (in case of limited dma window).

Quoted 5 lines

However right now I would like to focus on the simple case (1 device, 1 memory region) and define bindings which can be extended later. I hope that my current proposal covers this (I will send updated binding documentation asap) and the initial support for reserved memory can be merged to -next soon.

I don't believe that's a good approach unless you have at least a partial idea of how the current bindings will be extended to support multiple memory regions.

Without a clear idea how that will eventually work, you run a real risk of not being able to extend the bindings in a 100% backwards-compatible way, and hence wishing to break DT ABI.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by phandle, and leave it up to individual bindings to define which property they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case

Quoted 186 lines · Marek Szyprowski

Hello,

Quoted 171 lines · Stephen Warren

Quoted 5 lines · Tomasz Figa

Hi Stephen,

Quoted 2 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 1 line · Marek Szyprowski

This patch adds device tree support for contiguous and reserved

memory

Quoted 10 lines

Quoted 10 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 8 lines

regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +3 -0

 
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer

where the

Quoted 14 lines

Quoted 3 lines

"additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 7 lines

Quoted 7 lines

this

Documentation/devicetree/bindings/memory.txt +4 -0

+        region to Contiguous Memory Allocator (special region for
+        contiguous memory allocations, shared with movable system
+        memory, Linux kernel-specific), alternatively if
+        "reserved-memory-region" - compatibility is defined,

given
+ region is assigned for exclusive usage for by the

Quoted 25 lines

respective

Quoted 23 lines

Quoted 1 line

+ devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------

compatible: One or more of:
- "linux,contiguous-memory-region" - enables binding of this

region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).

- "reserved-memory-region" - compatibility is defined, given

region is assigned for exclusive usage for by the respective devices.

----------

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards

"linux,contiguous-memory-allocator-region", or

Quoted 1 line

Quoted 1 line

perhaps "linux,cma-region" since it's not really describing whether

the

Quoted 5 lines

Quoted 3 lines

memory is contiguous (at the level of /memory, each chunk of memory is
contiguous...)

I'm not really sure if we need the "linux" prefix for

"contiguous-memory-

Quoted 1 line

region". The concept of contiguous memory region is rather OS

independent

Quoted 7 lines

and tells us that memory allocated from this region will be contiguous.
IMHO any OS is free to implement its own contiguous memory allocation
method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that

there

Quoted 4 lines

are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong

opinion on

Quoted 16 lines

this.

Quoted 5 lines

Quoted 5 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been

defined,
they +can be assigned to device nodes to enable respective device

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt

Quoted 3 lines

drivers to +access them. The following properties are defined:

Documentation/devicetree/bindings/memory.txt +2 -0

+
+memory-region = <&phandle_to_defined_region>;

I think the naming of that property should more obviously match this
binding and/or compatible value; perhaps cma-region or contiguous-memory-region?

Quoted 5 lines

This property is not CMA-specific. Any memory region can be given using
the memory-region property and used to allocate buffers for particular
device.

OK, that makes sense.

What I'm looking for is some way to make it obvious that when you see a
"memory-region" property in a node, you go look at the "memory.txt" rather than the DT binding for the node where that property appears. Right now, it doesn't seem that obvious to me.

I think the real issue here is that my brief reading of memory.txt implies that arbitrary device nodes can include the memory-region property without the node's own binding having to document it; the property name is essentially "forced into" all other bindings.

I think instead, memory.txt should say:

----------
** Device node's properties ***

Once regions in the /memory/reserved-memory node have been defined, they
may be referenced by other device nodes. Bindings that wish to reference
memory regions should explicitly document their use of the following property:

memory-region = <&phandle_to_defined_region>;

This property indicates that the device driver should use the memory region pointed by the given phandle.
----------

Also, what if a device needs multiple separate memory regions? Perhaps a
GPU is forced to allocate displayable surfaces from addresses 0..32M and
textures/off-screen-render-targets from 256M..384M or something whacky like that. In that case, we could either:

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

or:

b) Adjust memory.txt not to mention any specific property names, but simply mention that other DT nodes can refer to define memory regions by
phandle, and leave it up to individual bindings to define which property
they use to reference the memory regions, perhaps with memory.txt providing a recommendation of memory-region for the simple case, but perhaps also allowing a custom case, e.g.:

Quoted 2 lines

display-memory-region = <&phandl1e1>;
texture-memory-region = <&phahndle2>;

Support for multiple regions is something that need to be discussed separately. In case of Exynos hardware it is also related to iommu bindings and configuration, because each busmuster on the internal memory bus has separate iommu controller. Having each busmaster defined as a separate node,
enables to put there the associated memory region and/or iommu controller as
well as dma window properties (in case of limited dma window).

Quoted 6 lines

However right now I would like to focus on the simple case (1 device, 1 memory region) and define bindings which can be extended later. I hope that my current proposal covers this (I will send updated binding
documentation asap) and the initial support for reserved memory can be merged to -next soon.

I don't believe that's a good approach unless you have at least a partial idea of how the current bindings will be extended to support multiple memory regions.

Without a clear idea how that will eventually work, you run a real risk of not being able to extend the bindings in a 100% backwards-compatible way, and hence wishing to break DT ABI.

Quoted 6 lines · On Tuesday 20 of August 2013 10:35:51 Stephen Warren wrote:

Quoted 3 lines

Quoted 3 lines

a) Adjust memory.txt to allow multiple entries in memory-regions, and add an associated memory-region-names property.

I don't believe that's a good approach unless you have at least a partial idea of how the current bindings will be extended to support multiple memory regions.

I believe that at least three "at least partial" ideas have been brought in this thread. Moreover, I don't think that defining the simple binding now would stop us from extending it according to any of those ideas in any way.

Hi Stephen,

Quoted 7 lines · On Monday 19 of August 2013 15:49:20 Stephen Warren wrote:

Quoted 6 lines · Marek Szyprowski

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Documentation/devicetree/bindings/memory.txt +0 -0

Quoted 8 lines

Documentation/devicetree/bindings/memory.txt line 35

Quoted 3 lines

Documentation/devicetree/bindings/memory.txt +3 -0

+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes

s/additional/child/ or s/additional/sub/ would make it clearer where the "additional" nodes should be placed.

Quoted 1 line

+compatible: "linux,contiguous-memory-region" - enables binding

of

Quoted 6 lines

Documentation/devicetree/bindings/memory.txt

Quoted 6 lines

this

Documentation/devicetree/bindings/memory.txt +5 -0

+		region to Contiguous Memory Allocator (special region for
+		contiguous memory allocations, shared with movable system
+		memory, Linux kernel-specific), alternatively if
+		"reserved-memory-region" - compatibility is defined, given
+		region is assigned for exclusive usage for by the 

respective

Quoted 17 lines

Documentation/devicetree/bindings/memory.txt line 58

Quoted 1 line

Documentation/devicetree/bindings/memory.txt +1 -0

+		devices

"alternatively" makes it sound like the two compatible values are mutually-exclusive. Perhaps make this a list, like:

----------
compatible: One or more of:

- "linux,contiguous-memory-region" - enables binding of this region to Contiguous Memory Allocator (special region for contiguous memory allocations, shared with movable system memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given region is assigned for exclusive usage for by the respective devices.
----------

Quoted 5 lines

"linux,contiguous-memory-region" is already long enough, but I'd slightly bikeshed towards "linux,contiguous-memory-allocator-region", or perhaps "linux,cma-region" since it's not really describing whether the memory is contiguous (at the level of /memory, each chunk of memory is contiguous...)

I'm not really sure if we need the "linux" prefix for "contiguous-memory- region". The concept of contiguous memory region is rather OS independent and tells us that memory allocated from this region will be contiguous. IMHO any OS is free to implement its own contiguous memory allocation method, without being limited to Linux CMA.

Keep in mind that rationale behind those contiguous regions was that there are devices that require buffers contiguous in memory to operate correctly.

But this is just nitpicking and I don't really have any strong opinion on this.

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Large memory blocks can be reliably reserved only during early boot. This must happen before the whole memory management subsystem is initialized, because we need to ensure that the given contiguous blocks are not yet allocated by kernel. Also it must happen before kernel mappings for the whole low memory are created, to ensure that there will be no mappings (for reserved blocks) or mapping with special properties can be created (for CMA blocks). This all happens before device tree structures are unflattened, so we need to get reserved memory layout directly from fdt.

Later, those reserved memory regions are assigned to devices on each device structure initialization.

Signed-off-by Marek Szyprowski <[email protected]>

Acked-by Kyungmin Park <[email protected]>

Acked-by Michal Nazarewicz <[email protected]>

Acked-by Tomasz Figa <[email protected]>

---
 Documentation/devicetree/bindings/memory.txt |  166 ++++++++++++++++++++++++
 drivers/of/Kconfig                           |    6 +
 drivers/of/Makefile                          |    1 +
 drivers/of/of_reserved_mem.c                 |  175 ++++++++++++++++++++++++++
 drivers/of/platform.c                        |    5 +
 include/linux/of_reserved_mem.h              |   14 +++
 6 files changed, 367 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory.txt
 create mode 100644 drivers/of/of_reserved_mem.c
 create mode 100644 include/linux/of_reserved_mem.h

Documentation/devicetree/bindings/memory.txt new file +166 -0

new file mode 100644
index 0000000..90e96278
@@ -0,0 +1,166 @@
+*** Memory binding ***
+
+The /memory node provides basic information about the address and size
+of the physical memory. This node is usually filled or updated by the
+bootloader, depending on the actual memory configuration of the given
+hardware.
+
+The memory layout is described by the following node:
+
+/ {
+       #address-cells = <(n)>;
+       #size-cells = <(m)>;
+       memory {
+               device_type = "memory";
+               reg =  <(baseaddr1) (size1)
+                       (baseaddr2) (size2)
+                       ...
+                       (baseaddrN) (sizeN)>;
+       };
+       ...
+};
+
+A memory node follows the typical device tree rules for "reg" property:
+n:             number of cells used to store base address value
+m:             number of cells used to store size value
+baseaddrX:     defines a base address of the defined memory bank
+sizeX:         the size of the defined memory bank
+
+
+More than one memory bank can be defined.
+
+
+*** Reserved memory regions ***
+
+In /memory/reserved-memory node one can create additional nodes
+describing particular reserved (excluded from normal use) memory
+regions. Such memory regions are usually designed for the special usage
+by various device drivers. A good example are contiguous memory
+allocations or memory sharing with other operating system on the same
+hardware board. Those special memory regions might depend on the board
+configuration and devices used on the target system.
+
+Parameters for each memory region can be encoded into the device tree
+with the following convention:
+
+[(label):] (name) {
+       compatible = "linux,contiguous-memory-region", "reserved-memory-region";
+       reg = <(address) (size)>;
+       (linux,default-contiguous-region);
+};
+
+compatible:    "linux,contiguous-memory-region" - enables binding of this
+               region to Contiguous Memory Allocator (special region for
+               contiguous memory allocations, shared with movable system
+               memory, Linux kernel-specific), alternatively if
+               "reserved-memory-region" - compatibility is defined, given
+               region is assigned for exclusive usage for by the respective
+               devices
+
+reg:           standard property defining the base address and size of
+               the memory region
+
+linux,default-contiguous-region: property indicating that the region
+               is the default region for all contiguous memory
+               allocations, Linux specific (optional)
+
+It is optional to specify the base address, so if one wants to use
+autoconfiguration of the base address, '0' can be specified as a base
+address in the 'reg' property.
+
+The /memory/reserved-memory node must contain the same #address-cells
+and #size-cells value as the root node.
+
+
+*** Device node's properties ***
+
+Once regions in the /memory/reserved-memory node have been defined, they
+can be assigned to device nodes to enable respective device drivers to
+access them. The following properties are defined:
+
+memory-region = <&phandle_to_defined_region>;
+
+This property indicates that the device driver should use the memory
+region pointed by the given phandle.
+
+
+*** Example ***
+
+This example defines a memory consisting of 4 memory banks. 3 contiguous
+regions are defined for Linux kernel, one default of all device drivers
+(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the
+framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB)
+and one for multimedia processing (labelled multimedia_mem, placed at
+0x77000000, 64MiB). 'display_mem' region is then assigned to fb at 12300000
+device for DMA memory allocations (Linux kernel drivers will use CMA is
+available or dma-exclusive usage otherwise). 'multimedia_mem' is
+assigned to scaler at 12500000 and codec at 12600000 devices for contiguous
+memory allocations when CMA driver is enabled.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer base address to the one configured by bootloader,
+so once Linux kernel drivers starts no glitches on the displayed boot
+logo appears. Scaller and codec drivers should share the memory
+allocations.
+
+/ {
+       #address-cells = <1>;
+       #size-cells = <1>;
+
+       /* ... */
+
+       memory {
+               reg =  <0x40000000 0x10000000
+                       0x50000000 0x10000000
+                       0x60000000 0x10000000
+                       0x70000000 0x10000000>;
+
+               reserved-memory {
+                       #address-cells = <1>;
+                       #size-cells = <1>;
+
+                       /*
+                        * global autoconfigured region for contiguous allocations
+                        * (used only with Contiguous Memory Allocator)
+                        */
+                       contig_region at 0 {
+                               compatible = "linux,contiguous-memory-region";
+                               reg = <0x0 0x4000000>;
+                               linux,default-contiguous-region;
+                       };
+
+                       /*
+                        * special region for framebuffer
+                        */
+                       display_mem: region at 78000000 {
+                               compatible = "linux,contiguous-memory-region", "reserved-memory-region";
+                               reg = <0x78000000 0x800000>;
+                       };
+
+                       /*
+                        * special region for multimedia processing devices
+                        */
+                       multimedia_mem: region at 77000000 {
+                               compatible = "linux,contiguous-memory-region";
+                               reg = <0x77000000 0x4000000>;
+                       };
+               };
+       };
+
+       /* ... */
+
+       fb0: fb at 12300000 {
+               status = "okay";
+               memory-region = <&display_mem>;
+       };
+
+       scaler: scaler at 12500000 {
+               status = "okay";
+               memory-region = <&multimedia_mem>;
+       };
+
+       codec: codec at 12600000 {
+               status = "okay";
+               memory-region = <&multimedia_mem>;
+       };
+};

drivers/of/Kconfig +6 -0

index 80e5c13..a83ab43 100644
@@ -80,4 +80,10 @@ config OF_MTD
        depends on MTD
        def_bool y
 
+config OF_RESERVED_MEM
+       depends on CMA || (HAVE_GENERIC_DMA_COHERENT && HAVE_MEMBLOCK)
+       def_bool y
+       help
+         Initialization code for DMA reserved memory
+
 endmenu # OF

drivers/of/Makefile +1 -0

index 1f9c0c4..e7e3322 100644
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
 obj-$(CONFIG_OF_PCI)   += of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 obj-$(CONFIG_OF_MTD)   += of_mtd.o
+obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o

drivers/of/of_reserved_mem.c new file +175 -0

new file mode 100644
index 0000000..95563d33
@@ -0,0 +1,175 @@
+/*
+ * Device tree based initialization code for reserved memory.
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ *             http://www.samsung.com
+ * Author: Marek Szyprowski <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+#include <asm/dma-contiguous.h>
+
+#include <linux/memblock.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
+#include <linux/mm.h>
+#include <linux/sizes.h>
+#include <linux/mm_types.h>
+#include <linux/dma-contiguous.h>
+#include <linux/dma-mapping.h>
+#include <linux/of_reserved_mem.h>
+
+#define MAX_RESERVED_REGIONS   16
+struct reserved_mem {
+       phys_addr_t             base;
+       unsigned long           size;
+       struct cma              *cma;
+       char                    name[32];
+};
+static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static int reserved_mem_count;
+
+static int __init fdt_scan_reserved_mem(unsigned long node, const char *uname,
+                                       int depth, void *data)
+{
+       struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
+       phys_addr_t base, size;
+       int is_cma, is_reserved;
+       unsigned long len;
+       const char *status;
+       __be32 *prop;
+
+       is_cma = IS_ENABLED(CONFIG_CMA) &&
+              of_flat_dt_is_compatible(node, "linux,contiguous-memory-region");
+       is_reserved = of_flat_dt_is_compatible(node, "reserved-memory-region");
+
+       if (!is_reserved && !is_cma) {
+               /* ignore node and scan next one */
+               return 0;
+       }
+
+       status = of_get_flat_dt_prop(node, "status", &len);
+       if (status && strcmp(status, "okay") != 0) {
+               /* ignore disabled node nad scan next one */
+               return 0;
+       }
+
+       prop = of_get_flat_dt_prop(node, "reg", &len);
+       if (!prop || (len < (dt_root_size_cells + dt_root_addr_cells) *
+                            sizeof(__be32))) {
+               pr_err("Reserved mem: node %s, incorrect \"reg\" property\n",
+                      uname);
+               /* ignore node and scan next one */
+               return 0;
+       }
+       base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+       size = dt_mem_next_cell(dt_root_size_cells, &prop);
+
+       if (!size) {
+               /* ignore node and scan next one */
+               return 0;
+       }
+
+       pr_info("Reserved mem: found %s, memory base %lx, size %ld MiB\n",
+               uname, (unsigned long)base, (unsigned long)size / SZ_1M);
+
+       if (reserved_mem_count == ARRAY_SIZE(reserved_mem))
+               return -ENOSPC;
+
+       rmem->base = base;
+       rmem->size = size;
+       strlcpy(rmem->name, uname, sizeof(rmem->name));
+
+       if (is_cma) {
+               struct cma *cma;
+               if (dma_contiguous_reserve_area(size, base, 0, &cma) == 0) {
+                       rmem->cma = cma;
+                       reserved_mem_count++;
+                       if (of_get_flat_dt_prop(node,
+                                               "linux,default-contiguous-region",
+                                               NULL))
+                               dma_contiguous_default_area = cma;
+               }
+       } else if (is_reserved) {
+               if (memblock_remove(base, size) == 0)
+                       reserved_mem_count++;
+               else
+                       pr_err("Failed to reserve memory for %s\n", uname);
+       }
+
+       return 0;
+}
+
+static struct reserved_mem *get_dma_memory_region(struct device *dev)
+{
+       struct device_node *node;
+       const char *name;
+       int i;
+
+       node = of_parse_phandle(dev->of_node, "memory-region", 0);
+       if (!node)
+               return NULL;
+
+       name = kbasename(node->full_name);
+       for (i = 0; i < reserved_mem_count; i++)
+               if (strcmp(name, reserved_mem[i].name) == 0)
+                       return &reserved_mem[i];
+       return NULL;
+}
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given device
+ *
+ * This function assign memory region pointed by "memory-region" device tree
+ * property to the given device.
+ */
+void of_reserved_mem_device_init(struct device *dev)
+{
+       struct reserved_mem *region = get_dma_memory_region(dev);
+       if (!region)
+               return;
+
+       if (region->cma) {
+               dev_set_cma_area(dev, region->cma);
+               pr_info("Assigned CMA %s to %s device\n", region->name,
+                       dev_name(dev));
+       } else {
+               if (dma_declare_coherent_memory(dev, region->base, region->base,
+                   region->size, DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) != 0)
+                       pr_info("Declared reserved memory %s to %s device\n",
+                               region->name, dev_name(dev));
+       }
+}
+
+/**
+ * of_reserved_mem_device_release() - release reserved memory device structures
+ *
+ * This function releases structures allocated for memory region handling for
+ * the given device.
+ */
+void of_reserved_mem_device_release(struct device *dev)
+{
+       struct reserved_mem *region = get_dma_memory_region(dev);
+       if (!region && !region->cma)
+               dma_release_declared_memory(dev);
+}
+
+/**
+ * early_init_dt_scan_reserved_mem() - create reserved memory regions
+ *
+ * This function grabs memory from early allocator for device exclusive use
+ * defined in device tree structures. It should be called by arch specific code
+ * once the early allocator (memblock) has been activated and all other
+ * subsystems have already allocated/reserved memory.
+ */
+void __init early_init_dt_scan_reserved_mem(void)
+{
+       of_scan_flat_dt_by_path("/memory/reserved-memory",
+                               fdt_scan_reserved_mem, NULL);
+}

drivers/of/platform.c +5 -0

index e0a6514..1e4e91d 100644
@@ -21,6 +21,7 @@
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
 
 const struct of_device_id of_default_bus_match_table[] = {

@@ -196,6 +197,7 @@ EXPORT_SYMBOL(of_device_alloc);
  * Returns pointer to created platform device, or NULL if a device was not
  * registered.  Unavailable devices will not get registered.
  */
+
 struct platform_device *of_platform_device_create_pdata(
                                        struct device_node *np,
                                        const char *bus_id,

@@ -218,6 +220,8 @@ struct platform_device *of_platform_device_create_pdata(
        dev->dev.bus = &platform_bus_type;
        dev->dev.platform_data = platform_data;
 
+       of_reserved_mem_device_init(&dev->dev);
+
        /* We do not fill the DMA ops for platform devices by default.
         * This is currently the responsibility of the platform code
         * to do such, possibly using a device notifier

@@ -225,6 +229,7 @@ struct platform_device *of_platform_device_create_pdata(
 
        if (of_device_add(dev) != 0) {
                platform_device_put(dev);
+               of_reserved_mem_device_release(&dev->dev);
                return NULL;
        }
 

include/linux/of_reserved_mem.h new file +14 -1

new file mode 100644
index 0000000..c841282
@@ -0,0 +1,14 @@
+#ifndef __OF_RESERVED_MEM_H
+#define __OF_RESERVED_MEM_H
+
+#ifdef CONFIG_OF_RESERVED_MEM
+void of_reserved_mem_device_init(struct device *dev);
+void of_reserved_mem_device_release(struct device *dev);
+void early_init_dt_scan_reserved_mem(void);
+#else
+static inline void of_reserved_mem_device_init(struct device *dev) { }
+static inline void of_reserved_mem_device_release(struct device *dev) { }
+static inline void early_init_dt_scan_reserved_mem(void) { }
+#endif
+
+#endif /* __OF_RESERVED_MEM_H */
--

1.7.9.5

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

From: Marek Szyprowski <[email protected]>

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Large memory blocks can be reliably reserved only during early boot. This must happen before the whole memory management subsystem is initialized, because we need to ensure that the given contiguous blocks are not yet allocated by kernel. Also it must happen before kernel mappings for the whole low memory are created, to ensure that there will be no mappings (for reserved blocks) or mapping with special properties can be created (for CMA blocks). This all happens before device tree structures are unflattened, so we need to get reserved memory layout directly from fdt.

Later, those reserved memory regions are assigned to devices on each device structure initialization.

Documentation/devicetree/bindings/memory.txt +2 -0

+*** Example ***
 
+		reserved-memory {

Documentation/devicetree/bindings/memory.txt +1 -0

+			contig_region at 0 {

Documentation/devicetree/bindings/memory.txt +1 -0

+			display_mem: region at 78000000 {

This patch adds device tree support for contiguous and reserved memory regions defined in device tree.

Large memory blocks can be reliably reserved only during early boot. This must happen before the whole memory management subsystem is initialized, because we need to ensure that the given contiguous blocks are not yet allocated by kernel. Also it must happen before kernel mappings for the whole low memory are created, to ensure that there will be no mappings (for reserved blocks) or mapping with special properties can be created (for CMA blocks). This all happens before device tree structures are unflattened, so we need to get reserved memory layout directly from fdt.

Later, those reserved memory regions are assigned to devices on each device structure initialization.

Signed-off-by Marek Szyprowski <[email protected]>

Acked-by Kyungmin Park <[email protected]>

Acked-by Michal Nazarewicz <[email protected]>

Acked-by Tomasz Figa <[email protected]>