[GIT PULL] omap changes for v2.6.39 merge window

[Will Deacon]

Hi Arnd,

On Fri, 2011-04-01 at 14:54 +0100, Arnd Bergmann wrote:
> I would actually suggest a different much more radical start: Fork the way
> that platforms are managed today, and start an alternative way of setting
> up boards and devices together with the proven ARM core kernel infrastructure,
> based on these observations (please correct me if some of them they don't make
> sense):
> 
> 1. The core arch code is not a problem (Russell does a great job here)
> 2. The platform specific code contains a lot of crap that doesn't belong there
>    (not enough reviewers to push back on crap)
> 3. The amount of crap in platform specfic files is growing exponentially,
>    despite the best efforts of a handful of people to clean it up.
> 4. Having one source file per board does not scale any more.
> 5. Discoverable hardware would solve this, but is not going to happen
>    in practice.
> 6. Board firmware would not solve this and is usually not present.
> 7. Boot loaders can not be trusted to pass valid information
> 8. Device tree blobs can solve a lot of the problems, and nobody has
>    come up with a better solution.

Right, so this is directly related to point (5) because in essence FDT
is a way to make undiscoverable hardware discoverable by probing the
tree. The `it's just data' mantra sums it up nicely.

> 9. All interesting work is going into a handful of platforms, all of which
>    are ARMv7 based.

I think starting out ARMv7-only might make this more manageable but
there are still shed loads of pre-v7 chips out there which we should try
not to break.

> 10. We do not want to discontinue support for old boards that work fine.

[...]

> Based on these assumptions, my preferred strategy would be to a new
> mach-nocrap directory with a documented set of rules (to be adapted when
> necessary):

This is a nice idea, but I don't think it's entirely practical:

> * Strictly no crap
>  * No board files

I don't understand how you can handle `early quirks' without board
files. Does this follow on from Linus' suggestion about moving code out
of the kernel and into the bootloader?

Realistically, I don't think you will ever get away from board files.
The trick is probably to make them as small as possible and common to as
many boards as possible (like the platforms directory for PowerPC).

>  * No hardcoded memory maps
>  * No lists of interrupts and GPIOs

This is largely just data, so should be do-able once this stuff isn't
needed at compile-time (which is becoming the case with stuff like
dynamic p2v).

Will