* Kevin Hilman <[email protected]> [100503 10:00]: > Tony Lindgren <[email protected]> writes: > > > * Kevin Hilman <[email protected]> [100503 08:58]: > >> Mika Westerberg <[email protected]> writes: > >> > >> > If we are softbooting another kernel using kexec, DMA controller state > >> > is not > >> > known when we are performing omap_init_dma(). It is possible that some > >> > DMA > >> > channels are already active. For example after kexec we get: > >> > > >> > <4>IRQ 0020 for non-allocated DMAchannel 5 > >> > <4>IRQ 0020 for non-allocated DMAchannel 5 > >> > <4>IRQ 0020 for non-allocated DMAchannel 5 > >> > <4>IRQ 0020 for non-allocated DMAchannel 5 > >> > <4>IRQ 0020 for non-allocated DMAchannel 5 > >> > > >> > To prevent any weird things happening, we perform soft reset for the > >> > controller > >> > and disable all per channel interrupts. > >> > > >> > Signed-off-by: Mika Westerberg <[email protected]> > >> > >> This is a good fix, but we get reset of DMA (and all other blocks) for > >> free when switching to hwmod. Here's a good reason to convert DMA > >> to hwmod. > > > > Hmm, do we have existing DMA hwmod patches somewhere that work on all omaps? > > No, that's my point. > > Rather than implement reset here (then remove it with DMA hwmods) I'd > rather just see a DMA hwmods added, and then we get reset for free.
Sure. But until we have something available we should get the fix part in. AFAIK just disabling the channel interrupt in omap_clear_dma() should do the trick, see my other reply. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
