Lines Matching full:we
36 1. We return from IRQ handler to a cooperative thread
59 | STATUS32 value, we explicitly save it here for later usage, read-on
70 thread's stack right on top of pre-switch contents so that's what we have:
96 So how do we return in such a complex scenario.
98 First we restore callee-saved regs with help of _load_callee_saved_regs().
99 Now we're back to PRE-CONTEXT-SWITCH STACK (see above).
103 we're still in interrupt handling mode and the only way to return to normal
104 execution mode is to execute "rtie" instruction. And here we need to deal
118 an interrupt, but remember we're returning to the thread which was
121 will happen. So if we do nothing special we'll end-up with that:
142 I.e. we'll go much deeper down the stack over needed return address, read
144 Nobody knows were we end-up then.
146 To work-around that problem we need to mimic existance of IRQ stack frame
147 of which we really only need return address obviously to return where we
148 need to. For that we just shift SP so that it points sizeof(_irq_stack_frame)
174 it makes no difference because we're returning to execution of code as if
175 we're returning from yet another function call and so we will restore
180 CPU hardware automatically save/restore registers in pairs and since we
181 wanted to save/restore R12 in IRQ stack frame as a caller-saved register we
183 a callee-saved register we save/restore it separately in _callee_saved_stack
184 structure. And when we restore callee-saved registers from stack we among
187 if we don't copy correct R13 value to fake IRQ stack frame R13 value