Cousson, Benoit wrote at Monday, March 05, 2012 6:14 AM:

On 2/29/2012 9:54 PM, Stephen Warren wrote:

quoted

Nicolas Ferre wrote at Wednesday, February 29, 2012 7:54 AM:

quoted

By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of "dma-request" argument.

The DMA client will search its associated DMA controller in the list
and call the registered of_dam_xlate() function to retrieve the
request values.

One simple xlate function is provided for the "single number" type
of request biding.

This implementation is independent from dmaengine so it can also be
used by legacy drivers.

At a high level this seems along the right lines.

The big issue I see is the lack of type-safety in of_get_dma_request()'s
out_data pointer: The DMA xlate function will assume it points at some
particular type, and the client is responsible for allocating that
correct type. However, it's "user"-supplied device tree data that hooks
the two together, and there could easily be mismatches, thus causing
the xlate function to trash memory.

Could each DMA controller (or type of out_data) have some enum in the
kernel that the client passes in, and the DMA engine validates matches
its expectations, to prevent this kind of thing?

Beside u32 and string, do we know what kind of parameters we can expect
to retrieve?
Because we can potentially reduce the scope to these two types only.

I wondered whether different drivers would return arbitrary driver-specific
structs, so that the DT specific would encode not only the DMA request
number, but perhaps some/all of the DMA parameters like transfer size,
wrap, even DMA FIFO address, ...

Still, there might not be much point in doing that, since drivers (at
least on Tegra) are already manually passing this information to the DMA
driver in the non-DT case, so we can just continue doing that same thing.

-- 
nvpublic