i.MX ProcessorsのトピックRe: Suspend-to-RAM debugging

Suspend-to-RAM debugging

harald_krapfenb — Fri, 06 Jul 2012 06:39:42 GMT

Hello,

I have a custom i.MX53 board where suspend-to-RAM is not working properly, i.e. the board won't wake up; and I believe it crashes even before going to suspend anyway.

Linux Standby mode works and the board wakes up again.

I use 2.6.35, from 11.05 ER Freescale BSP.

Stepping through the assembly code before the WFI instruction is executed within DS-5, I found that the problem is in cpu_do_suspend_workaround(), file arch/arm/mach-mx5/suspend.S.

More detail, the mx53_force_ddr_selfrefresh section goes wrong when the FDVFS bit in M4IF_CR0 register is set.

mx53_force_ddr_selfrefresh:
    PM_SET_ADDR_REG MX53_M4IF_CR0_FDVFS_ADDR, r4
    ldr r5, [r4]
    orr r5, r5 , #0x800
    str r5, [r4]

The processor locks up so I need to power-cycle it; and the debugger disconnects. I believe, sending low-power request to the fast channel of the EXTMC should not influence the JTAG clocks/connection. Who knows better?

Is there an idea by anyone what could go wrong? The manual's information about the FDVFS bit is rather sparse; I don't know what the M4IF does in background before it should acknowledge the low power state.

Thanks!

Re: Suspend-to-RAM debugging

VincentChen — Fri, 06 Jul 2012 07:31:42 GMT

static void loco_suspend_enter(void)
{
   if (!board_is_mx53_loco_mc34708()) {
       loco_da9053_irq_wakeup_only_fixup();
//vin       da9053_suspend_cmd_sw();
       da9053_suspend_cmd_hw(); //vin added 2012/4/11, because we have DA9053 on board

   }
}

int da9052_ldo_buck_set_voltage(struct regulator_dev *rdev,
                   int min_uV, int max_uV)
{
   struct da9052_regulator_priv *priv = rdev_get_drvdata(rdev);
   struct da9052_ssc_msg ssc_msg;
   int id = rdev_get_id(rdev);
   int ret;
   int ldo_volt = 0;

   /* KPIT - Below if condition is there for added setvoltage attribute
   in sysfs */
   if (0 == max_uV)
       max_uV = da9052_regulators[id].reg_const.max_uV;

   ...........
   ...........
   ...........

   switch (id) {
   case DA9052_LDO2:
       ssc_msg.data = (ssc_msg.data | DA9052_SUPPLY_VLDO2GO);
   break;
   case DA9052_LDO3:
       ssc_msg.data = (ssc_msg.data | DA9052_SUPPLY_VLDO3GO);
   break;
   case DA9052_BUCK_CORE:
       ssc_msg.data = (ssc_msg.data | DA9052_SUPPLY_VBCOREGO);
       ssc_msg.data &= 0x7f;//vin 2012/6/21, set the bit 7 to 0.
   break;
   case DA9052_BUCK_PRO:
       ssc_msg.data = (ssc_msg.data | DA9052_SUPPLY_VBPROGO);
   break;
   case DA9052_BUCK_MEM:
       ssc_msg.data = (ssc_msg.data | DA9052_SUPPLY_VBMEMGO);
   break;
   default:
       da9052_unlock(priv->da9052);
       return -EINVAL;
   }

   ............
   ............
   ............

}

Modified the above two functions, it works for me.

Re: Suspend-to-RAM debugging

harald_krapfenb — Fri, 06 Jul 2012 08:07:14 GMT

Up to now, I'm not dealing with the PMIC at all; my board has no DA9053. So this code is not executed.

Involved parts are imho DDR RAM and M4IF.

Re: Suspend-to-RAM debugging

VincentChen — Fri, 06 Jul 2012 08:43:24 GMT

Sorry, I don't know the function of cpu_do_suspend_workaround and can't help you.