Linaro Developers Summit: More ARM Linux Consolidation

We had a principled discussion today. In particular, we arrived at several principles:
 
 
 
 

1. The only ARM-specific code is (a) ARM core architecture and (b) ARM SoC core architecture.
2. What would otherwise be ARM board-specific code should be handled by (a) device tree and (b) device drivers in /drivers/*.
3. Functionality should be grouped by purpose rather than by implementation, which will help bring out common patterns and opportunities for further consolidation.
4. The more SoCs there are, the greater the motivation and practicality of pulling out common code. The number of SoCs is expected to continue to increase over time.

The “ARM SoC core architecture” should consist primarily of plugins for common frameworks. These frameworks should preferably be Linux-kernel-wide rather than being confined to the ARM tree. It is quite possible that the ARM SoC core architecture will turn out to be nonexistent. This would be a good thing: the more we consolidate code into common frameworks, the better able we will be to productively develop and maintain Linux on ARM.

We also continued our earlier discussion on opportunities for consolidation and people who are best positioned to take on this work:

1. GPIO (Grant Likely, Linus Walleij).
2. Pinmux (Linus Walleij).
3. MM and IOMMU (move the drivers to common place: individual sub-arch maintainers, Joerg Roedel might need some help for embedded).
4. CPU freq drivers (move the drivers to common place: individual sub-arch maintainers).
5. CPU idle drivers (move the drivers to common place: individual sub-arch maintainers).
6. Demultiplexed interrupts (Thomas Gleixner).
7. Cascaded interrupt controllers (especially the 256-interrupt parts where you use 1 interrupt).
8. Convert timer init to “earlytimer” like SH (Magnus Damm).
9. API to use multiple HW timers (for example, OMAP has 32 in some cases). Do we gain anything by just having them in the kernel? Have yet to see a real good use for this where existing timer interfaces in kernel don’t work. In some cases, the Linux kernel is reserving a HW timer to be used by a DSP OS. Need to understand the uses cases to create proper API to manage these. (Thomas Gleixner and Kevin Hilman to look at use cases and derive appropriate solution.)
10. PWM drivers (move the drivers to common place: individual sub-arch maintainers).
11. Industrial I/O drivers (now in staging, should stay out of arch/arm: Kyungmin Park & Jonathan Cameron).
12. drivers/mfd: (multi-function devices) getting overused—”just a bag of platform devices”. This is OK for the device driver itself, but the subdrivers should go into the appropriate GPIO location. Again, align with hardware—IP block separate from how it is connected. (Samuel Ortiz is the maintainer, so we clearly need to work this out with with him).
13. pruss DSP: patches being proposed, Arnd has been reviewing. These patches are being generated by new-to-Linux developers.
14. General infrastructure to handle instantiation of new devices at runtime as well as at boot: DSPs, FPGAs (Mark Brown).
15. Near-Field Communication drivers: Nokia has driver upstream, discussion about long-term interface, leaning towards sockets-based interface.
16. Maintainer for drivers/misc and drivers/char: Arnd Bergmann. Goal: force drivers to move into appropriate place, rather than dumping random functionality into drivers/misc and drivers/char.

Of course, the discussion is the easy part. The proof of the pudding with be the patches.