Re: [PATCH v9 18/19] dmaengine: ti: k3-udma-v2: Update glue layer to support PKTDMA V2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dmaengine: ti: inverted hardware teardown sequence for PKTDMA V2 TX channels
- [Medium] dmaengine: ti: missing configuration of error handling flags for PKTDMA V2
--

commit c9030c9c505174820633d0b6b095c2b74c127474
Author: Sai Sree Kartheek Adivi <s-adivi@ti.com>

dmaengine: ti: k3-udma-v2: Update glue layer to support PKTDMA V2

This patch updates the glue layer to support PKTDMA V2 for non DMAengine users.
It adds handling for the absence of TISCI, direct IRQs, and autopairing.

> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
> index 3721edf71f9b3..5a3cac685a46c 100644
> --- a/drivers/dma/ti/k3-udma-glue.c
> +++ b/drivers/dma/ti/k3-udma-glue.c
> @@ -267,6 +268,19 @@ static int k3_udma_glue_cfg_tx_chn(struct k3_udma_glue_tx_channel *tx_chn)
>  	const struct udma_tisci_rm *tisci_rm = tx_chn->common.tisci_rm;
>  	struct ti_sci_msg_rm_udmap_tx_ch_cfg req;
>  
> +	if (!tisci_rm->tisci) {
> +		u32 val = 0;
> +
> +		if (tx_chn->tx_filt_einfo)
> +			val |= UDMA_CHAN_CFG_FILT_EINFO;
> +		if (tx_chn->tx_filt_pswords)
> +			val |= UDMA_CHAN_CFG_FILT_PSWORDS;
> +
> +		xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_CFG_REG, val);
> +
> +		return 0;
> +	}

[Severity: Medium]
When configuring the channel without TISCI, is it intentional that
tx_pause_on_err and tx_supr_tdpkt are silently ignored before the early
return? In the TISCI configuration path further down in this function, these
flags are evaluated and applied, but here they seem to be dropped.

[ ... ]

> @@ -573,8 +605,16 @@ void k3_udma_glue_tdown_tx_chn(struct k3_udma_glue_tx_channel *tx_chn,
>  
>  	k3_udma_glue_dump_tx_rt_chn(tx_chn, "txchn tdown1");
>  
> -	xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_CTL_REG,
> -			    UDMA_CHAN_RT_CTL_EN | UDMA_CHAN_RT_CTL_TDOWN);
> +	if (tx_chn->common.udmax->match_data->version == K3_UDMA_V1) {
> +		xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_CTL_REG,
> +				    UDMA_CHAN_RT_CTL_EN | UDMA_CHAN_RT_CTL_TDOWN);
> +	} else {
> +		val = xudma_tchanrt_read(tx_chn->udma_tchanx, UDMA_CHAN_RT_CTL_REG);
> +		xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_CTL_REG,
> +				    val | UDMA_CHAN_RT_CTL_TDOWN);
> +		xudma_tchanrt_write(tx_chn->udma_tchanx, UDMA_CHAN_RT_PEER_REG(8),
> +				    UDMA_CHAN_RT_PEER_REG8_FLUSH);
> +	}

[Severity: High]
Does this sequence invert the hardware teardown requirements for PKTDMA V2 TX
channels? It looks like the teardown bit (UDMA_CHAN_RT_CTL_TDOWN) is being
written to UDMA_CHAN_RT_CTL_REG before sending the flush command to the peer
via UDMA_CHAN_RT_PEER_REG(8). Does the hardware require flushing the peer
before initiating the teardown to avoid locking up or leaving the channel in
an inconsistent state?

[ ... ]

> @@ -826,6 +883,19 @@ static int k3_udma_glue_cfg_rx_flow(struct k3_udma_glue_rx_channel *rx_chn,
>  		rx_ringfdq_id = k3_ringacc_get_ring_id(flow->ringrxfdq);
>  	}
>  
> +	if (!tisci_rm->tisci) {
> +		u32 val = 0;
> +
> +		if (rx_chn->common.epib)
> +			val |= UDMA_FLOWRT_RFA_RX_EINFO_PRESENT;
> +		if (rx_chn->common.psdata_size)
> +			val |= UDMA_FLOWRT_RFA_RX_PSINFO_PRESENT;
> +
> +		xudma_rflowrt_write(flow->udma_rflow, UDMA_RX_FLOWRT_RFA, val);
> +		rx_chn->flows_ready++;
> +		return 0;
> +	}

[Severity: Medium]
Are we missing the configuration for flow_cfg->rx_error_handling in this new
no-TISCI path? Callers using the glue layer for PKTDMA V2 could request
rx_error_handling, but it appears to be silently ignored here instead of being
written to the hardware registers (like bit 28 of UDMA_RX_FLOWRT_RFA) to enable
hardware flow error handling.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922064902.2719979-1-s-adivi@ti.com?part=18