Re: profiling the resume path
On Sun, Sep 02, 2007 at 01:03:12PM -0400, Marcelo Tosatti wrote: On Sun, Sep 02, 2007 at 12:50:03PM +0100, David Woodhouse wrote: On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote: Note: ohci_pci_resume does msleep 20. Hm. It's just waiting for the hardware to settle, right? Do the resume functions for the devices themselves actually have to wait until this is complete, before they can do anything? It really sounds like we need to decouple suspend/resume of individual hardware devices from the full system suspend. It should be almost completely asynchronous. Why can't I start running userspace after resume, before I've reinitialised the USB thermometer which is plugged in? Why don't we just block access to that particular device until it's complete (and take that device off-line to save power even when the full system isn't suspended). You're entirely right, but I'm talking about something else: [0.040909] cpu_idle+0x2e/0x7c - check_pgt_cache+0xb/0x31 [0.00] check_pgt_cache+0x2f/0x31 - quicklist_trim+0xe/0xe5 [0.040912] cpu_idle+0x4e/0x7c - default_idle+0x8/0x43 [0.233593] do_IRQ+0x45/0xdb - irq_enter+0xb/0x2d [0.233594] irq_enter+0x22/0x2d - idle_cpu+0x8/0x1b This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ... after 20ms have passed, not almost 200. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote: This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ... after 20ms have passed, not almost 200. Ah, right. Sorry, I missed the order of magnitude discrepancy. Are we just miscalculating the setting of the wakeup interrupt? More debugging of that calculation might be in order... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Mon, 2007-09-03 at 09:27 +0100, David Woodhouse wrote: On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote: This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ... after 20ms have passed, not almost 200. Ah, right. Sorry, I missed the order of magnitude discrepancy. Are we just miscalculating the setting of the wakeup interrupt? More debugging of that calculation might be in order... Can you comment out the 'if(tbase_get_deferrable(nte-base)) continue;' in __next_timer_interrupt() at about line 678 of kernel/timer.c ? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
headtracker / mag lens / macro lens
Hello, am searching for a cheap mag lens to improve the resolution of the headtracker. http://www.olpcaustria.org/mediawiki/index.php/Headtracker What I have found is a very cheap macro lens. I took it from a one-way-camera and put it directly in front of the web cam lens. The difference is obvious. But I did not find a magnification lens, yet. http://www.olpcaustria.org/mediawiki/index.php/Headtracker#magnification_lens By the way, how could I make high resolution / less compressed pictures and videos with the XO? regards, yokoy ps: sorry for cross posting ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
