On 24-09-26, 15:26, Ulf Hansson wrote: > On Mon, Sep 21, 2026 at 12:49 AM Linus Walleij <[email protected]> wrote: > > > > Replace the LCLA ESRAM regulator with runtime PM. > > > > Use the SRAM device that owns the ESRAM34 power domain. > > > > 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.
That is a consequence of dmaengine work running in tasklet and thus softirq mode. The dmaengine tasks need to run with a higher priority to enable higher dmaengine throughput. We have plans to move to WQ_BH [1], but I think that runs in softirq mode as well... [1]: [email protected] -- ~Vinod
