linux-kernel - Re: [PATCH v9 15/19] media: ti: j721e-csi2rx: Change the drain architecture for multistream

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: <68e9361a-df0d-4209-84ef-29051d0b5a35@ti.com>
Date: Fri, 16 Jan 2026 15:41:48 +0530
From: Vignesh Raghavendra <vigneshr@...com>
To: Jai Luthra <jai.luthra@...asonboard.com>, Rishikesh Donadkar
	<r-donadkar@...com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
CC: <y-abhilashchandra@...com>, <devarsht@...com>, <s-jain1@...com>,
	<mchehab@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<p.zabel@...gutronix.de>, <conor+dt@...nel.org>,
	<sakari.ailus@...ux.intel.com>, <hverkuil-cisco@...all.nl>,
	<changhuang.liang@...rfivetech.com>, <jack.zhu@...rfivetech.com>,
	<sjoerd@...labora.com>, <dan.carpenter@...aro.org>,
	<hverkuil+cisco@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-media@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<jai.luthra@...ux.dev>, <laurent.pinchart@...asonboard.com>,
	<mripard@...nel.org>
Subject: Re: [PATCH v9 15/19] media: ti: j721e-csi2rx: Change the drain
 architecture for multistream



On 15/01/26 21:32, Jai Luthra wrote:
> Hi Tomi,
> 
> Quoting Tomi Valkeinen (2026-01-15 18:07:07)
>> Hi,
>>
>> On 30/12/2025 10:32, Rishikesh Donadkar wrote:
>>> On buffer starvation the DMA is marked IDLE, and the stale data in the
>>> internal FIFOs gets drained only on the next VIDIOC_QBUF call from the
>>> userspace. This approach works fine for a single stream case.
>>>
>>> But in multistream scenarios, buffer starvation for one stream i.e. one
>>> virtual channel, can block the shared HW FIFO of the CSI2RX IP. This can
>>> stall the pipeline for all other virtual channels, even if buffers are
>>> available for them.
>>
>> One stream is filtered based on VC & DT, but the above only mentions VC.
>> And then later uses VC when referring to the stream. I think you can
>> drop the VC parts, and just talk about streams.
>>
>>> This patch introduces a new architecture, that continuously drains data
>>> from the shared HW FIFO into a small (32KiB) buffer if no buffers are made
>>> available to the driver from the userspace. This ensures independence
>>> between different streams, where a slower downstream element for one
>>> camera does not block streaming for other cameras.
>>>
>>> Additionally, after a drain is done for a VC, the next frame will be a
>>> partial frame, as a portion of its data will have already been drained
>>> before a valid buffer is queued by user space to the driver.
>>
>> This makes it sounds we drain a single 32KB piece. But won't we continue
>> draining that stream until the stream is stopped or the user provides a
>> buffer?
>>
>> Also, does the DMA not offer us ways to drain a full frame? There's no
>> way to e.g. set the DMA TX increment to 0, so that it would just write
>> to a single location in memory? Or just set the target to void.
>>
> 
> + Vignesh
> 
> AFAIU the dmaengine API is the first limitation here, and the actual
> Transfer Record (TR) structure for BCDMA might support writing to a single
> address. It also might be possible to use dmaengine_prep_dma_cyclic to
> setup a auto-repeating TR like it's used for audio.. maybe that can be
> explored separate from this series.
> 

Yeah. there is no dmaengine API that can do mem-to-mem transfer with
constant addressing mode on src or dst. But the DMA HW on TI K3 SoCs are
capable of doing so.


[...]

-- 
Regards
Vignesh
https://ti.com/opensource