Sleep/Suspend/Power Off on i.MX53 Kernel 3.0.15

[gruger]

Dear community,

We are using Android 4.0.4 ICS BSP from Symbio (a Freescale partner) which runs Kernel 3.0.15 on a custom i.MX53 board. This board uses Freescale MC34708 PMIC.

As Kernel 3.0.15 does not support QSB-R, we do not have any reference code for developing the following features:

• Android Power Off
• Android Suspend
• Android Resume from Suspend (a signal is sent to PWRON1 pin from MC34708 PMIC when device needs to wake up).

Can anyone help us with source code for our board? Currently, our board is not resuming from suspend mode and is not powering off. Also, there are several tasks we need to implement before suspending, such as turning off some power supplies.

Any help would be much appreciate.

Best regards,

Mauricio

[fabio_estevam]

Also, you stated that 3.0.15 does not support mx53qsb with mc34708 PMIC, but I can see that this is supported in the 3.0.15 FSL branch:

linux-2.6-imx.git - Freescale i.MX Linux Tree

Also, the explanation I gave assumes you are using a GPIO connected from mx53 to a button only, but it seems from your first message that it is connected to the PMIC, so I am a bit confused as to what is exactly the wakeup source that you want to implement.

Regards,

Fabio Estevam

[gruger]

Hi Fabio,

I have connected a button to another GPIO and I am using the GPIO-keys as you mentioned above. Unfortunately, it is still unable to wakeup the system. I can see input events from the kernel log while system is awake, but when it goes to sleep, it is still unable to wakeup.

[fabio_estevam]

Ok, so evtest can report the events on this button, right? Have you passed the .wakeup field?

I would suggest building a kernel without mc34708 support and then do:

echo mem > /sys/power/state

Press the button and it should wake.

Regards,

Fabio Estevam

[gruger]

Hi Fabio,

Evtest can report events on this button and I have passed the .wakeup field accordingly to your previous instructions:

static struct gpio_keys_button indash_gpio_buttons[] = {

    {

        .gpio        = MX53_INDASH_GPIO6,

        .code        = KEY_POWER,            // To wakeup the system...

        .desc        = "WAKEUP",

        .active_low    = 1,

        .wakeup        = 1,

        .debounce_interval = 30,

    },

};

static const struct gpio_keys_platform_data    indash_button_data __initconst = {

    .buttons    = indash_gpio_buttons,

    .nbuttons    = ARRAY_SIZE(indash_gpio_buttons),

};

static struct platform_device indash_button_device = {

    .name           = "gpio-keys",

    .id             = -1,

    .num_resources  = 0,

    .dev            = {

        .platform_data = &indash_button_data,

        }

};

Unfortunately, this button is still unable to wakeup the system after I run "echo mem > /sys/power/state".

There must be something related to the IRQ handling... All IRQs seems to be disabled at sleep mode.. I have tried to configure TZIC register accordingly to another thread like this:

static void indash_mc34708_irq_wakeup_only_fixup(void)

{

    void __iomem *tzic_base;

    tzic_base = ioremap(MX53_TZIC_BASE_ADDR, SZ_4K);

    if (NULL == tzic_base) {

        pr_err("TZIC: fail to map MX53_TZIC_BASE_ADDR\n");

           return;

    }

    __raw_writel(0, tzic_base + TZIC_WAKEUP0_OFFSET);

    __raw_writel(0, tzic_base + TZIC_WAKEUP1_OFFSET);

    __raw_writel(0, tzic_base + TZIC_WAKEUP2_OFFSET);

    /* only enable irq wakeup for mc34708 irq */

    __raw_writel(GPIO7_0_11_IRQ_BIT, tzic_base + TZIC_WAKEUP3_OFFSET);

    iounmap(tzic_base);

    pr_info("TZIC: only mc34708 is wakeup-enabled\n");

}

static void indash_suspend_enter(void)

{

    pr_info("indash_suspend_enter:\n");

    indash_mc34708_irq_wakeup_only_fixup();

}

static void indash_suspend_exit(void)

{

    pr_info("indash_suspend_exit:\n");

}

This should have enabled the PMIC IRQ as a wakeup source, but it also did not work.

[fabio_estevam]

I would suggest the following aproach:

Test a minimal kernel (without Android) without mc13708 support. Wakeup from GPIO should work independently from PMIC.

Regards,

Fabio Estevam

[gruger]

Hi Fabio,

I will try this approach, but it will require some time as I need to prepare a u-Boot image and a minimal linux rootfs.

Despite of that, I have got some interesting information about which IRQs are wakeup enabled, after system initialization, by adding some debug logs to the tzic_set_wake_irq function at tzic.c file:

/ # dmesg | grep -i "tzic\|mc34708\|gpio-keys"

[    0.000000] TrustZone Interrupt Controller (TZIC) initialized

[    0.343900] mc34708 irq: 331

[    0.558520] TZIC wake enabled=1 irq=18

[    0.565045] TZIC wake enabled=1 irq=107

[    0.568975] mc_pmic 0-0008: Adding mc34708-regulator subdevice!

[    0.601998] mc_pmic 0-0008: Adding mc34708-rtc subdevice!

[    0.607616] mc_pmic 0-0008: Adding mc34708_ts subdevice!

[    0.613180] mc_pmic 0-0008: Adding mc34708-onkey subdevice!

[    1.493624] TZIC wake enabled=1 irq=14

[    1.828458] input: gpio-keys as /devices/platform/gpio-keys/input/input1

[    1.840217] input: mc34708_ts as /devices/platform/imx-i2c.0/i2c-0/0-0008/mc34708_ts/input/input2

[    1.851587] input: mc34708-onkey as /devices/platform/imx-i2c.0/i2c-0/0-0008/mc34708-onkey/input/input3

[    1.864770] mc34708-onkey mc34708-onkey: mc34708-onkey successfully probed!

[    1.900666] using rtc device, mc34708-rtc, for alarms

[    1.905587] mc34708-rtc mc34708-rtc: rtc core: registered mc34708-rtc as rtc0

[    2.923613] mc34708-rtc mc34708-rtc: setting system clock to 2013-10-08 19:04:01 UTC (1381259041)

Accordingly to attached document, these IRQs are for USB Host (14), USB OTG (18) and GPIO7[0-15] (107), which is the PMIC INT signal. The GPIO-keys IRQ is not wake-up enabled! That must be the reason why we are not being able to wake up the system with the GPIO-key button. None of these IRQs is able to wakeup the device after it goes to sleep. If any of them occurs while system is going to sleep, sleep mode is canceled and the system stays awake. But if the system is already in sleep mode, then none of them is capable of waking system up.

These are the TZIC register values when the system is in sleep mode (I have read them just before system freezes):

[   95.721511] TZIC_ENCLEAR[0]=0x45E40

[   95.725021]      TZIC_ENSET[0]=0x45E40

[   95.728531]  TZIC_WAKEUP[0]=0x44000

[   95.732039] TZIC_ENCLEAR[1]=0xC3FC0090

[   95.735809]      TZIC_ENSET[1]=0xC3FC0090

[   95.739577]  TZIC_WAKEUP[1]=0x0

[   95.742738] TZIC_ENCLEAR[2]=0xD0022D

[   95.746333]      TZIC_ENSET[2]=0xD0022D

[   95.749928]  TZIC_WAKEUP[2]=0x0

[   95.753088] TZIC_ENCLEAR[3]=0x1F80

[   95.756510]      TZIC_ENSET[3]=0x1F80

[   95.759931]  TZIC_WAKEUP[3]=0x800

[   95.767372]   TZIC_INTCNTL=0x10001

As we can see, all interrupts we are interested in are enabled and wakeup-enabled at this time. I do not understand why these interrupts are being ignored by the system.

[YixingKong]

Maurico

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel

free to reply with an update to this discussion.

Thanks,
Yixing

[gruger]

Unfortunately not, Yixing Kong.

After struggling with this issue for months we decided to replace the Freescale's MC34708 PMIC to the DA9053 from Dialog, as the SABRE Tablet IMX53 works fine with this one and our kernel/Android version. Appearently no one has any idea on how to solve this issue properly as I have seen many guys with similar problems in this community and no solution.

Our new hardware shall be ready for evaluation in a couple weeks. If you want to close this topic you may do so, but this has not got a solution.

[gruger]

Hi Fabio, thanks for your support.

I am sorry for the misunderstaning. Kernel 3.0.15 does support PMIC MC34708. When I said it does not support I was talking about sleep/power off modes. There are two functions from Dialog's DA9053 which turn off some power supplies when going to sleep and restore voltages on wakeup. These functions are missing for the MC34708.

I will try your suggestion with GPIO-keys today and will give you feedback soon. In fact, I will do this to check if waking up is working properly at our board. I will connect a button to an unused GPIO and use it to wake up the system. In our final solution, we need to wakeup the system through PMIC's interrupts: RTC and PWRON1 only. Let me explain that a little bit further:

We have a button connected to PWRON1 MC34708 pin. This PMIC's pin generates an interrupt through the PMIC INT signal (GPIO16 at our board, muxed as GPIO(7, 11)). All PMIC's interrupts are generated by this INT signal: touch, ADC, RTC, PWRON1, temperature, among others. In our project, we want the system to wakeup when we have a RTC interrupt (alarm clock) or when our wakeup button is pressed (PWRON1 pin).

Thus, what we need to accomplish is:

1) When going to sleep, disable all PMIC's IRQs, except for RTC and PWRON1

2) Enables only GPIO(7, 11) IRQ at i.MX53 to wake up the system

3) After waked up, restore previous configuration

I have tried to use GPIO(7, 11) as a GPIO-key the way you explained above, but it does not work: GPIO-key fails to probe because GPIO(7, 11)'s IRQ is already being used by PMIC's core driver.

[fabio_estevam]

Hi Mauricio,

In a previous post you said that you would like to be able to wakeup the system via GPIO7_11.

i.mx53 qsb resume from suspend issue

Is this still your goal?

If so, please post your board file, so that we can understand what is preventing the system to wakeup.

Wakeup from GPIO should not depend on any PMIC setup. It is only a matter of properly configuring the IOMUX of the pin, setting it as input and mark it as source of wakeup.

Regards,

Fabio Estevam

[gruger]

Hi Fabio,

First of all, thank you for your reply.

Regarding your question: Yes, we still want to wake up the system through an interrupt request on GPIO7_11 and ONLY on this GPIO.

I am attaching my board file for reference. Thank you!

[fabio_estevam]

Mauricio,

In order to accomplish this, you need to register a gpio_key device.

I took a look at 3.0.15 and we have some imx boards that make use of this. You can reference arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c for example (search for eukrea_mbimxsd_gpio_buttons[] and how this is registered) The key thing here is the .wakeup field, which should be set to 1 to allow the gpio to be a source of wakeup.

If you look at the arch/arm/mach-mx5/mx51_babbage.c file inside the 3.0.15 kernel you will see that they also use a GPIO to wakeup the system, but instead of using the standard gpio_keys API, they used a more another aproach (just look for power_key throughout the source and you will see that they do gpio_request / gpio_direction_input and register the interrupt).

I would recommend the first approach though.

Hope this helps.

Regards,

Fabio Estevam