[lkml]   [2011]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] omap changes for v2.6.39 merge window
    2011/4/1 Arnd Bergmann <>:
    > 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:

    TI has two levels:

    Nvidia has one level:

    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

    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

    > 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
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-04-06 08:13    [W:0.050 / U:0.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site