On 8 May 2012 22:05, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>
> The data doesn't need to be part of the DMA controller node in order for
> the DMA controller driver to be the entity interpreting it.
>
I rather say, if the dma controller driver is the entity going to interpret the
data, why not provide the data directly through its node at one go?
There is important difference between providing data via clients
during runtime vs providing info about every client to the dmac driver
at one go during its probe.
>
> The advantage here is that:
>
> * The specifier is stored in the client, not the IRQ/GPIO/DMA
> controller's node, so it's located right at the usage site, which
> typically makes working out what resources a client uses easier.
>
A client doesn't really need some n'th channel of some m'th dma controller.
A client simply needs one channel for transmitting data whichever
platform it be.
So {n,m}_channel isn't really a required resource, dma_tx is, which I still
specify in the client's node.
The fact that this information is simply fwd by the client as such to the dmac
(via utility code), makes the ritual even more pointless.
> This also keeps client-specific information out of the provider node,
> allowing it to be fully generic.
>
A typical Samsung SoC has 2 peripheral DMA controllers and
about 40 possible clients. Of which ~20 clients could be served by either of
the two dmacs. Of course hardly ever a machine has 10 clients. It would be
desirable if the dma driver doesn't populate the unused 54(32+32-10) channels,
presumably also reserving limited resources for each, on the machine.
Consider this example ...
A PL330 instance has 8 physical channels and 32 client i/f.
So only 8 client reqs could be active at any time.
PL330 doesn't provide a way to program a true LLI transfer(very useful for
audio) using a single physical channel. However, we could emulate
true LLI if we employ 2 physical channels for one audio channel request.
Obviously, if a machine had 7 or lesser clients, one would freely employ
2 physical channels for audio and yet not worry about starving other clients.
How would we achieve this if the dmac driver was initialized as "fully
generic" ?
>
>> That encoding("channel_id") would be dma
>> controller specific and if we also manage to contain it within fixed number
>> of bytes we could also have common helpers for fetching it,
>
> I don't think there's any need for it to fit into a fixed number of bytes
>
Yeah, I realized that soon after posting.
I think I have run out of ways to explain myself better. FWIW, I won't
object to whatever mechanism folks decide after knowing my concerns.
Best Regards,
-Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
