From: ezequiel.garcia@free-electrons.com (Ezequiel Garcia)
To: linux-arm-kernel@lists.infradead.org
Subject: mvebu: mbus device tree binding
Date: Mon, 20 May 2013 09:31:54 -0300 [thread overview]
Message-ID: <20130520123153.GA2904@localhost> (raw)
Hello Arnd and Jason,
Let's advance with the DT binding for mvebu-mbus,
and perhaps have it ready for v3.11.
Our current approach to the mbus-windows allocation is as follows:
1. Every device is located as a child of the soc/internal-regs node.
The DT contains information for the assigned address space,
encoded in the 'ranges' property, like this:
soc {
ranges = < internal-regs
PCIe
NOR
... >;
internal-regs {
...
};
}
2. Each driver is in charge of allocating the mbus windows, using
the mbus API and the address region obtained through the information
on the device tree.
Now, this approach is particularly error-prone because of (1). The
'ranges' entry in a given .dtsi file is overrided by the 'ranges'
in the per-board .dts file. So, when if we need to declare a node for a
NOR device, we need to duplicate all ranges entries from the parent
.dtsi files.
This does not seem to be hugely problematic, for one could put the
'ranges' property only in the per-board files, and remove it from the
common dtsi.
Therefore, first of all I'd like to know:
**1** What's so broken with the current approach that makes us seek for
solution, in the form of an mbus DT binding?
In addition, reading the previous discussion you've had about this, I
noticed Arnd suggested (and even required) that the mbus binding should
update the ranges property in the DT blob each time an address window
is dynamically allocated.
**2** Why is this required? Who will read the updated ranges
information?
Why can't the kernel access the mbus API to obtain information
about currently allocated windows?
Those are my questions for now and I'm quite sure many more will come
in the future, so please bare with me!
Thanks a lot,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next reply other threads:[~2013-05-20 12:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 12:31 Ezequiel Garcia [this message]
2013-05-20 12:44 ` mvebu: mbus device tree binding Ezequiel Garcia
2013-05-20 16:25 ` Greg
2013-05-21 9:35 ` Thomas Petazzoni
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=20130520123153.GA2904@localhost \
--to=ezequiel.garcia@free-electrons.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 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.