mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rishikesh Donadkar <r-donadkar@ti.com>
To: Jai Luthra <jai.luthra@ideasonboard.com>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Vignesh Raghavendra <vigneshr@ti.com>
Cc: <y-abhilashchandra@ti.com>, <devarsht@ti.com>, <s-jain1@ti.com>,
	<mchehab@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
	<p.zabel@pengutronix.de>, <conor+dt@kernel.org>,
	<sakari.ailus@linux.intel.com>, <hverkuil-cisco@xs4all.nl>,
	<changhuang.liang@starfivetech.com>, <jack.zhu@starfivetech.com>,
	<sjoerd@collabora.com>, <dan.carpenter@linaro.org>,
	<hverkuil+cisco@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<jai.luthra@linux.dev>, <laurent.pinchart@ideasonboard.com>,
	<mripard@kernel.org>
Subject: Re: [PATCH v9 15/19] media: ti: j721e-csi2rx: Change the drain architecture for multistream
Date: Mon, 19 Jan 2026 10:38:40 +0530	[thread overview]
Message-ID: <fa6a32f4-c1a5-4c91-9c7e-b148257e631b@ti.com> (raw)
In-Reply-To: <176849292515.3449975.5983605057289270065@freya>


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.
Makes sense, if we have such API we can drain a full frame as Tomi 
suggested and also not care about the next frame being a partial one.
>
> 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@ideasonboard.com>
>>> Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
>>> Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com>
> [...]

  parent reply	other threads:[~2026-01-19  5:08 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30  8:32 [PATCH v9 00/19] media: cadence,ti: CSI2RX Multistream Support Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 01/19] media: ti: j721e-csi2rx: Remove word size alignment on frame width Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 02/19] dt-bindings: media: ti,j721e-csi2rx-shim: Support 32 dma chans Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 03/19] media: ti: j721e-csi2rx: separate out device and context Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 04/19] media: ti: j721e-csi2rx: prepare SHIM code for multiple contexts Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 05/19] media: ti: j721e-csi2rx: allocate DMA channel based on context index Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 06/19] media: ti: j721e-csi2rx: add a subdev for the core device Rishikesh Donadkar
2026-01-14 15:21   ` Tomi Valkeinen
2026-01-15  6:36     ` Jai Luthra
2026-01-15 12:56       ` Tomi Valkeinen
2026-01-20 23:25         ` Laurent Pinchart
2026-01-21  7:38           ` Tomi Valkeinen
2026-01-21 10:52             ` Laurent Pinchart
2026-01-22  6:53               ` Jai Luthra
2026-01-22  9:53                 ` Laurent Pinchart
2026-02-28 17:49                   ` Jai Luthra
2026-01-21  9:10     ` Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 07/19] media: cadence: csi2rx: Move to .enable/disable_streams API Rishikesh Donadkar
2026-01-14 15:25   ` Tomi Valkeinen
2025-12-30  8:32 ` [PATCH v9 08/19] media: staging: starfive: Move to enabel-disable streams in starfive drivers Rishikesh Donadkar
2026-01-14 12:51   ` Jai Luthra
2026-01-14 13:05     ` Laurent Pinchart
2025-12-30  8:32 ` [PATCH v9 09/19] media: ti: j721e-csi2rx: get number of contexts from device tree Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 10/19] media: cadence: csi2rx: add get_frame_desc wrapper Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 11/19] media: ti: j721e-csi2rx: add support for processing virtual channels Rishikesh Donadkar
2026-01-14 15:31   ` Tomi Valkeinen
2026-01-16 10:28     ` Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 12/19] media: cadence: csi2rx: add multistream support Rishikesh Donadkar
2026-01-15 12:01   ` Tomi Valkeinen
2026-01-16 11:04     ` Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 13/19] media: ti: j721e-csi2rx: " Rishikesh Donadkar
2026-01-15 12:27   ` Tomi Valkeinen
2026-01-20  8:48     ` Rishikesh Donadkar
2026-01-15 12:28   ` Tomi Valkeinen
2026-01-20  8:52     ` Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 14/19] media: ti: j721e-csi2rx: Submit all available buffers Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 15/19] media: ti: j721e-csi2rx: Change the drain architecture for multistream Rishikesh Donadkar
2026-01-15 12:37   ` Tomi Valkeinen
2026-01-15 16:02     ` Jai Luthra
2026-01-16 10:11       ` Vignesh Raghavendra
2026-01-19  5:08       ` Rishikesh Donadkar [this message]
2026-01-19  5:04     ` Rishikesh Donadkar
2025-12-30  8:32 ` [PATCH v9 16/19] media: ti: j721e-csi2rx: Return the partial frame as error Rishikesh Donadkar
2026-01-06 11:15   ` Jai Luthra
2026-01-08  5:37     ` Rishikesh Donadkar
2026-01-15 12:39   ` Tomi Valkeinen
2025-12-30  8:32 ` [PATCH v9 17/19] media: cadence: csi2rx: Support runtime PM Rishikesh Donadkar
2026-01-14 17:04   ` Tomi Valkeinen
2025-12-30  8:32 ` [PATCH v9 18/19] media: ti: j721e-csi2rx: Support runtime suspend Rishikesh Donadkar
2026-01-15 12:46   ` Tomi Valkeinen
2026-01-19  6:04     ` Jai Luthra
2025-12-30  8:32 ` [PATCH v9 19/19] media: ti: j721e-csi2rx: Support system suspend using pm_notifier Rishikesh Donadkar
2026-01-15 12:50   ` Tomi Valkeinen
2026-01-19  5:25     ` Rishikesh Donadkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa6a32f4-c1a5-4c91-9c7e-b148257e631b@ti.com \
    --to=r-donadkar@ti.com \
    --cc=changhuang.liang@starfivetech.com \
    --cc=conor+dt@kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=devarsht@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hverkuil+cisco@kernel.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jack.zhu@starfivetech.com \
    --cc=jai.luthra@ideasonboard.com \
    --cc=jai.luthra@linux.dev \
    --cc=krzk+dt@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=s-jain1@ti.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sjoerd@collabora.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=vigneshr@ti.com \
    --cc=y-abhilashchandra@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®