On Thu, Sep 24, 2026 at 3:27 PM Ulf Hansson
[off-list ref] wrote:
quoted
Hold that domain while DMA transfers are active. The DMA controller is
runtime PM IRQ-safe, so keep taking explicit LCLA runtime PM references
from the descriptor preparation path instead of relying on a runtime PM
device link from the atomic transfer path.
A bit of an orthogonal problem, but related to the above. The irqsafe
thing have been discussed in the past for DMA controller drivers.
Would it possible to get rid of the irqsafe configuration for the dma
controller device, altogether?
I don't recall exactly, but not the entire consumer DMA API is allowed
to be called in atomic context, but perhaps that is not sufficient to
allow us to drop the irqsafe configuration for the DMA controller
device?
If not, I wonder if the consumer of the DMA (like an mmc controller)
should be assigned as a consumer device (using device links and
DL_FLAG_PM_RUNTIME) of the DMA controller device. In this way, the
consumer (mmc) would be able to control the supplier (DMA) through the
device link directly using runtime PM. This could potentially avoid
the requirement of having to use irqsafe for the DMA controller
device. Maybe someone already tried this?
If the irqsafe configuration can be dropped, in some way or the other,
this patch could become less intrusive, as all that would be needed is
to create a device link to sram device using DL_FLAG_PM_RUNTIME.
I looked at it a bit, talked to the AI prompt a bit, thought about it from
my (limited) understanding and while it seems possible it will need a
substantial amount of work, so I think it's best to get this powerdomain
migration in place first.
Steps to actually go there would include getting proper consumer links
in place and verified, remove all atomic resume runpaths in the
DMAengine, handle requests without a device such as memcpy (I guess
by simply using the DMA device itself as device link?) and some minor
refactorings of lifetime for channel setup/teardown.
But indeed we could use the pretty well documented and supported
U8500 platform as a canary, I think you have access to this platform
too, the upside is that it is "simple" compared to some recent SoC
monsters so it could be an example of how to do stuff.
I don't see much generalizable stuff apart from things like the
pd-patch to the SRAM driver being pretty generic.
Yours,
Linus Walleij