0

I try to implement a low power "deep sleep" functionality into uboot on button press. Button press is handled by linux and a magic code is set to make u-boot aware of the stay asleep do not reboot"

    printf ("\nDisable interrupts to restore them later\n");
    rupts = disable_interrupts();
    printf ("\nEnable interrupts to enable magic wakeup later\n");
    enable_interrupts();
    printf ("\nSuspending. Press button to restart\n");

    while(probe_button()/*gpio probe*/){
#if 1
            //FIXME recheck if that one actually needs an unmasked interrupt or any is ok
            __asm__ __volatile__(
                            "mcr p15, 0, %0, c7, c0, 4\n" /* read cp15 */
                            "mov %0, %0"
                            : "=r" (tmp)
                            :
                            : "memory"
            );
#else
            udelay (10000);
#endif
    }
    if (rupts) {
            printf ("\nRe-Enabling interrupts\n");
            enable_interrupts();
    }

Unfortunatly the power dissipation does not change at all (got power dissipation measurment tied to the chip), no matter if hotspinning is used or not. Beyond that, if I use the Wait-For-Interrupt CP15 instruction, it never wakes up. The button is attached to one of the GPIOs. The plattform is Marvell Kirkwood ARM9EJ-S based.

I enabled some CONFIG_IRQ_* manually, and create implementation for arch_init_irq() aswell as do_irq(), I think there is my issue.

According to the CP15 instruction docs it should be just enough that a interrupt gets triggered (no matter if masked or not!).

Can anyone tell me what I am doing wrong or what needs to be done beyond the code above?

Thanks a lot in advance!

drahnr
  • 6,782
  • 5
  • 48
  • 75
  • I think this kind of question is too specific because it's lot of low level HW stuff and limited to a specific processor brand – Alvin Wong Oct 17 '12 at 15:24
  • Inline assembly doesn't look right. ("MOV R0, #0\n MCR p15, 0, r0, c7, c0, 4" : : : "r0") – auselen Oct 17 '12 at 16:14
  • @AlvinWong after all it's worth a try - there are a bunch of kirkwood based devices out there and have a high "hackiness" value (guruplug, sheeva, ..) Also the instruction is still used in the latest Cortex A chips to put the core to rest (after all ARM has pretty good backwards compatibility) – drahnr Oct 17 '12 at 18:18
  • @auselen I do not see much of a difference. I just tell gcc via "memory" that registers may get clobbered, allow gcc to choose the register for tmp as gcc likes. I do not see much of a difference, beyond that your inline does constraint that to r0. Correct me if I am wrong or if I missed something. – drahnr Oct 17 '12 at 19:03
  • @AlvinWong WFI is not that low level HW stuff and also not limited to a specific processor brand, idea is supported by several versions of ARM architecture. – auselen Oct 17 '12 at 19:55
  • @drahnr Did you try my suggestion? See my answer below. – auselen Oct 17 '12 at 19:55
  • @auselen I will check that tomorrow morning, thanks a lot for your input! – drahnr Oct 17 '12 at 20:22

1 Answers1

1

I'm not sure if it is the only reason your aproach isn't working on power saving but your inline assembly isn't correct. According to this article you need to execute:

MOV R0, #0
MCR p15, 0, r0, c7, c0, 4

but your inline assembly

        __asm__ __volatile__(
                        "mcr p15, 0, %0, c7, c0, 4\n" /* read cp15 */
                        "mov %0, %0"
                        : "=r" (tmp)
                        :
                        : "memory"
        );

produces

   0:   ee073f90    mcr 15, 0, r3, cr7, cr0, {4}
   4:   e1a03003    mov r3, r3
   8:   e12fff1e    bx  lr

I am not sure what's your intent but mov r3, r3 doesn'ẗ have any effect. So you are making coprocessor call with a random value. You also need to set r3 (ARM source register for mcr) before mcr call. Btw when you put 'memory' in clobber list it means

... will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory.

Try this line,

asm("MOV R0, #0\n MCR p15, 0, r0, c7, c0, 4" : : : "r0");

it produces

   c:   e3a00000    mov r0, #0  ; 0x0
  10:   ee070f90    mcr 15, 0, r0, cr7, cr0, {4}

For power saving in general, I would recommend this article at ARM's web site.

Bonus section:
A small answer to your claim on backward compability of this coprocessor supplied WFI:

ARMv7 processors (including Cortex-A8, Cortex-A9, Cortex-R4 and Cortex-M3) all implement the WFI instruction to enter "wait for interrupt" mode. On these processors, the coprocessor write used on earlier processors will always execute as a NOP. It is therefore possible to write code that will work across ARMv6K, ARMv6T2 and all profiles of ARMv7 by executing both the MCR and WFI instruction, though on ARM11MPCore this will cause "wait for interrupt" mode to be entered twice. To write fully portable code that enters "wait for interrupt" mode, the CPUID register must be read at runtime to determine whether "wait for interrupt" is available and the instruction needed to enter it.

auselen
  • 27,577
  • 7
  • 73
  • 114
  • Not the solution, but I guess that's the best that can be squeezed of my question. The current suspect is the interrupt configuratian (which is really wierd if VIC is not used, actually you have to deactive IRQ's by setting cspr_c accordingly) – drahnr Oct 18 '12 at 16:30