From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 1/6] dt-bindings: sram: describe option to reserve parts of the memory
Date: Tue, 25 Feb 2014 14:19:30 +0100 [thread overview]
Message-ID: <201402251419.31151.arnd@arndb.de> (raw)
In-Reply-To: <126672712.tufE5adZWC@phil>
On Tuesday 25 February 2014, Heiko St?bner wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
>
> Therefore add the option to define reserved regions as subnodes of the
> sram-node similar to defining reserved global memory regions.
[adding Sachin Kamat to Cc, he just had the same issue]
> Originally
> Suggested-by: Rob Herring <robherring2@gmail.com>
>
> Using subnodes for reserved regions
> Suggested-by: Grant Likely <grant.likely@linaro.org>
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> ---
> Documentation/devicetree/bindings/misc/sram.txt | 33 +++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..2d83758 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,42 @@ Required properties:
>
> - reg : SRAM iomem address range
>
> +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 be empty
I think we should rather define the 'ranges' property to translate from
addresses within the sram to bus addresses.
> +Required properties in the area nodes:
> +
> +- reg : iomem address range
> +
> +Optional properties in the area nodes:
> +
> +- compatible : standard definition
> +
Is this enough? Normally we should define a list of "compatible" strings
that people can add to, but not have an anything-allowed option.
> Example:
>
> sram: sram at 5c000000 {
> compatible = "mmio-sram";
> reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +
> + #adress-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + smp-sram at 5c000100 {
> + compatible = "socvendor,smp-sram";
> + reg = <0x5c000100 0x50>;
> + };
> };
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Sachin Kamat <sachin.kamat@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
linux-kernel@vger.kernel.org, arm@kernel.org,
Philipp Zabel <p.zabel@pengutronix.de>,
Grant Likely <grant.likely@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 1/6] dt-bindings: sram: describe option to reserve parts of the memory
Date: Tue, 25 Feb 2014 14:19:30 +0100 [thread overview]
Message-ID: <201402251419.31151.arnd@arndb.de> (raw)
In-Reply-To: <126672712.tufE5adZWC@phil>
On Tuesday 25 February 2014, Heiko Stübner wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
>
> Therefore add the option to define reserved regions as subnodes of the
> sram-node similar to defining reserved global memory regions.
[adding Sachin Kamat to Cc, he just had the same issue]
> Originally
> Suggested-by: Rob Herring <robherring2@gmail.com>
>
> Using subnodes for reserved regions
> Suggested-by: Grant Likely <grant.likely@linaro.org>
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> ---
> Documentation/devicetree/bindings/misc/sram.txt | 33 +++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..2d83758 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,42 @@ Required properties:
>
> - reg : SRAM iomem address range
>
> +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 be empty
I think we should rather define the 'ranges' property to translate from
addresses within the sram to bus addresses.
> +Required properties in the area nodes:
> +
> +- reg : iomem address range
> +
> +Optional properties in the area nodes:
> +
> +- compatible : standard definition
> +
Is this enough? Normally we should define a list of "compatible" strings
that people can add to, but not have an anything-allowed option.
> Example:
>
> sram: sram@5c000000 {
> compatible = "mmio-sram";
> reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +
> + #adress-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + smp-sram@5c000100 {
> + compatible = "socvendor,smp-sram";
> + reg = <0x5c000100 0x50>;
> + };
> };
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
arm@kernel.org, Grant Likely <grant.likely@linaro.org>,
Rob Herring <robherring2@gmail.com>,
devicetree@vger.kernel.org,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-kernel@vger.kernel.org,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Sachin Kamat <sachin.kamat@linaro.org>
Subject: Re: [PATCH v8 1/6] dt-bindings: sram: describe option to reserve parts of the memory
Date: Tue, 25 Feb 2014 14:19:30 +0100 [thread overview]
Message-ID: <201402251419.31151.arnd@arndb.de> (raw)
In-Reply-To: <126672712.tufE5adZWC@phil>
On Tuesday 25 February 2014, Heiko Stübner wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
>
> Therefore add the option to define reserved regions as subnodes of the
> sram-node similar to defining reserved global memory regions.
[adding Sachin Kamat to Cc, he just had the same issue]
> Originally
> Suggested-by: Rob Herring <robherring2@gmail.com>
>
> Using subnodes for reserved regions
> Suggested-by: Grant Likely <grant.likely@linaro.org>
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> ---
> Documentation/devicetree/bindings/misc/sram.txt | 33 +++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..2d83758 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,42 @@ Required properties:
>
> - reg : SRAM iomem address range
>
> +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 be empty
I think we should rather define the 'ranges' property to translate from
addresses within the sram to bus addresses.
> +Required properties in the area nodes:
> +
> +- reg : iomem address range
> +
> +Optional properties in the area nodes:
> +
> +- compatible : standard definition
> +
Is this enough? Normally we should define a list of "compatible" strings
that people can add to, but not have an anything-allowed option.
> Example:
>
> sram: sram@5c000000 {
> compatible = "mmio-sram";
> reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
> +
> + #adress-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + smp-sram@5c000100 {
> + compatible = "socvendor,smp-sram";
> + reg = <0x5c000100 0x50>;
> + };
> };
next prev parent reply other threads:[~2014-02-25 13:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 11:44 [PATCH v8 0/6] ARM: rockchip: add smp functionality Heiko Stübner
2014-02-25 11:44 ` Heiko Stübner
2014-02-25 11:44 ` Heiko Stübner
2014-02-25 11:45 ` [PATCH v8 1/6] dt-bindings: sram: describe option to reserve parts of the memory Heiko Stübner
2014-02-25 11:45 ` Heiko Stübner
2014-02-25 11:45 ` Heiko Stübner
2014-02-25 13:19 ` Arnd Bergmann [this message]
2014-02-25 13:19 ` Arnd Bergmann
2014-02-25 13:19 ` Arnd Bergmann
2014-02-26 22:02 ` [PATCH v8.1 " Heiko Stübner
2014-02-26 22:02 ` Heiko Stübner
2014-02-26 22:02 ` Heiko Stübner
2014-02-27 19:16 ` Arnd Bergmann
2014-02-27 19:16 ` Arnd Bergmann
2014-02-27 19:16 ` Arnd Bergmann
2014-02-25 11:46 ` [PATCH v8 2/6] misc: sram: implement reserved sram areas Heiko Stübner
2014-02-25 11:46 ` Heiko Stübner
2014-02-25 11:46 ` Heiko Stübner
2014-03-03 11:29 ` Philipp Zabel
2014-03-03 11:29 ` Philipp Zabel
2014-03-03 11:29 ` Philipp Zabel
2014-02-25 11:47 ` [PATCH v8 3/6] ARM: rockchip: add snoop-control-unit Heiko Stübner
2014-02-25 11:47 ` Heiko Stübner
2014-02-25 11:47 ` [PATCH v8 4/6] ARM: rockchip: add sram dt nodes and documentation Heiko Stübner
2014-02-25 11:47 ` Heiko Stübner
2014-02-25 11:47 ` Heiko Stübner
2014-02-25 11:48 ` [PATCH v8 5/6] ARM: rockchip: add power-management-unit Heiko Stübner
2014-02-25 11:48 ` Heiko Stübner
2014-02-25 11:48 ` [PATCH v8 6/6] ARM: rockchip: add smp bringup code Heiko Stübner
2014-02-25 11:48 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201402251419.31151.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.