lkml.org 
[lkml]   [2011]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [GIT PULL] omap changes for v2.6.39 merge window
    Date
    On Monday 04 April 2011, Benjamin Herrenschmidt wrote:
    > On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
    > > > * No board files
    > > Where do you put code that needs to run very early (e.g. pinging the
    > > watchdog)?
    >
    > Even on powerpc I keep board files :-)
    >
    > The main thing is:
    >
    > - The generic -> board linkage must not be hard (ie, no
    > platform_restart, but a board_ops.restart() etc....)
    >
    > - An average board file is a few hundreds line long, that's it, mostly
    > it hooks up to generically provided functions, tho it gets the choice of
    > _which_ ones to hookup.

    I believe a machine_type is more general than a board file, i.e. what
    gets described as a machine in powerpc would often currently correspond
    to multiple board files, if I am not mistaken.

    The fact that we have a more diverse set of hardware on ARM, and that
    it's growing quicker than powerpc also means that we should try harder
    to reduce duplication than is necessary there.

    > - It can still quirk/fixup a thing or two if needed, I thinkt it's
    > useful to keep that around, as long as such "quirks" remain small and
    > few. At the end of the day, if dealing with one board special case gives
    > you the choice between changing a ton of infrastructure/core to
    > introduce a new abstraction to deal with -that- special case vs. having
    > a one liner fixup in the platform code, the later is the most sensible
    > option. The hard part of course is to have sensible maintainers to make
    > sure this doesn't grow back to the old mess.

    I guess quirks are fine, as long as it's not required to have a them
    for each board. We can have a function that gets called for any matching
    "compatible" property of the root node, but I think the default should
    be not to need it eventually.

    This is one area where I think I can illustrate how a gradual change
    from the status quo differs from a parallel new platform implementation:
    To gradually change one board file, you would convert the existing
    machine description to match the compatible property of the device
    tree root node and possibly at a later stage remove that code again
    once it's possible to work without it.
    When starting out with a fresh implementation, we first need to
    change all device drivers that are used on the board to work
    without a machine description, but then would not have to change
    any code twice, and the work for a similar board is almost done.

    Arnd


    \
     
     \ /
      Last update: 2011-04-04 02:17    [W:0.023 / U:0.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site