From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Date: Fri, 25 Jan 2019 19:53:10 +0530 Subject: [U-Boot] [PATCH 4/6] dma: ti: add driver to K3 UDMA In-Reply-To: <20190123135616.GE28173@bill-the-cat> References: <20190122150359.15919-1-vigneshr@ti.com> <20190122150359.15919-5-vigneshr@ti.com> <20190122185638.GR28173@bill-the-cat> <5474a733-47a9-c66a-39c1-e25a5628b5c9@ti.com> <1da2c6f4-a19b-84ba-087f-db62abc7f222@ti.com> <20190123135616.GE28173@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 23/01/19 7:26 PM, Tom Rini wrote: > 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 >>>>> Signed-off-by: Grygorii Strashko >>>>> Signed-off-by: Vignesh R >>>> >>>> Reviewed-by: Tom Rini >>>> >>>> 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. > I have posted v2 with bindings that are in full alignment with proposed Linux bindings that Peter pointed out above. IMO, I dont expect any big change in these bindings in upstream. -- Regards Vignesh