Generic DMA engines are present in many ARM platforms to enable devices to
move data between main memory and device-specific regions. Arnd Bergmann led
a discussion about the DMA engine APIs as part of the last day of the ARM
minisummit. DMA is the last ARM subsystem that
does not have generic device tree bindings, he said, so he hoped the
assembled developers could agree on some. Without those bindings, the code
that uses DMA is forced to be platform-specific, which impedes progress
toward the goal of building a single kernel image for multiple ARM platforms.
Bergmann said that there are many things currently blocked by the lack of
device tree bindings for DMA. Those bindings need to describe the kinds of
DMA channels available in the hardware, along with their attributes. Two
proposals have been made to add support for the generic DMA engines. Jon
Hunter has a patch set that implements a particular set of bindings, but he
couldn't attend the meeting, so Bergmann presented them. The
other patches were from DMA engine maintainer Vinod Koul.
The differences between the two are a bit hard to decipher.
Both approaches attempt to keep any information about how to set up DMA
channels from both the device driver using them and from the DMA engine
driver that provides them. That knowledge would reside in the DMA engine
core. With Koul's patches, there would be a global lookup table that would
be populated by the platform-specific code from various sources (device
tree, ACPI, etc.). That table would list the
connections between devices and DMA engine drivers. Hunter's patches solve
the problem simply for the device tree case, without requiring interaction
with the platform-specific code.
The discussion got technically quite deep, as Bergmann admitted with a grin
after the session, but the upshot is that the two approaches are not
completely at odds. At the end of the session, it was agreed that both
patches could be merged ("more or less", Koul said). The DMA engine core
would be able to find the connection in either the device tree or via
the lookup table, but will use the same device driver interfaces either way.
Bergmann said that he
hoped to see something in the 3.7 kernel. In between those two discussions, some
things about the device tree bindings were hammered out as well.
One of the first problems noted with the bindings described in Hunter's
patch was the use of numerical values (derived from flag bits) to describe
attributes of DMA channels. "These magic numbers are not a readability
triumph", Mark Brown said. He went on to suggest adding some kind of
preprocessor support to the device tree compiler (dtc), which turns the
text representation into a flattened device tree binary (dtb). That
would make the flags readable, Tony Lindgren said, but he wondered if such
a preprocessor was "years off".
One way around the magic number problem is to use names instead, though
dealing with strings in device tree is difficult, Bergmann said. Some
platforms have complicated arrangements of controllers and DMA engines,
he said, using an example of an MMC (memory card) controller with two
channels, one of
which is connected to three different DMA engines. In order to make the
request API for a DMA channel
relatively simple, it would make sense to name each channel, someone
suggested. One problem there is that most devices (80% perhaps) either
have a single channel or just one for each direction, Bergmann said.
Forcing those devices to explicitly name them adds complexity.
But most were in favor of using the names. In addition to naming the
channels, standardizing the property names would make it easier to scan the
whole device tree for
properties of interest. Allowing devices to come up with their own
property names will make that impossible. Also, when new functional units that
implement DMA get
added to a platform, standardized names will make it easier to incorporate
existing device trees. So, names for each of a device's channels, along
with a standard set of property names, would seem to be in the cards.
This was the last non-hacking session in the ARM minisummit, which seemed
to be a great success overall. Some issues that
had been lingering were discussed and resolved—or at least plans
to do so were made. In addition, the status of some newer features
(e.g. big.LITTLE and
AArch64) was presented, so that questions could be raised and answered in
real time, rather than over a sometimes slow mailing list or IRC channel
pipe. Beyond the discussions, both afternoons featured hacking sessions
where it sounds like some real work got done.
[ I would like to thank Will Deacon and Arnd Bergmann for reviewing parts
of the ARM minisummit coverage, though any remaining errors are mine, of
to post comments)