u-boot.git/drivers/dma/ti, branch v2020.01Unnamed repository; edit this file 'description' to name the repository.http://cgit.235523.xyz/u-boot.git/atom/drivers/dma/ti?h=v2020.012019-12-09T15:47:43Znet: ti: am65-cpsw-nuss: Add new compatible for J721e2019-12-09T15:47:43ZVignesh Raghavendravigneshr@ti.com2019-12-04T16:47:23Zurn:sha1:382c0c629e75b6213b638f734db468e23ca4cff3
Add new compatible to handle J721e SoC
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
dma: ti: k3-udma: Implement dma_get_cfg() interface2019-12-09T15:47:43ZVignesh Raghavendravigneshr@ti.com2019-12-04T16:47:21Zurn:sha1:5e6d9ccde9cf700e19e0d783f1f671a1eb4a60fb
Implement dma_get_cfg() interface to pass flow id information for DMA
clients to use. This is needed because on K3 SoCs, CPSW (ethernet) and
UDMA (DMA provider) support "flows" within a given RX DMA channel. This
allows different network packets to be segregated while using same RX
DMA channel. In order for basic ethernet to work, CPSW slave must be
aware of the flow ID allocated for the RX channel by the DMA driver.
This interface allows CPSW to query flow ID from DMA provider and
configure it in CPSW HW.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
common: Move ARM cache operations out of common.h2019-12-02T23:24:58ZSimon Glasssjg@chromium.org2019-11-14T19:57:39Zurn:sha1:1eb69ae498567bb0b62ee554647204e8245cdacc
These functions are CPU-related and do not use driver model. Move them to
cpu_func.h
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
dma: ti: k3-udma: Do not touch RT registers before channel configuration2019-05-03T11:23:17ZPeter Ujfalusipeter.ujfalusi@ti.com2019-04-25T06:38:15Zurn:sha1:5487772517817a7e3b501062f3962b56fad34075
Upcoming sysfw (2019.03) will not open the channelized firewalls during
init, it only going to do so in response to the channel configuration
message.
Remove the channel state checks done before the channel configuration and
move it after the configuration for warning purposes.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
drivers: dma: ti: k3-udma: Extract packet data only when Meta data is not NULL2019-05-03T11:23:17ZKeerthyj-keerthy@ti.com2019-04-24T11:03:54Zurn:sha1:a3f25b925fe690be7744d47df0135321e43e2c2a
Currently packet data is wrongly extracted when metadata is NULL.
Fix it and negate the if check.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
dma: ti: add driver to K3 UDMA2019-04-12T00:07:12ZVignesh Rvigneshr@ti.com2019-02-05T12:01:24Zurn:sha1:ffcc66e8fec52d9c8d909f21c627c80596582dca
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>