Hi:     I have the same problem. There seems to be lot of information on the olpc website but not easy to get to without spending time searching for it. After a lot of searching and forgetting to bookmark and researching, I decided to add the links of interest to me in my blog:

<a href="http://tags07.blogspot.com/2007/03/olpc-links.html">http://tags07.blogspot.com/2007/03/olpc-links.html</a> Feel free to refer to it.   On a different note, I'd like to work on PM user interface and perhaps also on the kernel side.

I havn't dived into the hardware specs yet for OLPC. It would be nice to have a wiki page with some basics to help ramp up the learning curve. Some qns I have: 1. Does the hardware support Voltage/Frequency scaling?

2. What kind of sleep modes does it support? 3. Is there an infrastructure for power measurements? Do we have any current drain measurements/readings? 4. Where are you experiencing the instability..is it at the hardware layer or the syspend-resume mechanism?

5. Recently we did a lot of cleanup in the kernel to short-circuit the default pm_suspend process, which has unnecessary layers that trumps the suspends... the biggest one that comes to my mind is the dealing with UNINTERRUPTIBLE SLEEP processes. I am not sure if you are experiencing similar issues?

<br>6. Is there a need for periodic wakeup? on mobile devices its required to wakeup almost every minute to update clock display, battery level, rf <a href="http://levels.it">levels.it</a> makes sense to sync up all these activities during the wakeup 

period.I am not sure if a laptop has such a requirement.. 7. Usually display/backlight is the biggest sucker of power.. do we use any special displays that support partial refresh? 8. Suspend to RAM is good..it will give an "Instant-On" experience..is this in the main kernel now or does it need special patches? If so where can i find these patches?

<br><br>I'd also like to discuss user interface APIs and useful features for a power controller module in userspace. But i understand a stable suspend and resume of devices should be the priority.<br><br><br>thanks,<br>

Gopi<br><br><br><br><br><br><br><br><div><span class="gmail_quote">On 3/28/07, <b class="gmail_sendername">Jordan Crouse</b> <<a href="mailto:jordan.crouse@amd.com">jordan.crouse@amd.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On 28/03/07 19:42 +0200, Jens Axboe wrote: > Hi, > > I'd love to help out with the power management and suspend/resume parts, > but so far I'm having trouble finding out what the status of it is,

<br>> goals, directions, etc. Did I miss a wiki page on this? If not, anyone<br>> care to outline the current problems that need tackling?<br><br>Once we get the core drivers working happily (graphics, DCON, USB, and

<br>CaFE NAND), then we'll be ready to be more organized with wiki pages, and<br>images and such.  Following working core drivers, our emphasis will shift<br>to the fringe drivers.<br><br>My personal target is to survive 1000 consecutive suspend/resume cycles

<br>with a full system running a nominal load (sugar, nominal<br>CPU load + network).  If we accomplish that, then I think we'll be ready for<br>anything they throw at us.<br><br>After that we'll shift our attention to optimization, but I would

<br>like to stress that at this point, stability trumps speed any day of the<br>week and twice on Sunday.<br><br>Jordan<br><br>--<br>Jordan Crouse<br>Senior Linux Engineer<br>Advanced Micro Devices, Inc.<br><<a href="http://www.amd.com/embeddedprocessors">

www.amd.com/embeddedprocessors</a>><br><br><br>_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@laptop.org">Devel@laptop.org</a><br><a href="http://mailman.laptop.org/mailman/listinfo/devel">

http://mailman.laptop.org/mailman/listinfo/devel</a><br></blockquote></div><br>