On Wed, Jan 23, 2019 at 07:13:11PM +0530, Vignesh R wrote: > 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?
... I knew I should have read the whole thread first. So, how likely do we think the kernel bindings are to see big changes? I wonder if we should re-align things now, or not. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot