From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 00/12] MBus DT binding: A new hope
Date: Tue, 2 Jul 2013 13:55:24 -0600 [thread overview]
Message-ID: <20130702195524.GA14547@obsidianresearch.com> (raw)
In-Reply-To: <1372532655-20321-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Sat, Jun 29, 2013 at 04:04:03PM -0300, Ezequiel Garcia wrote:
> In the current proposal we have now required a 'controller' property
> to specify the MBus controller MMIO registers. To us this looks more
> appropriate, since the MBus registers are effectively located within
> the internal register region, behind the so-called internal-regs window.
Interesting, seems reasonable to me.
> Personally, I can't see any disadvantage, and the binding looks much
> cleaner now. But of course I can be wrong, and I'm open to discussion.
>
> There's another pending issue. Arnd Bergmann has required to add a
> property to specify the available space within the CPU address space
> for decoding windows. This property would allow to support fully
> dynamic mbus window allocation.
I wonder if this range is implied - eg it is address space not covered
by the memory node or any mbus ranges? Is there a situation where that
is not sufficient?
> For now, this property is intentionally missing, and I expect that
> it can be added in the future, together with the full-dynamic MBus
> implementation.
>
> @Arnd, @Jason: Given the v4 patchset didn't receive any comments but
> wasn't accepted either, I'd like to know which other pending issues
> I'm forgetting to address.
I took a quick look and it seems to match what was discussed..
Regards,
Jason
next prev parent reply other threads:[~2013-07-02 19:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-29 19:04 [PATCH v5 00/12] MBus DT binding: A new hope Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 01/12] bus: mvebu-mbus: Factor out initialization details Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 02/12] bus: mvebu-mbus: Introduce device tree binding Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 04/12] ARM: mvebu: Initialize MBus using " Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 05/12] ARM: mvebu: Remove the harcoded BootROM window allocation Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 06/12] memory: mvebu-devbus: Remove address decoding window workaround Ezequiel Garcia
2013-06-29 20:11 ` Greg Kroah-Hartman
2013-06-29 19:04 ` [PATCH v5 07/12] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 08/12] ARM: mvebu: Add MBus to Armada 370/XP device tree Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 09/12] ARM: mvebu: Add BootROM " Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 10/12] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 11/12] ARM: mvebu: Relocate Armada 370 PCIe " Ezequiel Garcia
2013-06-29 19:04 ` [PATCH v5 12/12] ARM: mvebu: Relocate Armada XP " Ezequiel Garcia
2013-07-02 19:55 ` Jason Gunthorpe [this message]
2013-07-03 12:04 ` [PATCH v5 00/12] MBus DT binding: A new hope Arnd Bergmann
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=20130702195524.GA14547@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--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 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).