2013-04-29 23:17:12 +00:00
|
|
|
Generic on-chip SRAM
|
|
|
|
|
|
|
|
Simple IO memory regions to be managed by the genalloc API.
|
|
|
|
|
|
|
|
Required properties:
|
|
|
|
|
2016-09-21 22:09:37 +00:00
|
|
|
- compatible : mmio-sram or atmel,sama5d2-securam
|
2013-04-29 23:17:12 +00:00
|
|
|
|
|
|
|
- reg : SRAM iomem address range
|
|
|
|
|
2014-02-26 22:02:52 +00:00
|
|
|
Reserving sram areas:
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
Each child of the sram node specifies a region of reserved memory. Each
|
|
|
|
child node should use a 'reg' property to specify a specific range of
|
|
|
|
reserved memory.
|
|
|
|
|
|
|
|
Following the generic-names recommended practice, node names should
|
|
|
|
reflect the purpose of the node. Unit address (@<address>) should be
|
|
|
|
appended to the name.
|
|
|
|
|
|
|
|
Required properties in the sram node:
|
|
|
|
|
|
|
|
- #address-cells, #size-cells : should use the same values as the root node
|
|
|
|
- ranges : standard definition, should translate from local addresses
|
|
|
|
within the sram to bus addresses
|
|
|
|
|
2016-03-14 08:38:56 +00:00
|
|
|
Optional properties in the sram node:
|
|
|
|
|
|
|
|
- no-memory-wc : the flag indicating, that SRAM memory region has not to
|
|
|
|
be remapped as write combining. WC is used by default.
|
|
|
|
|
2014-02-26 22:02:52 +00:00
|
|
|
Required properties in the area nodes:
|
|
|
|
|
|
|
|
- reg : iomem address range, relative to the SRAM range
|
|
|
|
|
|
|
|
Optional properties in the area nodes:
|
|
|
|
|
|
|
|
- compatible : standard definition, should contain a vendor specific string
|
|
|
|
in the form <vendor>,[<device>-]<usage>
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 20:52:46 +00:00
|
|
|
- pool : indicates that the particular reserved SRAM area is addressable
|
|
|
|
and in use by another device or devices
|
|
|
|
- export : indicates that the reserved SRAM area may be accessed outside
|
|
|
|
of the kernel, e.g. by bootloader or userspace
|
2017-01-12 20:52:20 +00:00
|
|
|
- protect-exec : Same as 'pool' above but with the additional
|
|
|
|
constraint that code wil be run from the region and
|
|
|
|
that the memory is maintained as read-only, executable
|
|
|
|
during code execution. NOTE: This region must be page
|
|
|
|
aligned on start and end in order to properly allow
|
|
|
|
manipulation of the page attributes.
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 20:52:46 +00:00
|
|
|
- label : the name for the reserved partition, if omitted, the label
|
|
|
|
is taken from the node name excluding the unit address.
|
2014-02-26 22:02:52 +00:00
|
|
|
|
2013-04-29 23:17:12 +00:00
|
|
|
Example:
|
|
|
|
|
|
|
|
sram: sram@5c000000 {
|
|
|
|
compatible = "mmio-sram";
|
|
|
|
reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
|
2014-02-26 22:02:52 +00:00
|
|
|
|
2016-04-20 15:32:15 +00:00
|
|
|
#address-cells = <1>;
|
2014-02-26 22:02:52 +00:00
|
|
|
#size-cells = <1>;
|
|
|
|
ranges = <0 0x5c000000 0x40000>;
|
|
|
|
|
|
|
|
smp-sram@100 {
|
|
|
|
compatible = "socvendor,smp-sram";
|
|
|
|
reg = <0x100 0x50>;
|
|
|
|
};
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 20:52:46 +00:00
|
|
|
|
|
|
|
device-sram@1000 {
|
|
|
|
reg = <0x1000 0x1000>;
|
|
|
|
pool;
|
|
|
|
};
|
|
|
|
|
|
|
|
exported@20000 {
|
|
|
|
reg = <0x20000 0x20000>;
|
|
|
|
export;
|
|
|
|
};
|
2013-04-29 23:17:12 +00:00
|
|
|
};
|