[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: Problem with FIQ on at91rm9200
From:       Matthias Welwarsky <mwelwarsky () web ! de>
Date:       2004-05-18 9:18:14
Message-ID: 200405181118.14231.mwelwarsky () web ! de
[Download RAW message or body]

On Monday 17 May 2004 11:07, Jean-Philippe Francois wrote:
> Hi,
> I already posted something similar a few days ago, but now I have more time
> to investigate about it.
>
> Here is my problem :
> I use the FIQ to emulate a DMA from SDRAM to external chip select 3.
> Since it is used to test a kind of screen driver, this FIQ routine is only
> used image by image, ie send an image, change some parameters, send another
> image etc...
>
> For one image, the external screen controller send FIQ interrupts. The
> duration of this is Tframe, ie there are 160 FIQ spreaded evenly over a
> Tframe period.
>
> The program we use to copy an image in memory and set some parameters also
> runs for a certain period of time. Let's call this Tproc. After this the
> control proc execve some script that relaunch it
>
> When Tproc < Tframe, I sometime get an oops. (see below)
> The only workaround I found is to sleep at the end of my process, to have
> Tproc + Tsleep > Tframe.
>
> What should I do to prevent this ? Did someone already run into similar
> problem ?

I ran into a similar problem once but didn't really find a fix for it. For me 
it was "bad mode in data abort handler". The interesting thing is that the 
CPU is only in ABT_32 for a very short time within the data abort handler, 
just before it switches to SVC_32. So unless you generate a data or prefetch 
abort in ABT_32 its impossible be in a bad mode there.

Aborts have a higher priority than normal IRQs and the CPU disables IRQs when 
executing an abort. So unless you enable IRQs before switching to SVC mode, 
there should be no way for an IRQ to happen while you're in ABT_32.  Unless 
you make an error when restoring the CPSR from the SPSR and restore into 
ABT_32 with interrupts enabled ;-)

But I guess you're not tinkering with the processor modes while executing the 
FIQ.

There's one special thing about FIQ and ABT however: If FIQ and ABT happen "at 
the same time", the CPU first takes the ABT and then the FIQ immediately 
afterwards. So you're then in FIQ mode with the SPSR from ABT. Still, this 
should be absolutely safe unless you make wrong assumptions about SPSR being 
always SVC or USR and restore into the wrong mode.

regards,
	matthias


-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]