From: benh@kernel.crashing.org (Benjamin Herrenschmidt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] Revert support for reserved memory regions defined in device tree
Date: Wed, 20 Nov 2013 09:01:44 +1100 [thread overview]
Message-ID: <1384898504.26969.48.camel@pasglop> (raw)
In-Reply-To: <20131119151418.8BB2BC4079D@trevor.secretlab.ca>
On Tue, 2013-11-19 at 15:14 +0000, Grant Likely wrote:
> > The proposal look good for me. I'm not convinced that we really need the
> > support for 'reg' property, as the fixed memory region is a special case
> > of generic dynamic allocation specified by the size and alloc-ranges, but
> > I assume that there have been already a long discussion about this, so I
> > accept the common consensus.
>
> It is absolutely necessary for some use cases. For example, a
> framebuffer enabled by firmware and passed onto the kernel for
> flicker-free boot. Some platforms have fixed regions that cannot be
> moved up.
Arguably that could be covered with alloc-range and size by making the range be
the reg property content basically (and thus size == size of range) but I
prefer the reg property, it's a clearer statement of intent.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Laura Abbott <lauraa@codeaurora.org>,
Pawel Moll <pawel.moll@arm.com>, Arnd Bergmann <arnd@arndb.de>,
Stephen Warren <swarren@wwwdotorg.org>,
Tomasz Figa <t.figa@samsung.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Michal Nazarewicz <mina86@mina86.com>,
linaro-mm-sig@lists.linaro.org, Marc <marc.ceeeee@gmail.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Kumar Gala <galak@codeaurora.org>,
Olof Johansson <olof@lixom.net>,
Ian Campbell <ian.campbell@citrix.com>,
Nishanth Peethambaran <nishanth.p@gmail.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 0/2] Revert support for reserved memory regions defined in device tree
Date: Wed, 20 Nov 2013 09:01:44 +1100 [thread overview]
Message-ID: <1384898504.26969.48.camel@pasglop> (raw)
In-Reply-To: <20131119151418.8BB2BC4079D@trevor.secretlab.ca>
On Tue, 2013-11-19 at 15:14 +0000, Grant Likely wrote:
> > The proposal look good for me. I'm not convinced that we really need the
> > support for 'reg' property, as the fixed memory region is a special case
> > of generic dynamic allocation specified by the size and alloc-ranges, but
> > I assume that there have been already a long discussion about this, so I
> > accept the common consensus.
>
> It is absolutely necessary for some use cases. For example, a
> framebuffer enabled by firmware and passed onto the kernel for
> flicker-free boot. Some platforms have fixed regions that cannot be
> moved up.
Arguably that could be covered with alloc-range and size by making the range be
the reg property content basically (and thus size == size of range) but I
prefer the reg property, it's a clearer statement of intent.
Cheers,
Ben.
next prev parent reply other threads:[~2013-11-19 22:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 7:27 [PATCH 0/2] Revert support for reserved memory regions defined in device tree Marek Szyprowski
2013-10-11 7:27 ` Marek Szyprowski
[not found] ` < 20131030134702.19B57C402A0@trevor.secretlab.ca>
2013-10-11 7:27 ` [PATCH 1/2] Revert "ARM: init: add support for reserved memory defined by device tree" Marek Szyprowski
2013-10-11 7:27 ` Marek Szyprowski
2013-10-11 7:27 ` [PATCH 2/2] Revert "drivers: of: add initialization code for dma reserved memory" Marek Szyprowski
2013-10-11 7:27 ` Marek Szyprowski
2013-10-11 7:48 ` [PATCH 0/2] Revert support for reserved memory regions defined in device tree Benjamin Herrenschmidt
2013-10-11 7:48 ` Benjamin Herrenschmidt
2013-10-11 18:12 ` Kumar Gala
2013-10-11 18:12 ` Kumar Gala
2013-10-15 11:41 ` Grant Likely
2013-10-15 11:41 ` Grant Likely
2013-10-17 18:37 ` Matt Sealey
2013-10-17 18:37 ` Matt Sealey
2013-10-17 19:35 ` Benjamin Herrenschmidt
2013-10-17 19:35 ` Benjamin Herrenschmidt
2013-10-15 11:40 ` Grant Likely
2013-10-15 11:40 ` Grant Likely
2013-10-15 13:27 ` Marek Szyprowski
2013-10-15 13:27 ` Marek Szyprowski
2013-10-30 13:47 ` Grant Likely
2013-10-30 13:47 ` Grant Likely
2013-10-30 17:30 ` Matt Sealey
2013-10-30 17:30 ` Matt Sealey
2013-11-19 12:27 ` Marek Szyprowski
2013-11-19 12:27 ` Marek Szyprowski
2013-11-19 15:14 ` Grant Likely
2013-11-19 15:14 ` Grant Likely
2013-11-19 22:01 ` Benjamin Herrenschmidt [this message]
2013-11-19 22:01 ` Benjamin Herrenschmidt
2013-11-20 13:04 ` Grant Likely
2013-11-20 13:04 ` Grant Likely
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=1384898504.26969.48.camel@pasglop \
--to=benh@kernel.crashing.org \
--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.