On 24-09-26, 15:26, Ulf Hansson wrote:
On Mon, Sep 21, 2026 at 12:49 AM Linus Walleij [off-list ref] wrote:
quoted
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]: cover.1786384168.git.allen.lkml@gmail.com
--
~Vinod