Hi, On 30/09/2020 12.13, Peter Ujfalusi wrote: > Hi, for some reason I have missed Grygorii from the TO, sorry. Grygorii: the series in lore: https://lore.kernel.org/lkml/20200930091412.8020-1-peter.ujfalusi@xxxxxx/ > The series have build dependency on ti_sci/soc series (v1): > https://lore.kernel.org/lkml/20200928083429.17390-1-peter.ujfalusi@xxxxxx/ > > The unmapped event handling in INTA is also needed, but it is not a build > dependency (v2): > https://lore.kernel.org/lkml/20200930074559.18028-1-peter.ujfalusi@xxxxxx/ > > The DMSS introduced within AM64 as a simplified Data movement engine is built > on similar grounds as the K3 NAVSS and UDMAP, but with significant architectural > changes. > > - Rings are built into the DMAs > The DMAs no longer use the general purpose ringacc, all rings has been moved > inside of the DMAs. The new rings within the DMAs are simplified to be dual > directional compared to the uni-directional rings in ringacc. > There is no more of a concept of generic purpose rings, all rings are assigned > to specific channels or flows. > > - Per channel coherency support > The DMAs use the 'ASEL' bits to select data and configuration fetch path. The > ASEL bits are placed at the unused parts of any address field used by the > DMAs (pointers to descriptors, addresses in descriptors, ring base addresses). > The ASEL is not part of the address (the DMAs can address 48bits). > Individual channels can be configured to be coherent (via ACP port) or non > coherent individually by configuring the ASEL to appropriate value. > > - Two different DMAs (well, three actually) > PKTDMA > Similar to UDMAP channels configured in packet mode. > The flow configuration of the channels has changed significantly in a way that > each channel have at least one flow assigned at design time and each flow is > directly mapped to corresponding ring. > When multiple flows are set, the channel can only use the flows within it's > assigned range. > PKTDMA also introduced multiple tflows which did not existed in UDMAP. > > BCDMA > It has two types of channels: > - split channels (tchan/rchan): Similar to UDMAP channels configured in TR mode. > - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, they > can be used for mem2mem type of transfers or to service peripherals not > accessible via PSI-L by using external triggers for the TR. > BCDMA channels do not have support for multiple flows > > With the introduction of the new DMAs (especially the BCDMA) we also need to > update the resource manager code to support the second range from sysfw for > UDMA channels. > > The two outstanding change in the series in my view is > the handling of the DMAs sideband signal of ASEL to select path to provide > coherency or non coherency. > > the smaller one is the device_router_config callback to allow the configuration > of the triggers when BCDMA is servicing a triggering peripheral to solve a > chicken-egg situation: > The router needs to know the event number to send which in turn depends on the > channel we got for servicing the peripheral. > > I'm sending this series as early as possible to have time for review and > changes. > > When all things resolved, it would be nice if Santosh could create an immutable > branch with the ti_sci/soc patches for Vinod to use for this series. > > Regards, > Peter > --- > Grygorii Strashko (1): > soc: ti: k3-ringacc: add AM64 DMA rings support. > > Peter Ujfalusi (16): > dmaengine: of-dma: Add support for optional router configuration > callback > dmaengine: Add support for per channel coherency handling > dmaengine: doc: client: Update for dmaengine_get_dma_device() usage > dmaengine: dmatest: Use dmaengine_get_dma_device > dmaengine: ti: k3-udma: Wait for peer teardown completion if supported > dmaengine: ti: k3-udma: Add support for second resource range from > sysfw > dmaengine: ti: k3-udma-glue: Add function to get device pointer for > DMA API > dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings > dt-bindings: dma: ti: Add document for K3 BCDMA > dt-bindings: dma: ti: Add document for K3 PKTDMA > dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA > dmaengine: ti: k3-psil: Add initial map for AM64 > dmaengine: ti: Add support for k3 event routers > dmaengine: ti: k3-udma: Initial support for K3 BCDMA > dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling > dmaengine: ti: k3-udma: Initial support for K3 PKTDMA > > Vignesh Raghavendra (1): > dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA > > .../devicetree/bindings/dma/ti/k3-bcdma.yaml | 183 ++ > .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 189 ++ > Documentation/driver-api/dmaengine/client.rst | 4 +- > drivers/dma/dmatest.c | 13 +- > drivers/dma/of-dma.c | 10 + > drivers/dma/ti/Makefile | 3 +- > drivers/dma/ti/k3-psil-am64.c | 75 + > drivers/dma/ti/k3-psil-priv.h | 1 + > drivers/dma/ti/k3-psil.c | 1 + > drivers/dma/ti/k3-udma-glue.c | 294 ++- > drivers/dma/ti/k3-udma-private.c | 39 + > drivers/dma/ti/k3-udma.c | 1975 +++++++++++++++-- > drivers/dma/ti/k3-udma.h | 27 +- > drivers/soc/ti/k3-ringacc.c | 325 ++- > include/linux/dma/k3-event-router.h | 16 + > include/linux/dma/k3-psil.h | 16 + > include/linux/dma/k3-udma-glue.h | 12 + > include/linux/dmaengine.h | 14 + > include/linux/soc/ti/k3-ringacc.h | 17 + > 19 files changed, 2994 insertions(+), 220 deletions(-) > create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml > create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml > create mode 100644 drivers/dma/ti/k3-psil-am64.c > create mode 100644 include/linux/dma/k3-event-router.h > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
