Re: cafe_ccic slowness in VIDIOC_S_FMT
Dan Williams [EMAIL PROTECTED] wrote: So here you see that calling VIDIOC_S_FMT takes 3655992 microseconds, which is a _really_ long time. Turns out that cafe_cam_configure() from s_fmt_cap() takes 378 jiffies. Trying to make this better was already on my list. The problem is that the Cafe i2c has to be treated *really* gently or you start getting those nifty write timed out problems. But there is almost certainly room for improvement, it's just a matter of working out what the minimum delays are. I'll try to get to it once I'm back home. jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Shutdown after resume using power button
Jordan Crouse wrote: Jordan, I remember you mentioned that reading PM1_STS might be unreliable... Can you shed more light into the issue? Hmm - I don't remember that. PM1_STS should be reliable at this point, assuming nobody has touched it since we resumed. I think there is a problem with bit 0 of PM_SSC. Perhaps that is what Marcelo is remembering. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: RSS feed for several git modules not working
Hi, Hello, looks like the RSS feed for several git modules on dev.laptop.org is not working. For example: http://dev.laptop.org/git?p=sugar;a=rss http://dev.laptop.org/git?p=artwork;a=rss Any idea? Trying to run git-instaweb on my local clone of sugar seem to work fine. I have 1.5.2.2 installed. Looks like the new version of gitweb isn't handling Unicode correctly: Cannot decode string with wide characters at /usr/lib/perl/5.8/Encode.pm line 166. (And those two modules have Ivan's name, containing Unicode, as the owner.) - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: RSS feed for several git modules not working
On Jul 8, 2007, at 3:41 PM, Chris Ball wrote: (And those two modules have Ivan's name, containing Unicode, as the owner.) Changed to marco so it works for now, but we should try and get the unicode thing resolved. Does someone know if there's a quick fix, and if not, whether there's a newer version of gitweb that resolves this? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Hibernate after alarm wakes from STR
On Sun, Jul 08, 2007 at 01:15:40PM -0700, David Brownell wrote: On Sunday 08 July 2007, Richard Hughes wrote: On Sun, 2007-07-08 at 12:17 -0700, David Brownell wrote: I think so ... although that's unfortunately another difference between the legacy x86-mostly code and the newer RTC framework. (sorry for hijacking the thread) I changed $SUBJECT ... Is this the interface should stuff like HAL use to do: * Suspend for 10 minutes * auto wakeup and then hibernate... That is, Suspend-to-RAM or standby? Yes, assuming that works on this particular system. Arguably that would be a direction for cpuidle to think about too, but I think alarm-driven wakeup is more ready-to-use at this point. I figure we can do a suspend setting the rtc using the ioctls and then we wakeup, and HAL has to know that we woke up from the alarm rather than from a lid event or keypress. On OLPC hibernate would be suspend-to-disk, but we haven't done any testing with that yet. It would be necessary to check for available disk space before attempting it (or reserving space perhaps?). ... although I don't know whether that particular distinction is made to userspace right now. ACPI provides a bit like that, and at least a few other systems can do something analagous. Yes, we can poke at registers to find that out. That is, we may want to provide a bit more information about the specific event which triggered wakeup. I don't believe there is such an interface, in general. What would be a nice interface? Perhaps an additional file under /sys/devices/.../power/wakeup_fired or something (only for devices with can_wakeup set). Plus, the notion seems kind of racey to me. (If you press a key right while the wakealarm fires, you don't want hibernation..) Then you check if the any key or other wakeup event has happened other than RTC... I don't see any problem with that. Is this something we can do (or should do) for OLPC and general ACPI? I'd certainly rather see laptops doing that than what they do now: running the battery out, and needing filesystem recovery!! Yep. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend-to-disk
Andres Salomon wrote: ... Implementation questions: I'm not going to concern myself with our B1s, for they have more ram and less nand. Our B2s have 128MB of ram, and 512MB of nand; B3s and up have 256MB of ram, and 1GB of nand. We need to figure out just how much space we'd need to set aside in a snapshot partition for STD. I'm not sure what would be required from the OFW side; Mitch? First-order swag: You need 256MB of disk to store 256MB of RAM, in the nothing-fancy scenario. Second-order swag: Machine code compresses about 2:1 with gzip, so if the memory were full of code, you would need about 128MB of disk for 256 MB of RAM. OFW already includes a gunzip-compatible decompressor which is reasonably fast (written in C, runs from cached memory). It would be easy enough to add either LZMA , LZO, or QuickLZ. It's likely that we could overlap the compression/decompression with NAND access, so the speed penalty would be minimal. Third-order swag: The memory is likely to be significantly more compressible than random machine code, due to the likely prevalence of sparsely-encoded data. So maybe the average compression in practice would be 3:1 or 4:1 or even better. But we would might need to allocate space for the worst case. Fourth-order swag: It wouldn't be necessary to save read-only code (text pages) to the save area; just mark those pages not present and save the information necessary to page them back in. But that would probably make the resume slower, because of the JFFS2 operations necessary to resolve all those page-in references. The firmware part of the resume would be faster, but the overall suspend/resume process might take longer (or maybe not; you trade not having to write the data out on the way down for having to do more work on the way up). The firmware part of this shouldn't be particularly difficult if we can make the save format reasonably straighforward. It could get more difficult if we run into enough examples of somebody has already done this so we have to use their existing solution even though it is massive overkill for our situation. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: suspend-to-disk
In any analysis, please don't bother with the B1 and B2 configurations as those platform profiles will not be an option in the production machines. -walter On 7/8/07, Mitch Bradley [EMAIL PROTECTED] wrote: Andres Salomon wrote: ... Implementation questions: I'm not going to concern myself with our B1s, for they have more ram and less nand. Our B2s have 128MB of ram, and 512MB of nand; B3s and up have 256MB of ram, and 1GB of nand. We need to figure out just how much space we'd need to set aside in a snapshot partition for STD. I'm not sure what would be required from the OFW side; Mitch? First-order swag: You need 256MB of disk to store 256MB of RAM, in the nothing-fancy scenario. Second-order swag: Machine code compresses about 2:1 with gzip, so if the memory were full of code, you would need about 128MB of disk for 256 MB of RAM. OFW already includes a gunzip-compatible decompressor which is reasonably fast (written in C, runs from cached memory). It would be easy enough to add either LZMA , LZO, or QuickLZ. It's likely that we could overlap the compression/decompression with NAND access, so the speed penalty would be minimal. Third-order swag: The memory is likely to be significantly more compressible than random machine code, due to the likely prevalence of sparsely-encoded data. So maybe the average compression in practice would be 3:1 or 4:1 or even better. But we would might need to allocate space for the worst case. Fourth-order swag: It wouldn't be necessary to save read-only code (text pages) to the save area; just mark those pages not present and save the information necessary to page them back in. But that would probably make the resume slower, because of the JFFS2 operations necessary to resolve all those page-in references. The firmware part of the resume would be faster, but the overall suspend/resume process might take longer (or maybe not; you trade not having to write the data out on the way down for having to do more work on the way up). The firmware part of this shouldn't be particularly difficult if we can make the save format reasonably straighforward. It could get more difficult if we run into enough examples of somebody has already done this so we have to use their existing solution even though it is massive overkill for our situation. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
