Messages in this thread | | | Subject | Re: [RFC PATCH 0/0 v3] callchain fixes and cleanups | From | Will Deacon <> | Date | Wed, 18 Aug 2010 10:08:47 +0100 |
| |
On Wed, 2010-08-18 at 04:55 +0100, Frederic Weisbecker wrote: > On Tue, Aug 17, 2010 at 11:32:39AM +0100, Will Deacon wrote: > > I've tested this on an ARM Cortex-A9 board and it all seems fine [plus > > the code is a lot cleaner!]. > > > > Tested-by: Will Deacon <will.deacon@arm.com> > > Thanks a lot!
> BTW, out of curiosity, do you have NMIs on ARM and do the hardware events > make use of them? Or may be you use FIQ to simulate NMIs? >
We don't have NMIs on ARM [so obviously we can't use them!] but you're right to point out the FIQ. I've actually been thinking about this during the past week, but there are the following problems:
(1) The FIQ isn't always wired up in the hardware, so you can't assume that it is available.
(2) The FIQ can only have a single handler at a given time. This is because it is a separate exception mode, with its own banked registers. Consequently, we might not be able to use it if it's being used for something else.
(3) The Trustzone security extensions may reserve the FIQ for secure use only or make it available only via the secure monitor [which will increase latency].
Of course, the advantage is that we could then use sample-based profiling techniques in sections of code where the interrupts are disabled.
The only way I can think of adding this is as a Kconfig option, which, when selected, tries to use the FIQ and then falls back to normal IRQs if it fails.
Cheers,
Will
| |