[Linux-c6x-dev] Rough review of the c6x kernel tree in git
Arnd Bergmann
arnd at arndb.de
Fri Sep 24 11:29:56 UTC 2010
On Friday 24 September 2010, William Mills wrote:
> > * It would be good to support the flattened device tree as a way
> > to pass information about the hardware to the kernel, as the
> > microblaze architecture does.
>
> I am personally very interested in the flattened device tree support. I
> would like to see this supported. It would be a good way to eliminate
> many of the #ifdefs you talk about below. However, it is not currently
> an assigned work item.
>
> Do you think this is critical to getting into the mainline or is this
> something we could add later?
I don't think it's critical, but I would expect that refactoring the
code after it is in mainline causes more work than doing it first.
Once the code is merged, there is much more desire to stay backwards
compatible with existing boot code, so if you require a device tree
to be present in the initial version that gets merged upstream, upgrades
are much easier.
However, I would not recommend moving to a device tree based configuration
before rebasing to the 2.6.36 kernel, because a lof of the architecture
independent infrastructure is just now getting merged, while older kernels
had to do a lot of things in the arch code.
It should be a lot easier in the future and help clean up your code.
> > * move the device drivers into driver directories, out of arch/,
> > submit them separately through subsystem maintainers
>
> Yes, this will happen over time except for the ones that couple tightly
> to the core like interrupt controller, power managment, clock tree, etc.
Ok.
> I also intend to collapse the code structure of the cio stuff down to
> one file and fix the style etc. It is a carry over from the structure
> in the TI C runtime library but we should treat this as just a fork.
Yes. In general it is not possible to maintain a single code version
in the kernel and some other project, unless you consider the kernel
version to be the master.
Arnd
More information about the Linux-c6x-dev
mailing list