linux-kernel - Re: [PATCH v4 16/19] dmaengine: ti: k3-udma-v2: Add support for PKTDMA V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f423267e-4324-4770-877f-78869ed6a360@ti.com>
Date: Tue, 3 Feb 2026 13:21:17 +0530
From: Sai Sree Kartheek Adivi <s-adivi@...com>
To: Péter Ujfalusi <peter.ujfalusi@...il.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 16/19] dmaengine: ti: k3-udma-v2: Add support for
 PKTDMA V2


On 03/02/26 11:55, Péter Ujfalusi wrote:
>
> On 30/01/2026 13:01, Sai Sree Kartheek Adivi wrote:
>> The PKTDMA V2 is different than the existing PKTDMA supported by the
>> k3-udma driver.
>>
>> The changes in PKTDMA 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.
> Plus I suppose..
>
>> Signed-off-by: Sai Sree Kartheek Adivi <s-adivi@...com>
>> ---
>>   drivers/dma/ti/k3-udma-common.c |  29 ++++-
>>   drivers/dma/ti/k3-udma-v2.c     | 219 ++++++++++++++++++++++++++++++--
>>   drivers/dma/ti/k3-udma.h        |   3 +
>>   3 files changed, 232 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/dma/ti/k3-udma-common.c b/drivers/dma/ti/k3-udma-common.c
>> index ba0fc048234ac..d6459bcc17599 100644
>> --- a/drivers/dma/ti/k3-udma-common.c
>> +++ b/drivers/dma/ti/k3-udma-common.c
>> @@ -2461,12 +2461,21 @@ int pktdma_setup_resources(struct udma_dev *ud)
>>   
>>   	ud->tchan_map = devm_kmalloc_array(dev, BITS_TO_LONGS(ud->tchan_cnt),
>>   					   sizeof(unsigned long), GFP_KERNEL);
>> +	bitmap_zero(ud->tchan_map, ud->tchan_cnt);
>>   	ud->tchans = devm_kcalloc(dev, ud->tchan_cnt, sizeof(*ud->tchans),
>>   				  GFP_KERNEL);
>> -	ud->rchan_map = devm_kmalloc_array(dev, BITS_TO_LONGS(ud->rchan_cnt),
>> -					   sizeof(unsigned long), GFP_KERNEL);
>> -	ud->rchans = devm_kcalloc(dev, ud->rchan_cnt, sizeof(*ud->rchans),
>> -				  GFP_KERNEL);
>> +	if (ud->match_data->type == DMA_TYPE_PKTDMA_V2) {
>> +		ud->rchan_map = ud->tchan_map;
>> +		ud->rchans = ud->tchans;
>> +		ud->chan_map = ud->tchan_map;
>> +		ud->chans = ud->tchans;
> It has single channel space and the TX/RX functionality alternates
> within the space?
> chX: TX, chX+1: TX, chX+2: RX, chX+3: TX, etc?
Yes Peter, that is the case.
>
>> +	} else {
>> +		ud->rchan_map = devm_kmalloc_array(dev, BITS_TO_LONGS(ud->rchan_cnt),
>> +						   sizeof(unsigned long), GFP_KERNEL);
>> +		bitmap_zero(ud->rchan_map, ud->rchan_cnt);
>> +		ud->rchans = devm_kcalloc(dev, ud->rchan_cnt, sizeof(*ud->rchans),
>> +					  GFP_KERNEL);
>> +	}
> ...
>
>> diff --git a/drivers/dma/ti/k3-udma-v2.c b/drivers/dma/ti/k3-udma-v2.c
>> index af06d25fd598b..6761a079025ba 100644
>> --- a/drivers/dma/ti/k3-udma-v2.c
>> +++ b/drivers/dma/ti/k3-udma-v2.c
>> @@ -744,6 +744,146 @@ static int bcdma_v2_alloc_chan_resources(struct dma_chan *chan)
>>   	return ret;
>>   }
>>   
>> +static int pktdma_v2_alloc_chan_resources(struct dma_chan *chan)
>> +{
>> +	struct udma_chan *uc = to_udma_chan(chan);
>> +	struct udma_dev *ud = to_udma_dev(chan->device);
>> +	u32 irq_ring_idx;
>> +	__be32 addr[2] = {0, 0};
>> +	struct of_phandle_args out_irq;
>> +	int ret;
> Nitpick: revers christmas tree declaration order.
>