Allan Larsen wrote:
Have you found out whether it is possible to use the OMAP method on
Davinci?
Not practically yet. But by reading the various manuals and knowing
how it works on OMAP1, I assume that statement below (sprue14a section
8.4.1, page 92) is at least incomplete. As I understand it, it is
correct, but covers only situations where ARM core interrupt enable
bits I & F are enabled (enabled == I & F bit are set so that
interrupts are _enabled_). But I think it doesn't cover situations
where I & F bits are disabled (disabled == I & F bit are set so that
ARM core interrupts are _disabled_).
But I don't want to blame TI for this, cause some ARM manuals are not
always clear about this as well.
E.g.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0151c/Cheijjbb.html
states:
-- cut --
When the interrupt occurs the MCR instruction completes and the FIQ or
IRQ handler is entered as normal. The return link in R14_fiq or
R14_irq contains the address of the MCR instruction plus 8, so that
the normal instruction used for interrupt return returns to the
instruction following the MCR
-- cut --
Same what sprue14a tells us, but no info what happens if FIQ and IRQ
are disabled.
But e.g.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0311d/I1014521.html
has a nice note:
-- cut --
Asserting nIRQ or nFIQ wakes the processor from wait-for-interrupt
state even if the I or F interrupt *disable* bit is set in the CPSR.
If interrupts are enabled, the ARM968E-S processor is guaranteed to
take the interrupt before executing the next instruction after the
wait-for-interrupt instruction.
-- cut --
This is a better and more complete description, isn't it?
So I think all ARMs wake from WFI even if I and F interrupt *disable*
bits are set.
If so, do you know of any code that has been written/ported to
Davinci?
No, but the WFI itself should be quite easy. It becomes harder if you
want to put SDRAM into self refresh and have WFI in SRAM/TCM. Maybe
OMAP can help:
http://source.mvista.com/git/?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap1/sleep.S;h=abef33d10f016815a0c67205a8c99f83fa08f91d;hb=HEAD
http://source.mvista.com/git/?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap1/pm.c;h=10aa87266fc592218215e14e8e09a7266c38a94e;hb=HEAD
DaVinci should be a little bit easier because less complex hardware
sleep logic I think.
Best regards
Dirk
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dirk Behme
Sent: 12. november 2007 20:37
To: [email protected]
Subject: DaVinci ARM wake from WFI mode?
I read a little about sleep/wakeup of DaVinci ARM part and compared it
with what I know from OMAP.
Now I wonder if DaVinci ARM can exit ARM wake-for-interrupt mode (WFI)
if ARM I- and F-IRQs are disabled?
sprue14a [1] states (section 8.4.1, page 92):
-- cut --
The following sequence describes the procedure to wake up from the
wait-for-interrupt mode:
- To wake up from the wait-for-interrupt mode, trigger any enabled
interrupt (for example, an external interrupt).
- The ARM's PC jumps to the IRQ vector and you must handle the
interrupt in an interrupt service routine (ISR).
Exit the ISR and continue normal program execution starting from the
instruction immediately following the instruction that enabled
wait-for-interrupt mode: mcr p15, #0, r3, c7, c0, #4.
-- cut --
Assuming that SDRAM is in self refresh mode and therefore WFI
enter/exit code is in internal (TCM) SRAM, ISR has to be in SRAM as
well? This implies that
- ARMs IRQ entry has to be mapped by MMU from standard Linux location
to SRAM
- All MMU translation for ARMs IRQ/ISR to internal SRAM has to be in
TLB cause MMU tables in SDRAM are not accessible
- ISR can't really handle data cause all (Linux-) data handling code
is located in SDRAM (still in self refresh). It has to be a "minimal"
ISR, main job is to wake the system and not to handle data.
What I know from OMAP is that ARM is able to exit WFI with ARM I- and
F-IRQ *disabled* (local_irq_disable() & local_fiq_disable()). On OMAP,
while going to sleep, still running from SDRAM, you configure some
interrupts as wake sources and then disable ARM I- and F-IRQ. Then you
jump to SRAM, enable SDRAM self refresh and go to WFI. Then, ARM can
still wake from interrupt, but *doesn't* jump to ISR immediately cause
I- and F-IRQ are still off. Enabling SDRAM, jumping back to SDRAM,
enabling ARMs I- and F-IRQ and *then* system jump and use normal Linux
ISRs for wake interrupt.
This is quite elegant and avoids complex programming steps like above
necessary on DaVinci? Or did I miss anything here?
Best regards
Dirk
[1]
http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=4
09&familyId=1302&abstractName=sprue14a
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
