On Mon, Nov 2, 2026 at 11:12 PM Linus Walleij <[email protected]> wrote: > > On Thu, Sep 24, 2026 at 3:27 PM Ulf Hansson > <[email protected]> wrote: > > > > 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.
Okay, so it seems like it may be better to revisit this later on then. No objections from my side! > > 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. Yeah, that could be a good candidate for doing this. Let's see if someone get to that then. :-) > > I don't see much generalizable stuff apart from things like the > pd-patch to the SRAM driver being pretty generic. > > Yours, > Linus Walleij Kind regards Uffe
