From: Jai Luthra <jai.luthra@ideasonboard.com>
To: Rishikesh Donadkar <r-donadkar@ti.com>,
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
jai.luthra@linux.dev, laurent.pinchart@ideasonboard.com,
mripard@kernel.org, Vignesh Raghavendra <vigneshr@ti.com>
Cc: y-abhilashchandra@ti.com, devarsht@ti.com, s-jain1@ti.com,
vigneshr@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
Subject: Re: [PATCH v8 17/18] media: ti: j721e-csi2rx: Support runtime suspend
Date: Mon, 08 Dec 2025 13:06:18 +0530 [thread overview]
Message-ID: <176517937821.20066.4604793543801654609@freya> (raw)
In-Reply-To: <032b441e-eefc-4574-bf7a-5c4d09599925@ideasonboard.com>
Hi Tomi,
Quoting Tomi Valkeinen (2025-12-01 18:52:36)
> Hi,
>
> On 12/11/2025 13:54, Rishikesh Donadkar wrote:
> > From: Jai Luthra <jai.luthra@ideasonboard.com>
> >
> > Add support for runtime power-management to enable powering off the
> > shared power domain between Cadence CSI2RX and TI CSI2RX wrapper when
> > the device(s) are not in use.
> >
> > When powering off the IP, the PSI-L endpoint loses the paired DMA
> > channels. Thus we have to release the DMA channels at runtime suspend
> > and request them again at resume.
>
> I'm not an expert on the dmaengine, but to me this sounds like a bug in
> the dma driver. It just sounds very wrong...
>
Cc: Vignesh
IIRC this was done because on AM62 the CSI2RX is on a separate power domain
and it uses DMA channels from the system-wide DMA engine.
And as those two drivers have different set of users, we have situations
where CSI2RX goes to runtime suspend state and turns off the power and
clocks, while the DMA engine remains on as it has other users. This leads
to the paired PSIL channels to become invalid, and needs a re-pairing.
I am not an expert on DMA engine APIs to know how feasible it would be to
do the book-keeping of the power state of various devices in the DMA driver
and manage the re-pairing entirely there.
On AM62A and later devices, there is a dedicated instance of the BCDMA
engine for camera pipeline on the same power domain as CSI2RX, so this is
not a problem. Rishikesh/Vignesh please correct me if I'm wrong, as it has
been a while since I looked at this in depth.
> > Tested-by: Rishikesh Donadkar <r-donadkar@ti.com>
> > Reviewed-by: Rishikesh Donadkar <r-donadkar@ti.com>
> > Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
> > Signed-off-by: Rishikesh Donadkar <r-donadkar@ti.com>
> > ---
> > drivers/media/platform/ti/Kconfig | 1 +
> > .../platform/ti/j721e-csi2rx/j721e-csi2rx.c | 55 ++++++++++++++++++-
> > 2 files changed, 54 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/ti/Kconfig b/drivers/media/platform/ti/Kconfig
> > index 3bc4aa35887e6..a808063e24779 100644
> > --- a/drivers/media/platform/ti/Kconfig
> > +++ b/drivers/media/platform/ti/Kconfig
> > @@ -70,6 +70,7 @@ config VIDEO_TI_J721E_CSI2RX
> > depends on VIDEO_CADENCE_CSI2RX
> > depends on PHY_CADENCE_DPHY_RX || COMPILE_TEST
> > depends on ARCH_K3 || COMPILE_TEST
> > + depends on PM
> > select VIDEOBUF2_DMA_CONTIG
> > select V4L2_FWNODE
> > help
> > diff --git a/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c b/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
> > index 528041ee78cf3..21e032c64b901 100644
> > --- a/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
> > +++ b/drivers/media/platform/ti/j721e-csi2rx/j721e-csi2rx.c
> > @@ -13,6 +13,7 @@
> > #include <linux/module.h>
> > #include <linux/of_platform.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/property.h>
> >
> > #include <media/cadence/cdns-csi2rx.h>
> > @@ -963,12 +964,16 @@ static int ti_csi2rx_start_streaming(struct vb2_queue *vq, unsigned int count)
> > unsigned long flags;
> > int ret = 0;
> >
> > + ret = pm_runtime_resume_and_get(csi->dev);
> > + if (ret)
> > + return ret;
> > +
> > spin_lock_irqsave(&dma->lock, flags);
> > if (list_empty(&dma->queue))
> > ret = -EIO;
> > spin_unlock_irqrestore(&dma->lock, flags);
> > if (ret)
> > - return ret;
> > + goto err;
> >
> > ret = video_device_pipeline_start(&ctx->vdev, &csi->pipe);
> > if (ret)
> > @@ -1024,6 +1029,8 @@ static int ti_csi2rx_start_streaming(struct vb2_queue *vq, unsigned int count)
> > writel(0, csi->shim + SHIM_DMACNTX(ctx->idx));
> > err:
> > ti_csi2rx_cleanup_buffers(ctx, VB2_BUF_STATE_QUEUED);
> > + pm_runtime_put(csi->dev);
> > +
> > return ret;
> > }
> >
> > @@ -1055,6 +1062,7 @@ static void ti_csi2rx_stop_streaming(struct vb2_queue *vq)
> >
> > ti_csi2rx_stop_dma(ctx);
> > ti_csi2rx_cleanup_buffers(ctx, VB2_BUF_STATE_ERROR);
> > + pm_runtime_put(csi->dev);
> > }
> >
> > static const struct vb2_ops csi_vb2_qops = {
> > @@ -1261,7 +1269,9 @@ static void ti_csi2rx_cleanup_notifier(struct ti_csi2rx_dev *csi)
> >
> > static void ti_csi2rx_cleanup_ctx(struct ti_csi2rx_ctx *ctx)
> > {
> > - dma_release_channel(ctx->dma.chan);
> > + if (!pm_runtime_status_suspended(ctx->csi->dev))
> > + dma_release_channel(ctx->dma.chan);
> > +
> > vb2_queue_release(&ctx->vidq);
> >
> > video_unregister_device(&ctx->vdev);
> > @@ -1512,6 +1522,39 @@ static int ti_csi2rx_init_ctx(struct ti_csi2rx_ctx *ctx)
> > return ret;
> > }
> >
> > +static int ti_csi2rx_runtime_suspend(struct device *dev)
> > +{
> > + struct ti_csi2rx_dev *csi = dev_get_drvdata(dev);
> > + int i;
> > +
> > + if (csi->enable_count != 0)
> > + return -EBUSY;
> > +
> > + for (i = 0; i < csi->num_ctx; i++)
> > + dma_release_channel(csi->ctx[i].dma.chan);
> > +
> > + return 0;
> > +}
> > +
> > +static int ti_csi2rx_runtime_resume(struct device *dev)
> > +{
> > + struct ti_csi2rx_dev *csi = dev_get_drvdata(dev);
> > + int ret, i;
> > +
> > + for (i = 0; i < csi->num_ctx; i++) {
> > + ret = ti_csi2rx_init_dma(&csi->ctx[i]);
>
> If runtime_resume always requests the dma channels, is the call to
> ti_csi2rx_init_dma() in ti_csi2rx_init_ctx() needed? If not, you could
> inline the code from ti_csi2rx_init_dma() to here and also drop the
> dma_release_channel() call from ti_csi2rx_cleanup_ctx(), making the flow
> more understandable.
>
Makes sense.
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct dev_pm_ops ti_csi2rx_pm_ops = {
> > + RUNTIME_PM_OPS(ti_csi2rx_runtime_suspend, ti_csi2rx_runtime_resume,
> > + NULL)
> > +};
> > +
> > static int ti_csi2rx_probe(struct platform_device *pdev)
> > {
> > struct device_node *np = pdev->dev.of_node;
> > @@ -1579,6 +1622,10 @@ static int ti_csi2rx_probe(struct platform_device *pdev)
> > goto err_notifier;
> > }
> >
> > + pm_runtime_set_active(csi->dev);
> > + pm_runtime_enable(csi->dev);
> > + pm_request_idle(csi->dev);
>
> I always forget what exactly the runtime_pm funcs do. What's the idea
> here? If you do something else than the plain standard
> pm_runtime_enable(), I think it's good to mention what/why in a comment.
>
https://docs.kernel.org/power/runtime_pm.html#runtime-pm-initialization-device-probing-and-removal
The pm_request_idle() is done to queue up a job to suspend the hardware
until userspace starts streaming, to save power.
The runtime_set_active() is used because the power domain for CSI is by
default turned on when system boots up. But Rishikesh, please double check
that before v9 on AM62.
> > return 0;
> >
> > err_notifier:
> > @@ -1609,6 +1656,9 @@ static void ti_csi2rx_remove(struct platform_device *pdev)
> > mutex_destroy(&csi->mutex);
> > dma_free_coherent(csi->dev, csi->drain.len, csi->drain.vaddr,
> > csi->drain.paddr);
> > + pm_runtime_disable(&pdev->dev);
> > + pm_runtime_set_suspended(&pdev->dev);
> > +
> > }
> >
> > static const struct of_device_id ti_csi2rx_of_match[] = {
> > @@ -1623,6 +1673,7 @@ static struct platform_driver ti_csi2rx_pdrv = {
> > .driver = {
> > .name = TI_CSI2RX_MODULE_NAME,
> > .of_match_table = ti_csi2rx_of_match,
> > + .pm = &ti_csi2rx_pm_ops,
> > },
> > };
> >
>
next prev parent reply other threads:[~2025-12-08 7:36 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 11:54 [PATCH v8 00/18] media: cadence,ti: CSI2RX Multistream Support Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 01/18] media: ti: j721e-csi2rx: Remove word size alignment on frame width Rishikesh Donadkar
2025-11-20 11:58 ` Tomi Valkeinen
2025-11-12 11:54 ` [PATCH v8 02/18] dt-bindings: media: ti,j721e-csi2rx-shim: Support 32 dma chans Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 03/18] media: ti: j721e-csi2rx: separate out device and context Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 04/18] media: ti: j721e-csi2rx: prepare SHIM code for multiple contexts Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 05/18] media: ti: j721e-csi2rx: allocate DMA channel based on context index Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 06/18] media: ti: j721e-csi2rx: add a subdev for the core device Rishikesh Donadkar
2025-11-20 12:39 ` Sakari Ailus
2025-11-21 6:59 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 07/18] media: cadence: csi2rx: Move to .enable/disable_streams API Rishikesh Donadkar
2025-11-20 13:00 ` Tomi Valkeinen
2025-11-21 7:02 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 08/18] media: ti: j721e-csi2rx: " Rishikesh Donadkar
2025-11-20 12:40 ` Sakari Ailus
2025-11-21 7:04 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 09/18] media: ti: j721e-csi2rx: get number of contexts from device tree Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 10/18] media: cadence: csi2rx: add get_frame_desc wrapper Rishikesh Donadkar
2025-11-20 12:40 ` Tomi Valkeinen
2025-12-02 9:03 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 11/18] media: ti: j721e-csi2rx: add support for processing virtual channels Rishikesh Donadkar
2025-11-20 12:32 ` Tomi Valkeinen
2025-12-01 9:25 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 12/18] media: cadence: csi2rx: add multistream support Rishikesh Donadkar
2025-11-20 12:53 ` Sakari Ailus
2025-12-09 9:43 ` Rishikesh Donadkar
2025-12-29 11:14 ` Sakari Ailus
2025-11-20 13:14 ` Tomi Valkeinen
2025-12-09 9:45 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 13/18] media: ti: j721e-csi2rx: " Rishikesh Donadkar
2025-12-01 13:03 ` Tomi Valkeinen
2025-12-09 10:08 ` Rishikesh Donadkar
2025-12-09 10:36 ` Jai Luthra
2025-12-09 11:52 ` Tomi Valkeinen
2025-12-09 12:06 ` Jai Luthra
2025-11-12 11:54 ` [PATCH v8 14/18] media: ti: j721e-csi2rx: Submit all available buffers Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 15/18] media: ti: j721e-csi2rx: Change the drain architecture for multistream Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 16/18] media: cadence: csi2rx: Support runtime PM Rishikesh Donadkar
2025-12-01 13:11 ` Tomi Valkeinen
2025-12-18 5:35 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 17/18] media: ti: j721e-csi2rx: Support runtime suspend Rishikesh Donadkar
2025-11-20 13:16 ` Sakari Ailus
2025-12-08 7:47 ` Jai Luthra
2025-12-08 9:39 ` Sakari Ailus
2025-12-01 13:22 ` Tomi Valkeinen
2025-12-08 7:36 ` Jai Luthra [this message]
2025-12-29 10:07 ` Rishikesh Donadkar
2025-11-12 11:54 ` [PATCH v8 18/18] media: ti: j721e-csi2rx: Support system suspend using pm_notifier Rishikesh Donadkar
2025-12-01 13:46 ` Tomi Valkeinen
2025-12-08 8:01 ` Jai Luthra
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=176517937821.20066.4604793543801654609@freya \
--to=jai.luthra@ideasonboard.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@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=r-donadkar@ti.com \
--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