Re: [PATCH] OMAP2/3/4: DMA: reset controller during init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tony Lindgren <tony@xxxxxxxxxxx> writes:

> * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [100503 08:58]:
>> Mika Westerberg <ext-mika.1.westerberg@xxxxxxxxx> 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 <ext-mika.1.westerberg@xxxxxxxxx>
>> 
>> 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.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux