Tom,
On 22/01/2019 20.56, Tom Rini wrote:
On Tue, Jan 22, 2019 at 08:33:57PM +0530, Vignesh R wrote:
The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis.
The initial driver supports:
- MEM_TO_MEM (TR mode)
- DEV_TO_MEM (Packet mode)
- MEM_TO_DEV (Packet mode)
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Grygorii Strashko grygorii.strashko@ti.com Signed-off-by: Vignesh R vigneshr@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
And the DT binding is common to Linux, and been reviewed there? Or?
The binding is the same for Linux but unfortunately it has not went through a proper review yet due to the fact that I need to wait for the interrupt support to arrive to mainline.
However I have sent an earlier version as RFC: https://www.spinics.net/lists/dmaengine/msg16661.html
As for the bindings (and code): The linux bindings are different:
- there is no ti,psi-proxy anymore. - ringacc uses tisci to get GP ring range and we need ti,sci-rm-range-gp-rings property in DT for it - UDMA also uses tisci to get resource ranges and needs: ti,sci-rm-range-tchan, ti,sci-rm-range-rchan, ti,sci-rm-range-rflow in DT - UDMA does not have/need dma-channels property - properties needed for interrupts (currently msi-parent)
FWIW this is how the MCU NAVSS looks like in Linux atm: https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/arch/arm...
and the binding documentation for UDMA: https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/Document...
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki