devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Matt Sealey <neko@bakuhatsu.net>
Cc: Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	Grant Likely <grant.likely@linaro.org>,
	Ulrich Prinz <ulrich.prinz@googlemail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Olof Johansson <olof@lixom.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved
Date: Thu, 1 Aug 2013 18:35:21 +0200	[thread overview]
Message-ID: <201308011835.22186.heiko@sntech.de> (raw)
In-Reply-To: <CAHCPf3vSQHtRkk-_cs3monHfrF-hVx3vTDt1ctcax_bspXDmsg@mail.gmail.com>

Am Montag, 29. Juli 2013, 23:39:45 schrieb Matt Sealey:
> On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel <p.zabel@pengutronix.de> 
wrote:
> > Hi Heiko,
> > 
> > Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko Stübner:
> >> 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 an option mmio-sram-reserved to keep arbitrary portions of
> >> the sram from being part of the pool.
> >> 
> >> Suggested-by: Rob Herring <robherring2@gmail.com>
> >> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> >> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> >> ---
> >> Philipp: I didn't carry the ack, because the loop changed significantly
> >> again. So if it looks ok, could you re-ack it please?
> > 
> > I'd prefer the first loop to contain the magic and produce a list of
> > useable chunks, instead of a list of reserved blocks. The second loop
> > could then iterate over the array and just call gen_pool_add_virt
> > repeatedly.
> > 
> > regards
> > Philipp
> 
> Agreed, however specifying chunks of memory should probably match the
> format of the standard memory@ node "available" property - mostly
> because it would be the same syntax and definition as defining any
> other chunk of memory, as OpenFirmware and device trees have been
> doing since the dark ages. In this case, why not re-use the
> "available" property name instead of creating a new one? Standard OF
> memory parsing code is then free for you to use to pull the chunks
> out.

Sound interesting, but could you give me a pointer to some sort of docs about 
this "available" property in memory nodes?

Documentation/devicetree/booting-without-of.txt seems to be the only file 
describing the memory node at all but only required properties, and not any 
"available" property.

I've found a document  on power.org describing the memory node, but also not 
mentioning any "available" property.

And devicetree.org does not seem to handle the memory node at all.


Thanks for any hints
Heiko

  reply	other threads:[~2013-08-01 16:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29 13:10 [PATCH v4 0/6] ARM: rockchip: add smp functionality Heiko Stübner
2013-07-29 13:11 ` [PATCH v4 1/6] misc: sram: fix error path in sram_probe Heiko Stübner
2013-07-29 13:12 ` [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved Heiko Stübner
2013-07-29 14:02   ` Philipp Zabel
2013-07-29 21:39     ` Matt Sealey
2013-08-01 16:35       ` Heiko Stübner [this message]
2013-08-01 17:07         ` Matt Sealey
2013-07-29 13:13 ` [PATCH v4 3/6] ARM: rockchip: add snoop-control-unit Heiko Stübner
2013-07-29 13:13 ` [PATCH v4 4/6] ARM: rockchip: add sram dt nodes and documentation Heiko Stübner
2013-07-29 13:14 ` [PATCH v4 5/6] ARM: rockchip: add power-management-unit dt node Heiko Stübner
2013-07-29 13:15 ` [PATCH v4 6/6] ARM: rockchip: add smp bringup code 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=201308011835.22186.heiko@sntech.de \
    --to=heiko@sntech.de \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=neko@bakuhatsu.net \
    --cc=olof@lixom.net \
    --cc=p.zabel@pengutronix.de \
    --cc=ulrich.prinz@googlemail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).