On 10/25/2010 7:36 AM, Thomas Renninger wrote:
I know that your new API tries to use "0" as exit, but 0 is already
taken (in all power terminology at least on x86 it is) for this.
cpuidle indeed misuses C0 as "poll idle" state.
That's really bad/misleading, but nothing that can be changed easily.
I agree shifting C0 (cpuidle)<-> POLL_IDLE event
and "not idle"<-> real C0 (executing instructions)
or however this gets mapped makes things even worse.
Damn, it could be that easy and straight forward, but I agree that
this kills the approach to trigger state 0 event if C0 is entered
(C0 as defined as operational mode executing instructions).
ok so we have
"C0 idle"
and
"C0 no longer idle"
I'd propose using the number 0 for the first one (it makes the most
logical sense, it's the least deep idle state etc etc)
we could use "-1" or "INT_MAX" for the later
but as a user of the API I rather like a separate "we're no longer idle"
event... but if not, as long as things aren't ambigious I'll find a way
to code around it.
basically with a separate event, I demultiplex based on event number
between entry and exit.... with a special exit value I would just need a
double demultiplex,
one on "idle" and then a second one on the state number to split between
entry/exit.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
