On 05/16/2012 11:22 AM, Jassi Brar wrote:
[...]
> OK, my guts feel people might be interested in what's cooking on
> my side. I started with the binding text first and then would write
> code based upon that approach.
>
> The following might be tweaked as I look deeper into client and DMAC
> drivers while deciding upon what the helper functions should be optimally...
>
> -------------------- 8< --------------------
>
>
> Generic binding to provide a way to provide the client-channel map and
> other dmac specific parameters to the dma controller driver
>
> DMA Model:-
> Only the most common characteristics of a dma setup are assumed
> in this binding.
> Client: Some h/w controller that could request a DMA controller in
> the system to perform data transfer on its behalf. Example SPI, MMC,
> I2S etc.
> DMAC: A DMA Controller instance. Example, PL330, PL08X, SDMA etc.
>
> The assumed model of the DMAC, in this binding, has P peripheral
> interfaces (P request signals) that could request a data transfer
> and C physical channels that actually do the data transfers, hence,
> at most C out of P peripherals could be served by the DMAC at any
> point of time. Usually C := P, but not always. Usually, any of the
> physical channels could be employed by the DMAC driver to serve any
> client.
> The DMAC driver identifies a client by its i/f number, 'peri_id'
> on the given DMAC. For example, TX for SPI has 7th while RX_TX
> (half-duplex) for MMC has 10th peripheral interface (request-signal)
> on a given DMAC. Usually, any of the physical channels could be
> employed by the DMAC driver to serve a client.
>
> * DMA Controller
>
> Required property:
>
> - #map-cells: Number of elements in each chan-map entry.
> At least 3 elements are required by this binding.
>
> - chan-map: List of entries that specify clients' 'peri_id'.
> and also possibly DMAC specific per-client data.
> The first element of each entry being the client's
> phandle. The second the direction of data transfer
> w.r.t the client 1 for RX, 2 for TX and 3 for RX|TX.
> The third the 'peri_id' of the client's request signal
> on the DMAC.
>
> Optional properties:
>
> - #dma-peri-ifs: P, usually the DMAC driver would simply assume the
> number of entries in the 'chan-map' property to be the
> effective number of peripheral request interfaces on the
> DMAC. If specified, it should be at least the number of
> entries in the 'chan-map' property.
>
> - #dma-channels: C, if specified, it should neither be more than
> the value of 'dma-peri-ifs' nor equal to zero.
> If unspecified, it is assumed to be equal to the value of
> 'dma-peri-ifs', i.e, C := P
>
> - #private-data: Peculiarities of the DMAC setup, not taken into
> account by this generic model. The decoding of it would
> be private to the DMAC's driver. For ex, some DMAC drivers
> for dmaengine would specify dma_cap_mask_t for the DMAC,
> if they don't need to specify it on a per-client basis
> (i.e, via 4th element of a 'chan-map' entry).
>
> Example:
>
> dma-controller@0 {
> compatible = "foo,dmac-xxx";
> #private-data = <0x80808080>;
> #dma-peri-ifs = <32>;
> #dma-channels = <8>;
> #map-cells = <3>;
> chan-map =
> <&i2s1 1 2>, /* peri_id of I2S's RX is 2 */
> <&i2s1 2 3>, /* peri_id of I2S's TX is 3 */
> <&mmc1 3 5>, /* peri_id of MMC's RX_TX is 5 */
> <&spi1 1 6>,
> <&spi1 2 8>,
> ...;
> };
>
>
> * Client Controller
>
> Required property: None.
> The client's DT node doesn't need any DMA specifier.
> Typically it would only comment about the data transfer
> direction associated with each of its request signal.
> Preferably also mentioned in the binding.
>
> Optional property: None.
May be I am still missing something here, but in the case where a client
can use one of two dma controllers, how do you specify which to use? Who
decides?
I was under the impression that you would use the phandle of the dma
controller to specify which controller is used in the client node.
For example ...
i2s1: i2s@70002800 {
/* This controller has a request-signal for TX and RX each
* i.e, the driver is going to request a channel for RX(1)
* and another for TX(2).
*/
dma = <dma-controller0>
...
};
Cheers
Jon
--
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
