[U-Boot] [PATCH 4/6] dma: ti: add driver to K3 UDMA

[Tom Rini]

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.ujfalusi at ti.com>
> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
> >>> Signed-off-by: Vignesh R <vigneshr at ti.com>
> >>
> >> Reviewed-by: Tom Rini <trini at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190123/b7b5b956/attachment.sig>