"Nori, Sekhar" <nsek...@ti.com> writes: > On Fri, Mar 12, 2010 at 23:33:10, Kevin Hilman wrote: >> Sekhar Nori <nsek...@ti.com> writes: >> >> > From: Anuj Aggarwal <anuj.aggar...@ti.com> >> > >> > Currently, the ISR in the EDMA driver clears the pending interrupt for all >> > channels without regard to whether that channel has a registered callback >> > or not. >> > >> > This causes problems for devices like DM355/DM365 where the multimedia >> > accelerator uses EDMA by polling on the interrupt pending bits of some of >> > the >> > EDMA channels. Since these channels are actually allocated through the >> > Linux >> > EDMA driver (by an out-of-kernel module), the same shadow region is used by >> > Linux and accelerator. There a race between the Linux ISR and the polling >> > code >> > running on the accelerator on the IPR (interrupt pending register). >> > >> > This patch fixes the issue by making the ISR clear the interrupts only for >> > those channels which have interrupt enabled. The channels which are >> > allocated >> > for the purpose of being polled on by the accelerator will not have a >> > callback >> > function provided and so will not have IER (interrupt enable register) >> > bits set. >> >> Dumb question: why cat the MM accelerator use the normal ISR + callback? > > There is some OS-less code running on the accelerator. I believe > (at least some parts of) the accelerator cannot even see the DDR > so having an OS implemented there seems far fetched. Without an > OS in place, it is easier to poll on EDMA IPR bits. > > Having Linux handle the interrupt brings in IPC mechanisms which > again needs an OS running on the other side and is also seen as > detrimental to performance.
OK, thanks for the clarification. applying, and queueing in davinci-next for 2.6.35 Kevin _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
