[PATCH v2] i.MX31 and i.MX35 : fix errate TLSbo65953 and ENGcm09472

[Nicolas Pitre]

On Tue, 5 Oct 2010, Eric Bénard wrote:

> Hi Uwe,
> 
> Le 05/10/2010 22:04, Uwe Kleine-König a écrit :
> > > That may seems bad, but I find this solution better than having an oops
> > > after a few IRQs which makes the CPU unusable for real life applications
> > > :-)
> > Ack, but it makes me think if the caches should be enabled in the irq
> > entry point, too.
> 
> If I understand well the following link, you are right.
> 
> Adding checks to enable cache at the IRQ entry point will execute aditional
> code at each interrupt which may have more cost than executing one ISR after
> WFI without cache (I may be totally wrong here).
> 
> More details here (click c7, Cache Operations Register > The Wait For
> Interrupt operation in the left menu) :
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211h/I1014942.html
> 
> which says :
> 
> MCR p15,0,<Rd>,c7,c0,4               ; Wait For Interrupt
> 
> This puts the processor into a low-power state and stops it executing
> following instructions until an interrupt, an imprecise external abort, or a
> debug request occurs, regardless of whether the interrupts or external
> imprecise aborts are disabled by the masks in the CPSR. When an interrupt does
> occur, the MCR instruction completes. If interrupts are enabled, the IRQ or
> FIQ handler is entered as normal. The return link in r14_irq or r14_fiq
> contains the address of the MCR instruction plus 8, so that the normal
> instruction used for interrupt return (SUBS PC,R14,#4) returns to the
> instruction following the MCR.

Note that, on Linux, the WFI instruction is always executed with IRQs 
off.  So you just have to turn on the cache right after the MCR before 
returning.


Nicolas