1. Tue-4-Mar, 10:05am, Arnd Bergmann, Deepak Saxena,
Linus Walleij
LCA14-202: ARM-SOC Status and directions
2. - Device Tree impetus
- Multiplatform targets defined and implemented
- Varying degree of adaption on older platforms, the vast
majority of v6+ systems now use exclusively
multiplatform configuration
- New platforms push all drivers under the drivers/
subsystem hierarchy and avoid ARM/plat/mach-specific
drivers
- New subsystems: pinctrl, clk, irqchip, clocksource,
virtio/rpmsg/remoteproc, reset, extcon, iio ...
- We are slowly processing the pile of older code: board
files, drivers etc, still present in arch/arm/*
Ground Covered So Far
3. 1. Empty mach-* platform/subarch directory
● Mirrors ARM64 architecture
● All platforms merged in 2012 or later
● All ARM reference platforms (vexpress, realview, …)
● Exceptions for quirks and bug fixes
● WIP: SMP support, L2x0, system controller
Goal: Four sets of platforms
4. 1. Empty platform directory
2. Multiplatform and DT enabled
● Most of the actively developed traditional platforms
■ Exynos, OMAP, i.MX, shmobile, …
● Existing board files get removed over time
● Should include all ARMv6 and ARMv7 based
● Also select ARMv5 and ARMv4 platforms
● WIP: exynos, s5p, at91, kirkwood/orion/dove,
integrator, versatile, realview
Goal: Four sets of platforms
5. 1. Empty platform directory
2. Multiplatform and DT enabled
3. Multiplatform with board files, optional DT
● Actively used ARMv5 platforms
● No active maintainer to do DT conversion
● WIP: s3c,
● Future work: ks8695, gemini, w90x900, netx
Goal: Four sets of platforms
6. 1. Empty platform directory
2. Multiplatform and DT enabled
3. Multiplatform with board files, optional DT
4. Legacy platforms without multiplatform:
● Hard to do multiplatform for
● Few remaining users/testers
● Not ready for deletion yet
● Examples: ebsa110, footbridge, sa1100, ixp, iop, rpc
Goal: Four sets of platforms
7. Suggested rationale:
● Don’t break things we cannot test, but clean up as much
as we can
● Subject to refactoring if (and only if):
○ Refactoring can be tested on real hardware
○ Refactoring provides modernization of the platform to recent kernel
framework updates, e.g. if it is standing in the way of reforming
irqchips/domains, generic timers, GPIO descriptors etc.
Rationale
8. ● Device Tree binding review queue and quality of binding
reviews are constantly in question
● Pile of legacy code:
○ Platforms with weird memory layout
(hello RealView EB)
○ Elder PCI hosts
○ Drivers not building on the device model or using custom initcalls
○ Elder video framebuffer drivers need to move to DRM, plat-foo
<plat/*> hierarchy is problematic etc.
● <mach/timex.h> removal is done for 3.15
● early console (between debug_ll and module_init),
possible fbcon for uart-less debugging
● turn more stuff into modules
Imminent Problems
9. ● Debugging, instrumentation and profiling systems are
catching up e.g. kprobes/uprobes/tracing in different
modes such as thumb[2]
● ARM32 and also ARM64 are lacking proper kernel
infrastructure for debugging and profiling hardware such
as CoreSight and bus monitors
● Remove multiplatform roadblocks:
○ DMA remapping bus offsets,
○ moving PCI hosts to drivers/pci,
○ find a way forward for LCD panels,
○ IOMMU detection etc.
● Good runtime PM deployments (separate session!)
Next Steps
10. More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members