[Ksummit-2012-discuss] ARM mini-summit notes
will.deacon at arm.com
Wed Aug 29 19:13:56 UTC 2012
The ARM workshop ran over two days, with topic sessions in the mornings
and hacking in the afternoons. The format of the hacking sessions typically
split the participants up into small groups, focussed on addressing a
particular problem or subject (e.g. randconfig fixes, KVM, etc).
The topics discussed were:
Secure Monitor APIs
The interface to the secure world on ARMv7 cores is defined differently
between SoCs and creates problems for Linux when secure services are
required to access crucial parts of the platform (e.g. L2 cache controller).
You can largely separate secure calls into three categories:
* Very early calls, usually from assembly, where knowledge of the
platform is not yet available. (MMU may be off)
* Platform initialisation and management code. Turning on L2,
configuring GIC, booting a secondary CPU etc.
* Secure services. Video encryption from a driver.
Of these, the last can be dealt with at the driver level and the first
is questionable whether Linux should deal with the call at all. Recent
patches from Samsung proposed an initial abstraction for the middle case,
which could leave all of the smc-specifics in the platform code whilst
allowing core code to make use of the functionality without worrying about
the current platform.
Stale Platform Deprecation
There are a number of old platforms in the ARM tree which we can only
built-test for, since hardware is not available.
Proposal to deprecate non-DT platforms after some period of inactivity.
An initial list of platforms was drawn up but it remains to be seen if
people will suddenly emerge as users.
Virtualisation (KVM and Xen)
Xen and KVM both under active development for ARM following the introduction
of virtualisation extensions to the ARMv7 architecture with Cortex-A15.
A new privilege mode (HYP) is added, where the kernel must be entered if
virtualisation is to be used. This may conflict with vendor-specific code
already installed at that privilege level but this is not something that
the current solutions care about -- if a vendor wishes to make use of
virtualisation, they must leave the HYP mode free.
Qemu is a major bottleneck for KVM as all MMIO device accesses are emulated,
whereas Xen allows direct access to the hardware.
An update from Catalin Marinas on ARM's new 64-bit architecture. The
kernel is being pushed as a separate architecture port but there are
concerns that many vendors may just drop an AArch64 CPU into their
In this light, the initial plan is to avoid as much platform code as
possible in the arch/arm64 directory and instead move things out into
drivers, where they may even be shared with arch/arm/. For example,
timers, GIC, etc.
Arnd suggests getting the code into -next ASAP and to aim for 3.7 in
Related talk at LinuxCon.
Paul McKenney gave an update about the ongoing big.LITTLE work for Linux.
big.LITTLE is essentially a way to combine architecturally-identical cores
with very different power/performance characteristics together using a
The two softare approaches for running on such a system are currently:
- Switching: moving the OS state between the big and little cores
- MP: allowing the Linux scheduler to manage all of the cores in
in the system and place tasks accordingly.
Paul Turner discussed his per-task load tracking patches which have been
used to enable the MP case above.
Related Linux Plumbers micro-conference.
arm-soc Process Review
The arm-soc tree has been active for a while now and generally seems to
be working well.
The workflow (multiple branches vs single linear history) may not be
preferred by all SoC vendors, but they are happy enough with the approach
and will continue to follow it.
Signed tags are preferred for new pull requests as they allow some
commentary for the merge and pull requests without them may be rejected
Marek Szyprowski presented his work on the DMA mapping interfaces. Over the last
year, both the Contiguous Memory Allocator (CMA) and the dmabuf framework have
been merged into the mainline kernel, and the ARM architecture has been converted
to use generic dma_map_ops, all based on his work. ARM can also now make use of
I/O memory management units (IOMMU) in the DMA mapping API, and as Arnd Bergmann
pointed out, this code is actually architecture independent and should in the
future be shared with other architectures that have IOMMUs using the
There was some debate over wether CMA should be the default on ARMv6 and ARMv7
platforms. At present, this interface is marked as experimental in the kernel,
but concerns are that it might never become stable unless people actually
start using it in production. There is a known problem with the non-CMA
implementation on ARMv6, which can in theory result in data corruption
because all DMA pages are mapped both cacheable and non-cacheable with this
method, something that is not allowed by the architecture. The CMA implementation
solves this problem, but can introduce allocation failures in certain corner
Arnd Bergmann talked about his recent work on single zImage and how he
sidestepped the problem of header files being duplicated between
subarchitectures by renaming all header files to have a unique name.
Most people in the room preferred a cleaner approach that Russell King
had already asked for on the mailing list. Bergmann had also sent a
smaller patch set to move about a third of the header files, the ones
that contain only platform data definitions, into the
include/linux/platform_data directory, and Rob Herring had another
patch set that enables multiplatform configurations for those platforms
that already do not have any dependencies on platform specific headers.
Those two patch sets were both welcomed by the other maintainers, and a
plan was made to clean up the remaining platforms and device drivers
for good before allowing them to be part of the multiplatform build.
In the final session of the mini summit, the device tree bindings
for the DMA engine subsystem was discussed. Jon Hunter, who could
not particpate in person, recently spent a lot of work on creating
a patch set to introduce that binding. Vinod Koul, the subsystem
maintainer, had some ideas of his own about solving the problem
in a more general way that is not specific to device tree but also
works with Intel's competing SFI data format. In the end, an agreement
was made to combine both approaches, using Hunter's bindings with
small modifications, and providing an abstract device driver interface
that can work independent of the firmware interface.
The main change that was requested for the binding was to remove the
'flags' from dma line, which was generally perceived as obscure.
Instead, each DMA identifier now has to have a name associated with
More information about the Ksummit-2012-discuss