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

[Barry Song <21cnbao@gmail.com>]

2011/4/1 Arnd Bergmann <arnd@arndb.de>:
> On Friday 01 April 2011, Ingo Molnar wrote:
>> IMO the right answer is what Linus and Thomas outlined:
>>
>>    1) provide a small number of clean examples and clean abstractions
>>    2) to not pull new crap from that point on
>>    3) do this gradually but consistently
>>
>> I.e. make all your requirements technical and actionable - avoid sweeping,
>> impossible to meet requirements. Do not require people to clean up all of the
>> existing mess straight away (they cannot realistically do it), do not summarily
>> block the flow of patches, but be firm about drawing a line in the sand and be
>> firm about not introducing new mess in a gradually growing list of well-chosen
>> areas of focus.
>>
>> Rinse, repeat.
>
> I believe getting to point 1 is the hard part here. There are a lot of things
> that are wrong with the mach-* (and also plat-*) implementations, and I don't
> think we have one today that can really serve as an example. Most decisions
> made in there made a lot of sense when they were introduced, and declaring
> code that was perfectly acceptable yesterday to be unacceptable crap today
> is not going to be met with much understanding by the someone who just
> wants to add support for one more board to 100 already existing ones in the
> same SoC family.
>
> 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.

ARM BSP is still blasting! we are planning to merge our new ARM
cortex-a9 SoC into kernel. So I am just wondering whether traditional
ARM BSP way can still be accepted, or we must move to use device tree?
but i have't seen any arm device tree codes enter mainline yet. but we
can get those patches from linaro 2.6.38. So what's the plan for
merging arm device tree?

What i have seen is that the BSP architecture of different ARM SoC
companies is even different.

samsung has three levels:
plat-samsung
            plat-s3c24xx
                     mach-s3c2410
                     mach-s3c2440
            plat-s5p
                     mach-s5pv210
                     mach-s5pv310

TI has two levels:
plat-omap
            mach-omap1
            mach-omap2

Nvidia has one level:
mach-tegra

I didn't find any rule about what codes should be placed in what
directories. Different companies have different ways. It looks like
the only agreement is board files are in mach-xxx. Any suggestions for
that?

BTW, we don't want to "dick around", which Linus has been very angry.
we want to fix more issues this email pointed out before we send
patches.

> 9. All interesting work is going into a handful of platforms, all of which
>   are ARMv7 based.
> 10. We do not want to discontinue support for old boards that work fine.
> 11. Massive changes to existing platforms would cause massive breakage.
> 12. Supporting many different boards with a single kernel binary is a
>    useful goal.
> 13. Infrastructure code should be cross-platform, not duplicated across
>    platforms.
> 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is
>    actually adding PAE support, which has failed to solve this on
>    other architectures).
> 15. We need to solve the platform problem before 64 bit support comes
>    and adds another dimension to the complexity.
>
> 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):
>
> * Strictly no crap
>  * No board files
>  * No hardcoded memory maps
>  * No lists of interrupts and GPIOs
> * All infrastructure added must be portable to all ARMv7 based SoCs.
>  (ARMv6 can be added later)
> * 64 bit safe code only.
> * SMP safe code only.
> * All board specific information must come from a device tree and
>  be run-time detected.
> * Must use the same device drivers as existing platforms
> * Should share platform drivers (interrupt controller, gpio, timer, ...)
>  with existing platforms where appropriate.
> * Code quality takes priority over stability in mach-nocrap, but must not
>  break other platforms.
>
> Until we have something working there, I think we should still generally
> allow new code to the existing platforms, and even new platforms to be
> added, while trying to keep the quality as high as possible but without
> changing the rules for them or doing any major treewide reworks.
>
> Once the mach-nocrap approach has turned into something usable, we can
> proceed on three fronts:
> 1. delete actively maintained boards from the other platforms once they
>   are no longer needed there
> 2. generalize concepts from mach-nocrap by applying them to all boards,
>   similar to the cleanup work that people have always been doing.
> 3. gradually make the rules for adding new code in other platforms stricter,
>   up to the point where they are bugfix only.
>
>> If companies do not 'bother to push upstream', then management will eventually
>> notice negative economic consequences:
>>
>> ...
>
> Good points, I fully agree with these. I also think that the SoC companies
> are actually understanding this nowadays, and that is exactly the reason
> why we see so much code getting pushed in.
>
>        Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel