Subtle interactions in the embedded world - what bugs can teach us [LWN.net]

Subtle interactions in the embedded world - what bugs can teach us

Posted Feb 27, 2012 20:52 UTC (Mon) by geuder (subscriber, #62854)
Parent article: Subtle interactions in the embedded world - what bugs can teach us

Looks like a very interesting article, although at least I cannot get all the details at the first reading.

However, I wonder how the author can just talk about about "suspend"? It's more than 2 years that I was struggling with OMAP3 documenentation, but I vaguely remember that there were 4(?) levels of suspend. Clocks and power are controlled separately. The deeper you suspend the more power you save, however at the price that waking up is more expensive (and maybe some interrupts are completely lost???). On top of that the SoC has numerous clock domains and power domains.

Whether this complexity has its part when some interrupt handling works sometimes but not always or always only once?

to post comments

Subtle interactions in the embedded world - what bugs can teach us

Posted Feb 29, 2012 8:04 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

The various functions in the OMAP3 module do indeed have 4 levels of power management - Active, Idle, Retension, and Off. "Idle" means all clocks have been turned off, I don't really understand exactly what "retention" means. The other two should be self explanatory. As you say, the deeper levels use less power and take longer to wake up from.

The runtime power management - which for the CPU is called 'cpuidle' - attempts to switch to the lowest power state which still meets the current needs.

This is all done quite independently of "suspend".

"suspend" is an OS concept more than a hardware concept - at least it in on ARM. On X86 it is also a firmware concept imposed by the BIOS (once the APM bios, now the ACPI bios).

To Linux "suspend" means:
. - freeze all processes
. - give extra encouragement to devices to go to low power states
. - disable some interrupts

and wait for a non-disabled interrupt.

Some devices don't need extra encouragement, and will always power down as much as possible. Others might only powerdown when they are not in use (i.e. no process has the device file open), and the extra encouragement from suspend powers them down anyway. Others might stay powered on a little bit so they can wake the system up, and this might be configurable.

So when I was talking about "suspend" it was definitely the OS-level concept, not the chip-level concept.

Hope that helps.

Subtle interactions in the embedded world - what bugs can teach us

Posted Feb 29, 2012 18:31 UTC (Wed) by geuder (subscriber, #62854) [Link]

Thanks for your reply.

When reading the article again, I see that you indeed wrote "suspend to RAM".

My fault probably was that when reading an article about a phone and OMAP3 I was implicitly thinking N900. And as far as I know N900 does not use suspend to RAM at all.

So obviously your GTA04 software is more advanced in that respect.

I have no idea what is the state machine of the various OMAP domains with respect to those power management states when you wake up from suspend to RAM. But I'm quite sure that not everything is fully active instantaneously after the first pulse on the interrupt line. Whether the reason for the missed interrupt is buried somewhere there?