Re: [PATCH v5 13/17] dmaengine: sh: rz-dmac: Add runtime PM support

[Frank Li]

On Wed, May 13, 2026 at 04:39:12PM +0300, Claudiu Beznea wrote:
> Hi, Frank,
>
> On 5/13/26 01:03, Frank Li wrote:
> > On Tue, May 12, 2026 at 03:12:14PM +0300, Claudiu Beznea wrote:
> > > Protect the driver exposed APIs with runtime PM suspend/resume calls
> > > before accessing HW registers. As the current driver leaves runtime PM
> > > enabled in probe, the purpose of the changes in this patch is to avoid
> > > accessing HW registers after a failed system suspend leaves the runtime
> > > PM state of the device improperly reinitialized.
> > >
> > > In that case, the driver remains bound to the device, the APIs are still
> > > exposed, and any access to HW registers without runtime resuming the
> > > device may lead to synchronous aborts.
> > >
> > > This patch prepares the driver for suspend-to-RAM support.
> > >
> > > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
> > > ---
> > >
> > > Changes in v5:
> > > - none, this patch is new
> > >
> > >   drivers/dma/sh/rz-dmac.c | 48 ++++++++++++++++++++++++++++++++++++++++
> > >   1 file changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
> > > index d6ad070be705..df91657fd5e3 100644
> > > --- a/drivers/dma/sh/rz-dmac.c
> > > +++ b/drivers/dma/sh/rz-dmac.c
> > > @@ -488,7 +488,15 @@ static void rz_dmac_prepare_descs_for_cyclic(struct rz_dmac_chan *channel)
> > >
> > >   static void rz_dmac_xfer_desc(struct rz_dmac_chan *chan)
> > >   {
> > > +	struct dma_chan *ch = &chan->vc.chan;
> > > +	struct rz_dmac *dmac = to_rz_dmac(ch->device);
> > >   	struct virt_dma_desc *vd;
> > > +	int ret;
> > > +
> > > +	PM_RUNTIME_ACQUIRE_IF_ENABLED(dmac->dev, pm);
> > > +	ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> > > +	if (ret)
> > > +		return;
> >
> > According vnod comment *_prep() call may be called in atomic context
> > (complete callback). but runtime_pm may sleep.
>
> That's why the pm_runtime_irq_safe() was called in probe, to allow it being
> called in atomic context.
>
> The series was tested with CONFIG_LOCKDEP=y and CONFIG_DEBUG_ATOMIC_SLEEP=y
> no issue was identified.

I am not sure how magic it makes pm_runtime_get_sync() work under atomic
context, suppose runtime callback involve clk_(un)prep() and power domain,
if you call pm_runtime_irq_safe() in probe, it may makes all parent resource
on when probe. At least it should defer to alloc chan.

some platform's dependent is simple, which may just use MMIO to gate clock.

Frank
>
> --
> Thank you,
> Claudiu
>