On 05/18/2012 02:49 PM, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Stephen Warren wrote:
>> Simple case:
>>
>> /* e.g. FIFO TX DMA req - 2 DMACs possible */
>> dma-req-0 = <&dmac1 DMAC1_DMA_REQ_6>;
>> /* e.g. FIFO RX DMA req 1 DMAC possible */
>> dma-req-1 = <&dmac1 DMAC1_DMA_REQ_8>;
>>
>> Multiple DMAC case:
>>
>> /* e.g. FIFO TX DMA req - 2 DMACs possible */
>> dma-req-0 = <&dmac1 DMAC1_DMA_REQ_6 &dmac2 DMA_2_DMA_REQ_8>;
>> /* e.g. FIFO RX DMA req 1 DMAC possible */
>> dma-req-1 = <&dmac1 DMAC1_DMA_REQ_8>;
>>
>> Then, when the DMA client calls the standard API to "get DMA channel for
>> my outbound DMA request "n", the core code will kasprintf("dma-req-%d",
>> n); to generate the property name. That's how pinctrl works.
>>
>> Does that seem better?
> 
> Yes, that is one way that I suggested at an earlier point. After some
> discussion, I would use a different syntax for these though, to the exact
> same effect, writing it as
> 
> 
>       dmas = <&dmac1 DMAC1_DMA_REQ_6>,  <&dmac2 DMA_2_DMA_REQ_8>,  <&dmac1 
> DMAC1_DMA_REQ_8>;
>       dma-names = "tx", "tx", "rx";

That looks pretty reasonable. One comment below.

> The driver can still request the dma line by name "tx" and the subsystem
> would pick one out of those with the same name.
> 
> For the majority of cases, we would only need a single dma request line

Hmm. Many devices have multiple different FIFOs, and hence multiple DMA
request signals (e.g. Tegra I2S has separate RX and TX FIFO, Tegra
S/PDIF has 2 FIFOs in each direction). That would require the driver to
always use get_by_name() to differentiate between 2/4 options for the
same DMA req or 2/4 different DMA requests. Most other bindings allow
use of get_by_id() or get_by_name() interchangeably.

> and could leave out the dma-names property, so when you don't ask for a
> specific name, you just get any dma line out of the dmas array.
> 
>       Arnd
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to