[PATCH v6 0/5] Basic ARM devicetree support
Grant Likely
Here's the current state of the device tree patches for basic
infrastructure support. It's pretty much the same as the last series
I sent to you, except I've dropped the patches that add .dts files and
board support simply because the final location for storing .dtb files
is still up in the air.
After hearing from multiple people this week at UDS, and specifically
having a long conversation about it with tglx, I'd really think it's
time to start getting some wider testing in linux-next since it has
seemed to be quite stable for a while now. In fact, I want to put it
in right now so that there is the /option/ of getting it into 2.6.40
with a separate pull request near the end of the merge window (I'm not
asking you to commit to merging it, but it isn't even an option if it
isn't in linux-next).
Right now it merges cleanly with linux-next and the resulting tree
builds and boots at least on qemu. Unless you really object, I'm
going to ask Stephen to add the following branch to the /end/ of the
list of trees for linux-next so it can easily be dropped it if it
causes any problems.
git://git.secretlab.ca/git/linux-2.6 devicetree/arm-next
g.
---
Grant Likely (5):
arm/dt: Make __vet_atags also accept a dtb image
arm/dt: Allow CONFIG_OF on ARM
arm/dt: consolidate atags setup into setup_machine_atags
arm/dt: probe for platforms via the device tree
dt: add documentation of ARM dt boot interface
Documentation/arm/Booting | 33 +++++
Documentation/devicetree/booting-without-of.txt | 48 +++++++-
arch/arm/Kconfig | 7 +
arch/arm/include/asm/mach/arch.h | 9 +
arch/arm/include/asm/prom.h | 37 ++++++
arch/arm/include/asm/setup.h | 4 +
arch/arm/kernel/Makefile | 1-
arch/arm/kernel/devtree.c | 145 +++++++++++++++++++++++
arch/arm/kernel/head-common.S | 24 +++-
arch/arm/kernel/head.S | 8 +
arch/arm/kernel/setup.c | 90 +++++++++-----
arch/arm/mm/init.c | 11 ++
12 files changed, 367 insertions(+), 50 deletions(-)
create mode 100644 arch/arm/include/asm/prom.h
create mode 100644 arch/arm/kernel/devtree.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King - ARM Linux
> Right now it merges cleanly with linux-next and the resulting tree
> builds and boots at least on qemu. Unless you really object, I'm
> going to ask Stephen to add the following branch to the /end/ of the
> list of trees for linux-next so it can easily be dropped it if it
> causes any problems.
As far as the set of five patches looks fine to me, I don't have any
objections against them. So I think we can merge them for .40.
What I've always worried about is the platform stuff, and that's
something I'm going to continue worrying about because I don't think
we have sufficient review capacity to ensure that we don't end up
with lots of stupidities.
Eg, we need to properly sort out how we're going to represent stuff
so we don't end up with X IRQ controllers, Y clock events, etc. In
other words, I don't want to see DT growing an AT91 IRQ controller,
PXA IRQ controller, SA1100 IRQ controller, etc.
One of the things we must deal with is how do we reduce the amount
of IRQ controller code, clock event code, etc that we have in the
kernel tree. That means coming up with some generic representation
of these facilities and having the right DT properties in place to
be able to describe to the generic representation what's required of
it.
If we can't do that, then DT isn't solving the problem which Linus
has complained about, and we will still be in the situation where
platform X wants its own IRQ controller, clock event, etc code.
Stephen Rothwell
On Wed, 11 May 2011 22:44:49 +0200 Grant Likely <grant....@secretlab.ca> wrote:
>
> Right now it merges cleanly with linux-next and the resulting tree
> builds and boots at least on qemu. Unless you really object, I'm
> going to ask Stephen to add the following branch to the /end/ of the
> list of trees for linux-next so it can easily be dropped it if it
> causes any problems.
>
> git://git.secretlab.ca/git/linux-2.6 devicetree/arm-next
OK, given Russell's qualified agreement, I will add this tree today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
s...@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
Nicolas Pitre
> On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote:
> > Right now it merges cleanly with linux-next and the resulting tree
> > builds and boots at least on qemu. Unless you really object, I'm
> > going to ask Stephen to add the following branch to the /end/ of the
> > list of trees for linux-next so it can easily be dropped it if it
> > causes any problems.
>
> As far as the set of five patches looks fine to me, I don't have any
> objections against them. So I think we can merge them for .40.
>
> What I've always worried about is the platform stuff, and that's
> something I'm going to continue worrying about because I don't think
> we have sufficient review capacity to ensure that we don't end up
> with lots of stupidities.
DT is certainly not a silver bullet. Good judgement will be needed as
to what is put in DT and how it is represented. I don't think that it
would make things worse than they are now though.
I also do have some concerns about some aspects of DT which I've
expressed several times in the past. However I don't think holding back
those patches any longer is a solution though.
So consider this as a ACK from my part to merge those patches now. This
will get the ball rolling.
Nicolas
Grant Likely
> On Wed, 11 May 2011, Russell King - ARM Linux wrote:
>
>> On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote:
>> > Right now it merges cleanly with linux-next and the resulting tree
>> > builds and boots at least on qemu. Unless you really object, I'm
>> > going to ask Stephen to add the following branch to the /end/ of the
>> > list of trees for linux-next so it can easily be dropped it if it
>> > causes any problems.
>>
>> As far as the set of five patches looks fine to me, I don't have any
>> objections against them. So I think we can merge them for .40.
Yay! Thanks Russell!
>> What I've always worried about is the platform stuff, and that's
>> something I'm going to continue worrying about because I don't think
>> we have sufficient review capacity to ensure that we don't end up
>> with lots of stupidities.
Understood, and I agree to a point, but I'm cautiously optimistic that
the review process we talked about heavily this week will be able to
push back on bad bindings to prevent a lot of these problems. It also
helps that we we can cut over to device tree in board ports in stages
without needing a change-everything-flag-day. Devices can be
converted one by one, which will limit the volume of stuff that needs
to be reviewed at one time.
> DT is certainly not a silver bullet. Good judgement will be needed as
> to what is put in DT and how it is represented. I don't think that it
> would make things worse than they are now though.
+1
> I also do have some concerns about some aspects of DT which I've
> expressed several times in the past. However I don't think holding back
> those patches any longer is a solution though.
>
> So consider this as a ACK from my part to merge those patches now. This
> will get the ball rolling.
Thanks Nicolas.
g.