From: "jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Andy Green <andy-/Zus8d0mwwtBDgjK7y7TUQ@public.gmane.org>,
Nicolas Pitre
<nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Linaro Dev <linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
Eric Miao <eric.miao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: Re: Linus being annoyed by the ARM kernel code
Date: Mon, 4 Apr 2011 07:29:53 -0400 [thread overview]
Message-ID: <BANLkTiku0xqBrpPdHe6hn4B94aRPq6-a5A@mail.gmail.com> (raw)
In-Reply-To: <4D99875C.8060004-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Apr 4, 2011 at 4:54 AM, Andy Green <andy-/Zus8d0mwwtBDgjK7y7TUQ@public.gmane.org> wrote:
> Another way to solve it, would be to encode the set of device trees
> supported in a way that removes redundancy. Then the additional data needed
> to resolve a generic OMAP3 device table into overo or beagle or any similar
> board would be a small increment. The encoded table can be initdata and
> gotten rid of after being rendered into the DT required.
Grant, this is an interesting idea...
Suppose Linux develops a standardized DT format for describing things
like clock and power domains. This domain data is then acted on by
generic code in the kernel. The domain data is CPU specific, not
board specific.
It would make sense to me to not put this data into the board specific
device trees. Board specific device trees include the CPU identifier.
During the Linux boot process we could look at the CPU identifier and
then expand the in-memory DT with CPU specific info like the clock and
power domains.
Since each CPU variant would expand into the corresponding nodes we
can now write generic code that acts on this data in a manner that is
not bound to the specific CPU. Keeping data like this out of the board
specific DT makes them easier to write. There's nothing to be gained
by adding dozens of CPU specific nodes to a board level device tree.
--
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
parent reply other threads:[~2011-04-04 11:29 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <4D99875C.8060004-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
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=BANLkTiku0xqBrpPdHe6hn4B94aRPq6-a5A@mail.gmail.com \
--to=jonsmirl-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=andy-/Zus8d0mwwtBDgjK7y7TUQ@public.gmane.org \
--cc=andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=eric.miao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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).