Message-ID: <176849292515.3449975.5983605057289270065@freya>
Date: Thu, 15 Jan 2026 21:32:05 +0530
From: Jai Luthra <jai.luthra@...asonboard.com>
To: Rishikesh Donadkar <r-donadkar@...com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Vignesh Raghavendra <vigneshr@...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

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.

But yes, ideally we need to set the target to void, which I don't think is
supported by the HW (TI folks please correct me if I'm wrong :)

Thanks,
    Jai

>  Tomi
> 
> > Use wait for completion barrier to make sure the shared hardware FIFO
> > is cleared of the data at the end of stream after the source has stopped
> > sending data.
> > 
> > Reviewed-by: Jai Luthra <jai.luthra@...asonboard.com>
> > Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@...com>
> > Signed-off-by: Rishikesh Donadkar <r-donadkar@...com>

[...]

Powered by blists - more mailing lists