ARM Maintainers Summit

Agenda & Minutes (in no particular order)
 * pinctrl (linusw)
   * feature complete upstream
   * current discontent is around what does or does not go into device tree
     * tegra driver is a little scary, 6k lines of code
     * Might merge, but do we want to put the soc specific parts into pinmux or not
       * size is the main issue.
     * Potential risk of damaging hardware if wrong volatages are set on the pins, so device tree has real risks
     * Also splitting the data between device tree and driver makes it harder to understand?
   * Couple of diffferent device tree binding proposals
     * What a pin group should be?
     * one proposal: binding of all registers to initialize hardware at boot/runtime
       * sort of an initialization script / interp language
         * acpi / openfirmware already do this sort of thing, should avoid duplicating
       * loses the data representation
         * Hurts understandability of code
         * Only vendors can maintain
       * This proposal is no state, to avoid really an interp language
         * concern is that it would eventually grow into ugly language
       * Readability of static structure in the kernel is nice
       * Need for interaction between firmware and OS is reduced on these sorts of devices (non-server)
         * longview: device tree & acpi not all that different, may be able to merge way way out
       * Is it possible some of the data is really debugging data that could be provided by userspace? Could be used to reduce size of static structures in kernel

 * common clock
   * major issue: taking a long time
     * implementation detail disagreements, think most of it is resolved w/ latest version
     * May need to address some long standing deficiencies in the clk api
       * May be out of scope for the work, getting common clk tree in is high priroity
       * re-validating any major change for someting like dvfs would be a big pain
       * Concerned about the clk data each platform defines having to be reworked if the api changes
   * Would be good to get it into linux-next just so folks can get a feel for it
     * assure folks it won't break the world
     * Want 1-2 platforms included in the series
   * omap4 & freescale partially converted
     * msm wants to work with it
     * Would be good to get versatile/hibank/etc on latest series
   * Want to make clk struct opaque
     * Important for dvfs, as might be unsafe for drivers to access something like freq, as it might change under them
   * msm has additional restrictions/features & might need to take locking into account now, rather then later.
     * ACTION: Discuss this detail later this week, do a review of locking
       * Attendees: David Brown, Peter De Schrijver, ideally Saravana Kannan (might need voice call)
     * Current struct clk locking is likely racy

 * common clock bindings (glikely)
   * describes connections
   * If clk data changes per board, probably should be in device tree, but if static, leave it in the driver (or other in-tree static data)
   * Questions on how device clks are modelled & named
     * ACTION: Grant to take a meeting later today or tomorrow to discuss
       * Attendees: David Brown, Peter De Schrijver,
   * grant has code that will work for Versatile & hibank
   * Add info to clk providers that provides parenting info, but up to binding
   * For bindings, naming is optional.
     * drivers can require it, but for the binding layer, it doesn't care.
   * swarren asked whether a common binding was appropriate to set up clock parenting relationships within a SoC's clock complex driver. Grant indicated this was down to individual binding of the clock provider. If the binding ends up being useful for multiple providers, they can adopt the same binding for consistency, but aren't required to if it doesn't work for them.

 * arm-soc tree status (arndb)
   * Much going well, esp the workload split
   * This merge window we did not get everything upstream that was in linux-next
     * Lack of coordination with RMK
     * Big set of patches from Nico for single zImage that conflicts with other areas
        3.4 queue is behind
                Need to advertise email alias better
                    Need to add to maintainers file
        Need to make sure sh-mobile stuff goes through the arm-soc tree instead of sh tree
            DMA memory/ Reset handlers need to be more consistent then coding style
        Subarch maintainer feedback:
            Having something like for-next branches would be good, but also pinging Arnd may be needed
                Need to handle collisions and get code in soc tree sooner
            Would be nice to have "merge-base" tagging
                Hard to define common merge base, may limit ability to rebase
                Instead of using a special tag, just use the most appropriate base when sending patches
            Need a name convention to differentiate between stable branches or more experiemental bits
            More skepticism needed when pulling trees (had some non stable stuff go in after being told it was stable)
            Need better communication/process on deadlines for -rc window fixes for linus
                Due to occasional need for very urgent stuff, maybe not good a idea to have a fixed schedule.
                Friday is not preferred for sending patches.
        arm-soc tree isn't always best place to push changes through
            subsystem changes like pinmux should go through their maintainers

 * single zImage
   * Progressing slowly
   * mach/macros.S, mach/system.h under work
     * remaining items: mach/io.h mach/timex.h
     * removal CLOCK_TICK_RATE issue is contentiouos
     * ACTION: Deepak to follow up on patches
        Next step:
            Change main makefile & compile two or more SoCs together
                Already done via picoxl & highbank? which both support device tree
            #ifdef stuff will be nasty to sort out
        May take yet another year to get this done
            Fairly boring cleanup, hard to get folks involved
        Focus on: Armv6 & above or v5 and above
        Getting the build working first is important
            Randconfig patches will help find problems w/ build testing
        clk api needs to be solved
            possible for some non common struct clk consolidation, not sure if it would be a distraction
        Not much interest in getting multiple v5 together
            Once v6/v7 is done, then if interest, the hardwork will be done already
            Not likely in practice for distros to want v4/v5
                although debian has that as the majority of users
        Another item to look at: weak symbols
            not hard to grep for, but needs to be addressed
            find list of weak symbols, then look for those in arch/arm
            might not be major, as linker doesn't link weak symbols on arm properly?
        initcall functions that don't check what platform they're running on?

 * separating out legacy platforms
   * No hard rules, use review comments and maintainer social skills.
   * ACTION: Deepak and Arnd to create a Documentation/arm/new-platforms.txt to encode the rules surrounding DT and other new platform constraints

 * Platform upstreaming
   * missing subsystems: rpmsg, hsi, system controllers, irqchip
   * ACTION: LinusW to ask Greg about where to put system controllers, drivers/misc, drivers/scm (reads out "system controller modules") or what? Rationale: try to get rid of cruft in drivers/mfd or arch/arm/* or elsewhere
   * ACTION: Rob to create drivers/irqchip and start moving IRQ drivers there

 * Device Tree migration
   * rule of thumb: no more board files that use atag based probing, use device tree boot protocol even while still using board files (ideally no more board files, but not there yet)
   * compatibility: while we're slowly migrating to full device tree based probing, we will break booting new kernels with old device trees. Ideally we never break new kernels wiht old dt files once the conversion is complete, but we should *always* provide an option to override the dt when installing a new kernel
   * Grant comments: tell fw developers that the dt will always change with a new kernel, but tell kernel developers that old dt files always need to keep working

 * irq_domain migration
   * patches in linux-next
   * gets rid of hardcoding global IRQ numbers per platform
   * /proc/interrupts can contain dynamically assigned numbers
   * suggestion: use sparse irq globally on ARM, not currently necessary

 * Deferred probe
   * Grant has a patch, thinks it's ready
   * needs testing
   * seems to be uncontroversial
   * ACTION: Grant to (re)send patch for 3.4 integration
   * ACTION: Tony to provide a patch using it