Tom, On 23/01/19 4:05 PM, Peter Ujfalusi wrote: > 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.ujfal...@ti.com> >>> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com> >>> Signed-off-by: Vignesh R <vigne...@ti.com> >> >> Reviewed-by: Tom Rini <tr...@konsulko.com> >> >> And the DT binding is common to Linux, and been reviewed there? Or?
As Peter pointed out DT bindings are not yet frozen and may change. Hence, I have added the nodes in -u-boot.dtsi. As and when DT bindings are accepted, these would be moved to base dtsi. UDMA support in kernel is currently blocked due to on going discussions on how UDMA/ring interrupts needs to be modeled and supported (not a so important for U-Boot UDMA support). But, I submitted patches for U-Boot as UDMA is support is required to support networking on AM654 which is essential for ease of booting the platform with U-Boot. > > 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. Will drop this as U-Boot driver does not use them either. > - 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 I plan to align above bindings with Linux as when bindings are accepted into kernel and then port it to U-Boot along with relevant TI-SCI driver code. Meanwhile would it be acceptable to add these nodes in -u-boot.dtsi to get closer to enable tftp? -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
