Re: XO 1.75 battery life?
On Fri, Dec 2, 2011 at 4:12 PM, Richard A. Smith wrote: > > If you wanted to help and you have a 1.5 you can. People with 1.5s can > provide accurate usage info they install the latest release, make sure the > date is set correctly, and then allow powerd to do ASR (ie don't disable > it). Then use the XO as you normally would but use it on battery as much as > possible. Only charge up the battery when it gets low. Powerd logs are kept > in /home/olpc/power-logs . After a few cycles of the battery send me all > the logs in that directory. Do you really mean XO 1.5 or did you intend to write XO 1.75 in the paragraph above? cjl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH linux] Fix double accelerometer initialisation
I haven't seen it pushed, please do. My test was with a dirty kernel. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO 1.75 battery life?
On 11/29/2011 05:11 AM, Peter Robinson wrote: How's the battery life on the 1.75 going for Read, web browsing& suspend? (3 of the most important functions) Anyone doing tests on these yet? I have begun doing battery life testing. But aggressive suspend/resume is not 100% functional yet (but its very close). Until aggressive suspend resume (ASR) is 100% I can't do a full round of usage mode testing. I do have some data points and I can give you an minimum value. One of the nice things about the 1.75 is that its maximum power draw from the battery is coming in at 5W regardless of how loaded the machine is. This makes a minimum battery life value much easier to predict. The average value of the minimum for battery juice is 18Wh. So 18Wh/5W is 3.6hours. So I feel safe in making the claim that regardless of what you do [1] with a 1.75 you can run for 3.5 hours. That said you have to have a lot of stuff going to keep that at constant 5W. Certainly using Read or browsing the web you won't be at 5W so the battery life will be longer. My existing data points have been collected under the following conditions: - Machine idle at sugar home screen (zero user input) with power management off. - Backlight at our default of 80%. This is of course an artificial test since zero user input is not very useful as a battery life estimate but it allows me to do OS to OS comparisons and represents and upper bound of non-suspend runtime. In that mode we I see abot 2.75W which on the above 18W est is 6.5 hours of runtime. I have run logs that range from 6-7 hours for that test. So I'm expecting to see in-the-wild numbers for people who disable ASR to be in the 4-5 hour range. If you are outside and can turn off the backlight then that lower bound drops to 1.8W. With the backlight off I've got idle runs that show between 8.5-10 hours. Throwing ASR into the works adds a _huge_ dynamic. During ASR our low power drops from 2.75W to about 1.2W and even lower if the backlight has a chance to dim or turn off. So if you can spend a lot of time in this mode then the battery life will increase quite a bit. We don't have any good estimates of how much suspend time you can get out of things like Read or web browsing. Powerd can now collect this sort of info but unfortunately a kernel bug in build 860 prevents the information from being accurate. If you wanted to help and you have a 1.5 you can. People with 1.5s can provide accurate usage info they install the latest release, make sure the date is set correctly, and then allow powerd to do ASR (ie don't disable it). Then use the XO as you normally would but use it on battery as much as possible. Only charge up the battery when it gets low. Powerd logs are kept in /home/olpc/power-logs . After a few cycles of the battery send me all the logs in that directory. [1] There's always a disclaimer. :) Thats without any USB devices plugged in. the USB subsystem can provide up to 5W to an external device. If you were to also draw 5W from USB then the draw would be 10W and your battery life will be much less. In between 1 and 1.5h. (The harder you draw a battery the less capacity it can provide so its not a straight /2) -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
announcing 1.75 firmware Q4C07
http://wiki.laptop.org/go/OLPC_Firmware_q4c07 this is primarily an EC release. it has numerous battery system changes, and it introduces support for preserving the keystroke which causes a system resume, keystroke preservation requires a hardware mod on c1 machines. in principle it should work on b1/b2 machines too (also w/ h/w mod), but my testing today showed it's not quite there. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] 11.3.1 build 11 released for XO-1.75
On Fri, Dec 2, 2011 at 3:49 PM, Frederick Grose wrote: > On Fri, Nov 18, 2011 at 12:55 AM, S Page wrote: > >> >> Sorry to butt in What is the recommended way to identify the >> >> type/model of keyboard/trackpad? >> > >> > Good question. This should be put on a Wiki page. >> >> http://wiki.laptop.org/go/Support_FAQ/Mouse,_Touchpad ? >> >> -- >> =S Page > > > How does one interpret the output? > > # dmesg | grep psmouse > > On my XO-1.75 SN SHC129E > the output is > > [] psmouse serio1: ID: 10 02 64 > > --Fred > > These are the three variations I've seen, there may very well be more: XO 1.5 newer CL1A = serio1: ID: 10 02 64 XO 1.5 older CL1A = synaptics XO 1.0 = 50 > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] 11.3.1 build 11 released for XO-1.75
On Fri, Nov 18, 2011 at 12:55 AM, S Page wrote: > >> Sorry to butt in What is the recommended way to identify the > >> type/model of keyboard/trackpad? > > > > Good question. This should be put on a Wiki page. > > http://wiki.laptop.org/go/Support_FAQ/Mouse,_Touchpad ? > > -- > =S Page How does one interpret the output? # dmesg | grep psmouse On my XO-1.75 SN SHC129E the output is [] psmouse serio1: ID: 10 02 64 --Fred ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH linux] Fix double accelerometer initialisation
Thanks for looking at this. I thought I was seeing this error message continue to scroll by... Cheers, was On Dec 2, 2011, at 11:59 AM, Saadia Husain Baloch wrote: > Sasha and James, > I thought this was pushed to arm-3.0-wip, but it doesn't show up there. After > trying it out, I found that the board revision was not current, and got that > fixed by jnettlet. > Any clues as to whether the patch was pushed? > -Saadia > > > On Wed, Nov 23, 2011 at 1:00 AM, James Cameron wrote: > On Tue, Nov 22, 2011 at 01:13:55PM +0100, Sascha Silbe wrote: > > The lis3lv02d driver doesn't support multiple instances of itself, so > > we need to make sure we instantiate only the one that's actually > > present. This also avoids logging an error message about not being > > able to initialise the 8-bit sensor on C1 and above. > > > > Signed-off-by: Sascha Silbe > > --- > > Tested on B1 only since I don't have a C1. Are there even actual C1s > > or just patched-up Bx? I wonder because the wiki page for C1 doesn't > > exist yet. > > Yes, many C1 exist. Sorry about the Wiki page. > > Tested your patch with 5611fd36a7b30edac640e1bd8ab2948ca91d09d5 by > Andres, since this is needed for board detect to work, and also with > q4c05jc [1] which changes /proc/device-tree/openprom/architecture to > OLPC. > > On an XO-1.75 C1 with new accelerometer, dmesg contains: > > lis3lv02d: 16 bits sensor found > input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input0 > > On an XO-1.75 B1 with old accelerometer, dmesg contains: > > lis3lv02d: 8 bits sensor found > input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input0 > > On an XO-1.75 B1 with new accelerometer, dmesg contains: > > lis3lv02d: unknown sensor type 0x87 > lis3lv02d_i2c: probe of 5-001d failed with error -22 > > On an XO-1.75 B4 with new accelerometer, dmesg contains: > > lis3lv02d: unknown sensor type 0x87 > lis3lv02d_i2c: probe of 5-001d failed with error -22 > > So effectively your patch breaks XO-1.75 B1 and B4 with new > accelerometer chip. ;-} > > Saadia is looking into this, she said. > > -- > > [1] http://dev.laptop.org/~quozl/q4c05jc.rom > > -- > James Cameron > http://quozl.linux.org.au/ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ad-hoc networking - automatically selecting the best channel
On Thu, Dec 1, 2011 at 7:55 PM, Sridhar Dhanapalan wrote: > My understanding is the Sugar's ad-hoc automatically defaults to > channel 1. Would it be possible for the client (XO or otherwise) to > automatically pick the best channel (1, 6 or 11) based on prevailing > interference levels? For the reasons James pointed out, it's not easily solvable for the "find the best thing to do, quickly". Ad hoc works well for very small groups (<6) -- and in that case you want them all to be in the same channel... to be able to communicate! :-) It's for the "under a tree" scenario, no access points around. If there is a lot of interference, it means there are lots of APs. Just make one AP available to the XOs ;-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH linux] Fix double accelerometer initialisation
Sasha and James, I thought this was pushed to arm-3.0-wip, but it doesn't show up there. After trying it out, I found that the board revision was not current, and got that fixed by jnettlet. Any clues as to whether the patch was pushed? -Saadia On Wed, Nov 23, 2011 at 1:00 AM, James Cameron wrote: > On Tue, Nov 22, 2011 at 01:13:55PM +0100, Sascha Silbe wrote: > > The lis3lv02d driver doesn't support multiple instances of itself, so > > we need to make sure we instantiate only the one that's actually > > present. This also avoids logging an error message about not being > > able to initialise the 8-bit sensor on C1 and above. > > > > Signed-off-by: Sascha Silbe > > --- > > Tested on B1 only since I don't have a C1. Are there even actual C1s > > or just patched-up Bx? I wonder because the wiki page for C1 doesn't > > exist yet. > > Yes, many C1 exist. Sorry about the Wiki page. > > Tested your patch with 5611fd36a7b30edac640e1bd8ab2948ca91d09d5 by > Andres, since this is needed for board detect to work, and also with > q4c05jc [1] which changes /proc/device-tree/openprom/architecture to > OLPC. > > On an XO-1.75 C1 with new accelerometer, dmesg contains: > > lis3lv02d: 16 bits sensor found > input: ST LIS3LV02DL Accelerometer as > /devices/platform/lis3lv02d/input/input0 > > On an XO-1.75 B1 with old accelerometer, dmesg contains: > > lis3lv02d: 8 bits sensor found > input: ST LIS3LV02DL Accelerometer as > /devices/platform/lis3lv02d/input/input0 > > On an XO-1.75 B1 with new accelerometer, dmesg contains: > > lis3lv02d: unknown sensor type 0x87 > lis3lv02d_i2c: probe of 5-001d failed with error -22 > > On an XO-1.75 B4 with new accelerometer, dmesg contains: > > lis3lv02d: unknown sensor type 0x87 > lis3lv02d_i2c: probe of 5-001d failed with error -22 > > So effectively your patch breaks XO-1.75 B1 and B4 with new > accelerometer chip. ;-} > > Saadia is looking into this, she said. > > -- > > [1] http://dev.laptop.org/~quozl/q4c05jc.rom > > -- > James Cameron > http://quozl.linux.org.au/ > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
