Hi Russell,
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
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.
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.
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.
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
On Thu, May 12, 2011 at 9:47 AM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
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.
Hi Grant,
On Wed, 11 May 2011 22:44:49 +0200 Grant Likely grant.likely@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.
-
Grant Likely -
Nicolas Pitre -
Russell King - ARM Linux -
Stephen Rothwell