[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98c254c5-94c1-49b0-b361-617639b781d8@gmail.com>
Date: Tue, 3 Feb 2026 08:37:29 +0200
From: Péter Ujfalusi <peter.ujfalusi@...il.com>
To: Sai Sree Kartheek Adivi <s-adivi@...com>, vkoul@...nel.org,
robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, nm@...com,
ssantosh@...nel.org, dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
vigneshr@...com
Cc: r-sharma3@...com, gehariprasath@...com
Subject: Re: [PATCH v4 15/19] dmaengine: ti: k3-udma-v2: New driver for K3
BCDMA_V2
On 30/01/2026 13:01, Sai Sree Kartheek Adivi wrote:
> Add support for BCDMA_V2.
>
> The BCDMA_V2 is different than the existing BCDMA supported by the
> k3-udma driver.
>
> The changes in BCDMA_V2 are:
> - Autopair: There is no longer a need for PSIL pair and AUTOPAIR bit
> needs to set in the RT_CTL register.
> - Static channel mapping: Each channel is mapped to a single peripheral.
> - Direct IRQs: There is no INT-A and interrupt lines from DMA are
> directly connected to GIC.
> - Remote side configuration handled by DMA. So no need to write to PEER
> registers to START / STOP / PAUSE / TEARDOWN.
>
> Signed-off-by: Sai Sree Kartheek Adivi <s-adivi@...com>
> ---
> drivers/dma/ti/Kconfig | 16 +-
> drivers/dma/ti/Makefile | 1 +
> drivers/dma/ti/k3-udma-common.c | 75 +-
> drivers/dma/ti/k3-udma-v2.c | 1283 +++++++++++++++++++++++++++++
> drivers/dma/ti/k3-udma.h | 117 +--
> include/linux/soc/ti/k3-ringacc.h | 3 +
> 6 files changed, 1429 insertions(+), 66 deletions(-)
> create mode 100644 drivers/dma/ti/k3-udma-v2.c
>
> diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
> index 712e456015459..ada2ea8aca4b0 100644
> --- a/drivers/dma/ti/Kconfig
> +++ b/drivers/dma/ti/Kconfig
> @@ -49,6 +49,18 @@ config TI_K3_UDMA
> Enable support for the TI UDMA (Unified DMA) controller. This
> DMA engine is used in AM65x and j721e.
>
> +config TI_K3_UDMA_V2
> + tristate "Texas Instruments K3 UDMA v2 support"
> + depends on ARCH_K3
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + select TI_K3_UDMA_COMMON
> + select TI_K3_RINGACC
> + select TI_K3_PSIL
> + help
> + Enable support for the TI UDMA (Unified DMA) v2 controller. This
> + DMA engine is used in AM62L.
> +
> config TI_K3_UDMA_COMMON
> tristate
> default n
> @@ -56,14 +68,14 @@ config TI_K3_UDMA_COMMON
> config TI_K3_UDMA_GLUE_LAYER
> tristate "Texas Instruments UDMA Glue layer for non DMAengine users"
> depends on ARCH_K3 || COMPILE_TEST
> - depends on TI_K3_UDMA
> + depends on TI_K3_UDMA || TI_K3_UDMA_V2
At this point the glue layer should not have dependency on UDMA_V2 as it
only receives BCDMA support, which is not used by the glue?
> help
> Say y here to support the K3 NAVSS DMA glue interface
> If unsure, say N.
>
> config TI_K3_PSIL
> tristate
> - default TI_K3_UDMA
> + default TI_K3_UDMA || TI_K3_UDMA_V2
>
> config TI_DMA_CROSSBAR
> bool
> diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
> index 41bfba944dc6c..296aa3421e71b 100644
> --- a/drivers/dma/ti/Makefile
> +++ b/drivers/dma/ti/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_TI_CPPI41) += cppi41.o
> obj-$(CONFIG_TI_EDMA) += edma.o
> obj-$(CONFIG_DMA_OMAP) += omap-dma.o
> obj-$(CONFIG_TI_K3_UDMA) += k3-udma.o
> +obj-$(CONFIG_TI_K3_UDMA_V2) += k3-udma-v2.o
> obj-$(CONFIG_TI_K3_UDMA_COMMON) += k3-udma-common.o
> obj-$(CONFIG_TI_K3_UDMA_GLUE_LAYER) += k3-udma-glue.o
> k3-psil-lib-objs := k3-psil.o \
> diff --git a/drivers/dma/ti/k3-udma-common.c b/drivers/dma/ti/k3-udma-common.c
> index 0ffc6becc402e..ba0fc048234ac 100644
> --- a/drivers/dma/ti/k3-udma-common.c
> +++ b/drivers/dma/ti/k3-udma-common.c
> @@ -171,8 +171,13 @@ bool udma_is_desc_really_done(struct udma_chan *uc, struct udma_desc *d)
> uc->config.dir != DMA_MEM_TO_DEV || !(uc->config.tx_flags & DMA_PREP_INTERRUPT))
> return true;
>
> - peer_bcnt = udma_tchanrt_read(uc, UDMA_CHAN_RT_PEER_BCNT_REG);
> - bcnt = udma_tchanrt_read(uc, UDMA_CHAN_RT_BCNT_REG);
> + if (uc->ud->match_data->type >= DMA_TYPE_BCDMA_V2) {
> + peer_bcnt = udma_chanrt_read(uc, UDMA_CHAN_RT_PERIPH_BCNT_REG);
> + bcnt = udma_chanrt_read(uc, UDMA_CHAN_RT_BCNT_REG);
> + } else {
> + peer_bcnt = udma_tchanrt_read(uc, UDMA_CHAN_RT_PEER_BCNT_REG);
> + bcnt = udma_tchanrt_read(uc, UDMA_CHAN_RT_BCNT_REG);
> + }
>
> /* Transfer is incomplete, store current residue and time stamp */
> if (peer_bcnt < bcnt) {
> @@ -319,6 +324,7 @@ udma_prep_slave_sg_tr(struct udma_chan *uc, struct scatterlist *sgl,
> size_t tr_size;
> int num_tr = 0;
> int tr_idx = 0;
> + u32 extra_flags = 0;
nitpick: reverse christmas tree order
> u64 asel;
>
> /* estimate the number of TRs we will need */
> @@ -342,6 +348,9 @@ udma_prep_slave_sg_tr(struct udma_chan *uc, struct scatterlist *sgl,
> else
> asel = (u64)uc->config.asel << K3_ADDRESS_ASEL_SHIFT;
>
> + if (dir == DMA_MEM_TO_DEV && uc->ud->match_data->type == DMA_TYPE_BCDMA_V2)
I would add the evaluation order in reverse to skip checking direction
for UDMA_V1.
> + extra_flags = CPPI5_TR_CSF_EOP;
> +
> tr_req = d->hwdesc[0].tr_req_base;
> for_each_sg(sgl, sgent, sglen, i) {
> dma_addr_t sg_addr = sg_dma_address(sgent);
> @@ -358,7 +367,7 @@ udma_prep_slave_sg_tr(struct udma_chan *uc, struct scatterlist *sgl,
>
> cppi5_tr_init(&tr_req[tr_idx].flags, CPPI5_TR_TYPE1, false,
> false, CPPI5_TR_EVENT_SIZE_COMPLETION, 0);
> - cppi5_tr_csf_set(&tr_req[tr_idx].flags, CPPI5_TR_CSF_SUPR_EVT);
> + cppi5_tr_csf_set(&tr_req[tr_idx].flags, CPPI5_TR_CSF_SUPR_EVT | extra_flags);
>
> sg_addr |= asel;
> tr_req[tr_idx].addr = sg_addr;
> @@ -372,7 +381,7 @@ udma_prep_slave_sg_tr(struct udma_chan *uc, struct scatterlist *sgl,
> false, false,
> CPPI5_TR_EVENT_SIZE_COMPLETION, 0);
> cppi5_tr_csf_set(&tr_req[tr_idx].flags,
> - CPPI5_TR_CSF_SUPR_EVT);
> + CPPI5_TR_CSF_SUPR_EVT | extra_flags);
>
> tr_req[tr_idx].addr = sg_addr + tr0_cnt1 * tr0_cnt0;
> tr_req[tr_idx].icnt0 = tr1_cnt0;
> @@ -632,7 +641,8 @@ int udma_configure_statictr(struct udma_chan *uc, struct udma_desc *d,
> d->static_tr.bstcnt = d->residue / d->sglen / div;
> else
> d->static_tr.bstcnt = d->residue / div;
> - } else if (uc->ud->match_data->type == DMA_TYPE_BCDMA &&
> + } else if ((uc->ud->match_data->type == DMA_TYPE_BCDMA ||
> + uc->ud->match_data->type == DMA_TYPE_BCDMA_V2) &&
Have you thought of adding a version member to struct udma_match_data
and use that instead of distinct different types for BCDMA/PKTDMA?
Here for example you would not need any change as the code is common for
both v1 and v2.
> uc->config.dir == DMA_DEV_TO_MEM &&
> uc->cyclic) {
> /*
...
> diff --git a/drivers/dma/ti/k3-udma-v2.c b/drivers/dma/ti/k3-udma-v2.c
> new file mode 100644
> index 0000000000000..af06d25fd598b
> --- /dev/null
> +++ b/drivers/dma/ti/k3-udma-v2.c
...
> +static bool udma_v2_dma_filter_fn(struct dma_chan *chan, void *param)
> +{
> + struct udma_chan_config *ucc;
> + struct psil_endpoint_config *ep_config;
> + struct udma_v2_filter_param *filter_param;
> + struct udma_chan *uc;
> + struct udma_dev *ud;
nitpick: reverse christmas tree order
also in few other places.
--
Péter
Powered by blists - more mailing lists