00:00.30 | [acl] | MassStash: and it has later kernel too.. so thats whats diff |
00:01.13 | [acl] | MassStash: since arrg was able to boot.. did u test it ou? |
00:02.33 | arrrghhh | Oo later kernel |
00:02.40 | jonpry | http://imagebin.org/139943 |
00:02.43 | jonpry | WisTilt2, check it out |
00:05.15 | WisTilt2 | jonpry: nice. so thats battery percentage as it drops? |
00:05.41 | jonpry | yeah thats your data set. red is simple voltage to charge%. blue is output of the model |
00:06.06 | WisTilt2 | what did you use for the 100% value, 4200? |
00:06.22 | jonpry | 4117 |
00:06.34 | MassStash | [acl], yea tested and working - service |
00:06.45 | jonpry | 4171 |
00:06.58 | WisTilt2 | so it extrapolated that num? |
00:07.40 | [acl] | MassStash: good to hear.. ur on 400 or 5? |
00:07.42 | jonpry | umm, no that is from standard open circuit li-ion curves |
00:07.45 | MassStash | 400 |
00:08.19 | jonpry | WisTilt2, key here is we can use open circuit voltage cause we can calculate what the battery voltage would be if it were hypothetically unloaded and relaxed |
00:09.10 | jonpry | it actually takes a while for the algorithm to train up to a bad start like we will always get |
00:09.17 | WisTilt2 | so the fact we're tracking close to the model means this should be fairly accurate across the board |
00:09.46 | jonpry | there are problems |
00:10.03 | jonpry | its a machine learning thing, so the fact that it predicts well on the training data is not surprising |
00:10.37 | jonpry | i also do not understand why SOC starts taking a dive at 80% |
00:11.19 | WisTilt2 | very curious to see the output with a heavier load on the same device |
00:11.40 | jonpry | yes, we can try with model derived from this data set to see how accurate it is |
00:11.51 | jonpry | or visa versa |
00:12.47 | arrrghhh | WisTilt2: don't mean to interrupt, but did the move of ramconsole mess up the SYSTEM_LAST_KMSG files...? |
00:13.42 | WisTilt2 | arrrghhh, moving ramconsole isnt in that test kernel, only the one im messing with here |
00:13.53 | jonpry | the original authors used slightly different model based on SOC. i don't have a plan on how to derive that from the data |
00:14.08 | WisTilt2 | are all those kmgs files empty? |
00:14.10 | [acl] | aite fellas .. need to get back to helping for this wedding.. laters |
00:14.20 | arrrghhh | WisTilt2: hrm. well, all the SYSTEM_LAST_KMSG's I'm getting from everyone are empty... |
00:14.23 | arrrghhh | yea |
00:15.12 | bzo | arrrghhh: have you looked at them with a hex editor/viewer? |
00:15.19 | WisTilt2 | hmm, i did have klog disabled in one of my many tests, maybe i didnt turn it back on when i built that one |
00:15.30 | arrrghhh | bzo: the SYSTEM_LAST_KMSG files...? |
00:15.51 | bzo | arrrghhh: nvm, thought you were talking about dumping ramconsole |
00:15.54 | arrrghhh | WisTilt2: huh. sounds like it might do it :P |
00:15.58 | arrrghhh | bzo: sorry no ;) |
00:16.45 | WisTilt2 | bzo: moving ramconsole to ebi1 is working nicely so far. i cant get it to crash msm_fb at all now and waking every time without any vsync errors. |
00:17.15 | Alex[sp3dev] | WisTilt2: crashing msm_fb? huh? |
00:17.43 | WisTilt2 | well, causing pan_display errors with vsync timeouts, thats crashing in my book:) |
00:17.47 | bzo | WisTilt2: weird stuff, guess we shouldn't be playing in qcsbl |
00:18.17 | Alex[sp3dev] | WisTilt2: let's agree that crashing is either a null pointer or data abort.. don't make me feel nervous ;) |
00:18.47 | arrrghhh | WisTilt2: orly now? |
00:18.51 | WisTilt2 | why does gpu0 have to be in SMI? |
00:19.00 | Alex[sp3dev] | WisTilt2: speeeeed |
00:19.24 | bzo | Alex[sp3dev]: is 1mb the minimum size granularity for pmem? |
00:19.35 | bzo | WisTilt2: I think the qcom libs are hardcoded for it |
00:19.51 | Alex[sp3dev] | bzo: no idea. who told you that? iirc jb is using half meg somewhere |
00:20.11 | bzo | Alex[sp3dev]: just a dumb assumption on my part |
00:20.23 | bzo | guess it would be more logical to be a page size or something? |
00:20.36 | Alex[sp3dev] | i would think so |
00:20.45 | jonpry | not like mmu is involved |
00:21.42 | bzo | anyways, I guess it is no big deal to relocate ramconsole to ebi if we can use only 128k or so |
00:22.04 | Alex[sp3dev] | honestly, i do not like the vreg api. when we'll finish 35 and nand, i'll either convert it to voltage regulator framework or make it lookup vregs by numbers. android and wince names don't match at all |
00:22.28 | bzo | WisTilt2: what size did you make your ebi ramconsole? |
00:22.41 | WisTilt2 | ok dumb question here, what is using the 1st meg of SMI? gpu0 starts from 1meg up |
00:22.51 | WisTilt2 | bzo: left it at 128k |
00:22.56 | Alex[sp3dev] | WisTilt2: spl. told you already today |
00:23.00 | bzo | Alex[sp3dev]: yeah, the way we use non matching vreg names is dumb |
00:23.02 | Alex[sp3dev] | and it is mmued |
00:23.05 | Alex[sp3dev] | mpued |
00:23.28 | WisTilt2 | :( too many things today to remember. thanks alex |
00:23.41 | Alex[sp3dev] | no problem |
00:24.00 | Cotulla | wtf |
00:24.01 | Cotulla | :D |
00:24.09 | jonpry | looks like SMI is probably edram |
00:24.11 | Cotulla | I come back and u still discussing SMI |
00:24.29 | arrrghhh | lol |
00:24.33 | Alex[sp3dev] | a law of smi. whenever Cotulla comes, people are discussing SMI |
00:25.36 | bzo | jonpry: either that, or on the same package |
00:25.52 | jonpry | either way, edram slow :( |
00:26.37 | bzo | it seems more likely to be the latter, because there are versions with different amounts of smi |
00:26.58 | Cotulla | it's DDR wtf |
00:27.04 | bzo | also, do they do edram that large? |
00:27.06 | Cotulla | wtf |
00:27.56 | *** join/#htc-linux GNUtoo|laptop (~gnutoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
00:28.12 | jonpry | i dunno. qcom uses it though |
00:28.33 | jonpry | then there is qsd, they have vreg for edram? |
00:32.44 | *** part/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
00:32.56 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
00:33.10 | *** join/#htc-linux LuHe (~LuHe@91-118-62-204.dynamic.adsl-line.inode.at) |
00:36.10 | WisTilt2 | arrrghhh: are you in nand or can you try this kernel and see if it blows up your phone? |
00:36.13 | *** join/#htc-linux MethoS-- (~clemens@134.102.106.250) |
00:36.22 | *** join/#htc-linux mobidev_ (~i-sat@wmod.net) |
00:37.25 | arrrghhh | WisTilt2: bring it on |
00:37.28 | arrrghhh | i'm running your kernel |
00:37.35 | arrrghhh | no data in nand still, can't have that :P |
00:38.12 | arrrghhh | WisTilt2: i was actually just saying to the peoples the reason last_kmsg's were blank heh. |
00:38.16 | WisTilt2 | booting right now. want to see if kmsg log is back to normal first |
00:39.00 | WisTilt2 | bootup time has been ranging 75-90secs every boot |
00:39.25 | arrrghhh | kk |
00:39.28 | arrrghhh | nice! |
00:44.00 | GNUtoo|laptop | hi dcordes_ |
00:44.14 | Alex[sp3dev] | GNUtoo!!! |
00:44.38 | Alex[sp3dev] | GNUtoo: hi, could you send me your attempts at bringing wl1251 on dream? |
00:47.30 | WisTilt2 | arrrghhh: kernel with your name on it -> 6fe6504b5dcda4aeb1bc9aa52659c9ff |
00:47.39 | arrrghhh | kk |
00:47.54 | WisTilt2 | i changed the ramconsole to 256k for kicks also |
00:48.22 | WisTilt2 | might be a placebo effect but in ebi memory it seems snappier |
00:48.30 | arrrghhh | heh |
00:49.34 | *** join/#htc-linux CazH (~quassel@3007ds2-rd.0.fullrate.dk) |
00:51.25 | *** join/#htc-linux FlawlesStyle (~LOL@unaffiliated/flawlesstyle) |
00:55.31 | *** join/#htc-linux g3rm (~germo@89-77-81-175.dynamic.chello.pl) |
00:56.23 | *** join/#htc-linux arrrghhh_ (~arrrghhh@c-71-237-40-111.hsd1.co.comcast.net) |
00:57.00 | WisTilt2 | arrrghhh: go to the app menu, back to main screen, switch apps, tell me this isnt noticeably faster! |
00:57.19 | *** join/#htc-linux cazh_ (~quassel@3007ds2-rd.0.fullrate.dk) |
00:57.43 | WisTilt2 | lol, just hit the app menu then back button, wow |
00:57.55 | arrrghhh | heh |
00:57.58 | arrrghhh | calm down there |
00:58.04 | arrrghhh | haven't booted yet. |
00:58.20 | WisTilt2 | this is way faster than my sons iphone he keeps bragging on being faster screen |
00:58.21 | *** join/#htc-linux Nautis (4cda4629@gateway/web/freenode/ip.76.218.70.41) |
00:58.27 | arrrghhh | lmao |
00:58.31 | arrrghhh | that's what i'm talkin about |
00:58.37 | arrrghhh | trash talkin iOS |
00:59.33 | rpierce99 | no no WisTilt2 you're doing it all wrong, it goes like this: APPS: BLAZING FAST, MARKET: SUPER FAST, 3G: SPIZEEEDY, ITS BEST BUILD EVER |
00:59.58 | arrrghhh | lol |
01:00.04 | WisTilt2 | lol, got a ways to go but getting there |
01:00.08 | arrrghhh | i don't think he's had the privelege of reading any of those threads. |
01:00.43 | arrrghhh | this boot is soooo much less verbose. |
01:00.49 | arrrghhh | i almost miss the flying text, odd :P |
01:00.58 | arrrghhh | it likes to sit at the prompt too |
01:01.00 | arrrghhh | teasing me |
01:01.01 | WisTilt2 | yeah everything fits on the screen so you can read it |
01:01.09 | arrrghhh | i know it's wacky :P |
01:01.57 | *** join/#htc-linux CazH (~quassel@3007ds2-rd.0.fullrate.dk) |
01:03.15 | WisTilt2 | bzo: just an fyi if you want to mess with it... i moved ramconsole to the base of EBI and allocated 256k. definitely quicker and so far no errors, but arrrghhh will come up with some im sure:) |
01:03.36 | arrrghhh | hrm |
01:03.40 | *** join/#htc-linux arif-ali (~arif-ali@88-111-128-250.dynamic.dsl.as9105.com) |
01:03.47 | arrrghhh | it's... worse for me so far. just had a competely failed wake... |
01:03.59 | arrrghhh | maybe it was the startup jitters... |
01:04.07 | WisTilt2 | did you let it fully bootup and settle down? |
01:04.25 | bzo | WisTilt2: ok, let's see how it goes with your next test kernel |
01:04.30 | WisTilt2 | it does weird things until data stuff gets situated ive found |
01:05.06 | arrrghhh | indeed |
01:05.39 | WisTilt2 | mines been up 22mins and my fingers are getting tired of pushing on/off, no failed wakes or errors yet |
01:05.49 | *** join/#htc-linux Dinde (kayser@sur-internet.net) |
01:06.11 | arrrghhh | lol |
01:07.20 | *** join/#htc-linux programmer8922 (~Evan@67.219.164.162) |
01:07.23 | WisTilt2 | arrrghhh: if you get a failed wake like that where backlight comes on only, hit power and wait for it to fully sleep then it will come back up. if you can look at dmesg right after that, see if there are any pan_display errors during the wake sequence |
01:07.35 | *** part/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |
01:07.57 | WisTilt2 | most likely it will be the msm_fb dma timeout |
01:09.36 | WisTilt2 | arrrghhh im out of here, need to go by the bank then home so ill be back on in an hour or so for your list of bugs:) |
01:28.49 | *** join/#htc-linux surge (surge@pool-98-118-157-221.bflony.fios.verizon.net) |
01:28.59 | jonpry | is feeding the kernels battery from userland actually a bad idea? |
01:29.26 | jonpry | *kernels battery driver |
01:36.02 | *** join/#htc-linux ftoz (~root@cst-prg-164-28.vodafone.cz) |
01:59.00 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless248.wirelesstcp.net) |
02:06.19 | jonpry | hi WisTilt2 |
02:06.22 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5DE0.dip.t-dialin.net) |
02:06.52 | arrrghhh | WisTilt2: so far so good |
02:07.02 | WisTilt2 | yo. friday night, drinks in hand, life is good |
02:07.07 | fakker | snifffs |
02:07.11 | fakker | sniffs WisTilt2 |
02:07.12 | jonpry | i'm stoked about this battery thing, i think it is finally working :p. |
02:07.17 | WisTilt2 | fakker lol |
02:07.17 | fakker | sniffs jonpry |
02:07.25 | fakker | :D |
02:07.30 | jonpry | for the last time |
02:07.33 | fakker | i need some 2am entertainment |
02:07.35 | fakker | jonpry, you wish |
02:07.41 | fakker | i just started |
02:08.30 | WisTilt2 | jonpry: i took one of our phones from the office and set it up with the heavy load test. 4hrs run should be done in about 2.5hrs and ill email it to you. i really want to see how much different that reports |
02:08.30 | jonpry | WisTilt2, what do you think feeding the userland results back into the kernel, so they can be presented on /sys/class/... |
02:08.34 | arrrghhh | WisTilt2: i did get one [ 212.721618] msmfb_pan_display timeout rerequest vsync |
02:08.42 | WisTilt2 | arrrghhh: fast screen now huh? |
02:08.46 | arrrghhh | 200s in tho, that was probably the failed wake at the beginning |
02:08.57 | arrrghhh | but yea haven't had a failed wake since |
02:09.01 | arrrghhh | made a bunch of phone calls |
02:09.06 | arrrghhh | hope i don't go over my work phone's minutes lol |
02:09.15 | WisTilt2 | jonpry: sounds good. what all would need to be passed back? |
02:10.00 | WisTilt2 | arrrghhh: did it do the partial panel wake thing at that time and came back up after full sleep again? |
02:10.21 | arrrghhh | yup |
02:10.26 | arrrghhh | and it was just that once, early in the boot |
02:10.38 | WisTilt2 | yeah things were still getting situated i think |
02:10.53 | arrrghhh | swiping desktops is incredible |
02:10.54 | jonpry | WisTilt2, i think just capacity, and maybe voltage |
02:11.01 | arrrghhh | that used to be kinda painful until you did it a few times |
02:11.19 | WisTilt2 | arrrghhh, instant isnt it? |
02:11.30 | arrrghhh | yup |
02:11.33 | WisTilt2 | switching menu back to desktop is crazy |
02:11.54 | arrrghhh | it really is starting to feel like a native android phone |
02:12.01 | WisTilt2 | jonpry: so userland would just pass that and kernel just stores it back in the class? |
02:12.02 | arrrghhh | this 30s sleep thing is frustrating. |
02:13.07 | WisTilt2 | 30s continuously? |
02:13.16 | arrrghhh | not at first |
02:13.29 | arrrghhh | but i seem to have gotten stuck in it after a little while |
02:13.33 | arrrghhh | i called it a whole bunch |
02:13.38 | WisTilt2 | its never going back to the 5ss now once it started? |
02:13.41 | arrrghhh | put it in deep sleep and called it again and again :D |
02:13.46 | arrrghhh | nope, not yet at least. |
02:13.53 | jonpry | WisTilt2, i think what happens is batteryd will block on read for more data, and battery driver will open up the flow whenever phone is awake. then when algorithm gets a hunk, it will immediately write a new result back to the driver, which just caches it for the /sys/class/attribute reads |
02:14.04 | XirXes | can i get in on this fun? it sounds awesome |
02:15.32 | WisTilt2 | jonpry: sounds good. you do the userland side and tell me what you need on the kernel side and ill set it up, unless you want to code the whole thing |
02:15.50 | jonpry | not really :p |
02:16.03 | WisTilt2 | XirXes, going to have arrrghhh put it up for testing as soon as I fix the manual backlight problem. |
02:16.13 | jonpry | how are you reading the ring buffer out now? |
02:16.17 | XirXes | sounds good |
02:16.27 | jonpry | you have an app for that? |
02:17.16 | arrrghhh | lol |
02:17.33 | WisTilt2 | jonpry: im doing it all inside the kernel right now. need to setup zalloc instead of this char buffer really. |
02:18.49 | WisTilt2 | we need to layout how things need to happen in the kernel. do we wake it up at some interval, store in ring buffer and wait. i guess you're going to need the kernel to make the whole ring buffer available to userland or what? |
02:19.11 | arrrghhh | WisTilt2: this thing is a beast. have a fix for those who use manual bl? |
02:19.27 | arrrghhh | is it in this one, should i test that? i'm guessing no. |
02:19.50 | WisTilt2 | yeah going to fix that right now then you can put up the new kernel pack for mass testing with this new stuff |
02:20.20 | jonpry | well i figure when phone is sleep or almost sleeping, we don't need userland to do anything, so theres no reason to give it data, hence need for buffer. but i'm not sure how to differentiate "woke up for level reading" and "woke up for code/phone/whatev" |
02:21.29 | jonpry | but events could be transferred to userland one at a time as far as i'm concerned |
02:21.31 | WisTilt2 | i can make it only pull data on its planned read interval so if something else wakes it up it wont skew the timing |
02:21.34 | jonpry | maybe blocking ioctl |
02:21.51 | jonpry | that would be good |
02:22.46 | WisTilt2 | but when you request the data from userland, will the whole ring buffer be sent or do i need to keep a pointer to the next value to send? |
02:23.33 | jonpry | it depends |
02:23.46 | jonpry | ioctl are fixed size, so if we do it that way, it one at a time |
02:24.15 | jonpry | char stream could in theory pipe lots of stuff, but it is trickier, cause you have to worry about incomplete reads |
02:24.49 | WisTilt2 | ioctl would be cleaner and exact |
02:25.28 | XirXes | does anyone know the name of the prox/ light sensor in the rhod? |
02:25.50 | arrrghhh | O.o WisTilt2 just had a failed wake, simply hitting the power button. |
02:26.03 | arrrghhh | i will pull dmesg as soon as it sleeps again and i can wake it back up. |
02:26.03 | jonpry | WisTilt2, that sounds good to me, so then you definitely need read ptr |
02:26.10 | WisTilt2 | nice. let it sleep then wake it and check dmesg for that error |
02:26.54 | WisTilt2 | brb, wife has groceries again:( |
02:31.06 | arrrghhh | WisTilt2: odd. i didn't get another pan_display error at all. |
02:31.08 | arrrghhh | WisTilt2: http://pastebin.com/XRMEAk7Q |
02:32.34 | rpierce99 | arrrghhh: there is this though: msmfb_start_dma 35110.000 ms after vsync request |
02:33.16 | arrrghhh | Oo |
02:33.19 | arrrghhh | good catch |
02:33.33 | rpierce99 | don't know what it means but 35s doesn't sound good |
02:33.40 | arrrghhh | lol no |
02:33.51 | arrrghhh | that's right around the issue took i believe |
02:43.13 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
02:44.21 | *** join/#htc-linux crawling (crawling@a94-132-169-99.cpe.netcabo.pt) |
02:46.27 | arrrghhh | wth just had another one |
02:46.28 | arrrghhh | http://pastebin.com/5VSWdZcc |
02:52.04 | *** join/#htc-linux nineX_ (~nunya@75-132-13-29.dhcp.stls.mo.charter.com) |
03:00.11 | WisTilt2 | arrrghhh: ok back from unloading and eating something. so looks like theres still a problem with vsync. thats where the non wakes seem to always occurs |
03:01.17 | arrrghhh | WisTilt2: what about that last one? |
03:01.31 | arrrghhh | i didn't see any of those errors, but i don't really know what i'm looking for. |
03:01.48 | WisTilt2 | dont see anything at all in that one. did it come back after going into sleep again? |
03:02.41 | arrrghhh | yup |
03:02.51 | arrrghhh | and as soon as it did, unlock plug in adb pull dmsg... |
03:03.13 | WisTilt2 | are the kmsg logs still empty btw |
03:03.28 | arrrghhh | i think i need to reboot to see those, right? |
03:03.32 | WisTilt2 | yep |
03:03.34 | arrrghhh | kk |
03:03.46 | arrrghhh | see anything about the 30s sleep?' |
03:11.13 | WisTilt2 | yeah looks like a wakelock on evdev holding it. need to see why that would have changed to that long |
03:11.47 | arrrghhh | k |
03:11.57 | WisTilt2 | i added output to show when arm11 sleeps/wakes exactly so its easier to have starting points |
03:13.17 | arrrghhh | cool |
03:17.48 | WisTilt2 | arrrghhh: which rhods dont have proximity sensor? |
03:18.43 | XirXes | all have them |
03:19.16 | XirXes | the light and prox sensors are the same chip afaik |
03:19.42 | WisTilt2 | interesting. |
03:19.43 | arrrghhh | i don't know about what chip they're on |
03:19.55 | arrrghhh | but AFAIK all RHOD's have prox sensor. |
03:20.30 | phh | yes |
03:20.33 | phh | and it's an isl something chip |
03:21.59 | WisTilt2 | phh: proximity not working obviously but was the code that maps it to an input always in the code or added a few months ago? |
03:22.25 | phh | few months ago |
03:22.31 | phh | iirc the code was totally wrong |
03:23.03 | WisTilt2 | hmm, this wake lock hanging things might be that input |
03:23.10 | phh | "oops" |
03:23.50 | *** join/#htc-linux CIA-62 (~CIA@208.69.182.149) |
03:24.22 | WisTilt2 | code is wrong, i have the proximity stuff already but havent implemented it yet. but this wake lock points to that input being the possible cause |
03:24.36 | arrrghhh | heh |
03:25.00 | phh | just drop that code |
03:25.23 | WisTilt2 | going to do that now and see |
03:26.33 | *** join/#htc-linux netson-ubuntu (~netson-ub@125.161.198.91) |
03:26.47 | *** join/#htc-linux crawling (crawling@a94-132-169-99.cpe.netcabo.pt) |
03:29.27 | XirXes | i just found the ir blaster in the tp2. its right above the htc logo on the front. inpossible to see without it being on and with a camera |
03:29.28 | jonpry | WisTilt2, i defined some ioctl's and structures for our project. this file would go in linux/include |
03:29.29 | jonpry | http://gitorious.org/scbs/scbs/blobs/master/scbs.h |
03:30.12 | jonpry | very complicated :p |
03:36.31 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
03:38.21 | AstainHellbring | how goes it |
03:38.29 | AstainHellbring | ~seen cr2 |
03:38.33 | apt | cr2 <n=cr2@ip-109-84-74-80.web.vodafone.de> was last seen on IRC in channel #htc-linux, 399d 7h 17m 40s ago, saying: 'MrPippy: where is this source ?'. |
03:38.38 | arrrghhh | 399d |
03:38.39 | AstainHellbring | damn |
03:38.42 | AstainHellbring | long time ago |
03:38.45 | arrrghhh | ~seen cr2_ |
03:38.46 | apt | cr2_ <~cr2@ip-80-226-0-1.vodafone-net.de> was last seen on IRC in channel #htc-linux, 37d 5h 55m 23s ago, saying: 'kiozen: i can run userspace x11/gtk apps, but it is not possible to access the hardware. so it's more or less useless'. |
03:38.48 | phh | . |
03:38.50 | arrrghhh | lol |
03:38.51 | arrrghhh | sorry |
03:38.54 | arrrghhh | apt was smart |
03:39.00 | phh | yeah |
03:39.03 | AstainHellbring | very |
03:39.14 | AstainHellbring | phh know if anything has happened on athena dev? |
03:39.28 | phh | athena ? :D |
03:39.42 | AstainHellbring | yah aka htc advantage aka x7500 |
03:39.53 | phh | doesn't really help :p |
03:39.57 | AstainHellbring | lol |
03:40.06 | phh | i'm not *that* old |
03:40.06 | AstainHellbring | guess thats a no from you |
03:40.11 | AstainHellbring | cr2 was doing some stuff on it |
03:40.15 | AstainHellbring | athenas not that old |
03:40.23 | AstainHellbring | well I guess in phone terms it is |
03:40.36 | phh | how much ? 5 years ? |
03:40.44 | AstainHellbring | something like that |
03:40.53 | AstainHellbring | ran intel xscale proc |
03:41.02 | phh | wo |
03:41.02 | phh | w |
03:41.13 | AstainHellbring | was a sweet device |
03:41.22 | AstainHellbring | 5" screen detachable magnetic keyboard |
03:41.31 | phh | oO |
03:41.59 | arrrghhh | wth? |
03:42.06 | AstainHellbring | http://pdadb.net/index.php?m=specs&id=691&c=t-mobile_mda_ameo_htc_athena_100 |
03:42.10 | AstainHellbring | thats a version of it |
03:42.41 | phh | motorola atrix is late ! :D |
03:42.57 | AstainHellbring | phh you ordered one? |
03:43.06 | phh | a what ? |
03:43.08 | phh | either way it's no |
03:43.12 | AstainHellbring | atrix |
03:43.15 | AstainHellbring | you said its late |
03:43.26 | phh | i mean their idea |
03:43.31 | phh | compared to htc athena |
03:43.36 | AstainHellbring | ahh gotcha |
03:43.54 | WisTilt2 | arrrghhh: try this one and see if you can get it to do it. 8c5ef1d2ae42da275d8911fa9ee55db5 |
03:44.03 | arrrghhh | kk |
03:44.16 | dcordes_ | hi |
03:45.35 | WisTilt2 | jonpry: dont know if i can handle that, very complicated stuff:) |
03:46.42 | WisTilt2 | what time value you need? |
03:51.00 | dcordes_ | Login error |
03:51.01 | dcordes_ | Htc-linux uses cookies to log in users. You have cookies disabled. Please enable them and try again. |
03:51.08 | dcordes_ | NetRipper: ping |
03:53.18 | arrrghhh | WisTilt2: failed wake. pulling logs... |
03:53.59 | arrrghhh | http://pastebin.com/SgcbyUwQ |
03:54.01 | arrrghhh | ^^ |
03:54.49 | jonpry | WisTilt2, i'm guessing milliseconds |
03:55.08 | dcordes_ | somebody knows where the photon kernel is ? |
03:55.09 | jonpry | like somebody could set 5000 sleep, 1000 awake for the updates |
03:56.35 | arrrghhh | brb |
03:56.39 | jonpry | and then samples would need to be labeled. its not important if sleep==awake |
03:57.04 | jonpry | i think voltage,current,capacity, 16.16 fixed point |
03:57.14 | *** join/#htc-linux bzo (~chatzilla@c-76-126-175-200.hsd1.ca.comcast.net) |
03:59.40 | jonpry | i wish android had STL |
04:00.20 | AstainHellbring | STL? |
04:00.40 | jonpry | standard template library |
04:03.06 | *** join/#htc-linux kubi (~Adium@miranda/user/kubi) |
04:04.33 | WisTilt2 | jonpry: in going to be adding the logging timestamp correction to show actual time since boot instead of timestamps freezing in suspend, then continuing from that point. that way logs will be actual uptime logging and the battery readings can match time since boot. |
04:05.35 | jonpry | that sounds like an important step |
04:05.59 | WisTilt2 | yeah, been bugging me how timestamps in logs are real with actual uptime |
04:06.10 | WisTilt2 | arent real i mean |
04:06.27 | jonpry | especially since you've got 99% sleep |
04:07.01 | WisTilt2 | arm has a register that tracks that so sleep time can be correct to actual runtime |
04:07.30 | jonpry | would it be cool if sleep/collapse was some kind of dynamic thing |
04:08.30 | jonpry | i guess thats not really how phones are used |
04:15.12 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
04:16.13 | jonpry | somehow or another the integral of those 1 second current measurements is not fubar |
04:16.35 | jonpry | we will see about 5 |
04:18.09 | WisTilt2 | we need to do 5s intervals instead of 1s on these tests we're doing now or you mean later? |
04:18.23 | jonpry | later i think |
04:18.32 | jonpry | we need all kinds of data |
04:19.11 | WisTilt2 | this 4hr test under load looks like it will be done in about 15mins or so. they are at 1s intervals like before |
04:19.36 | WisTilt2 | man that phone is much warmer than the previous test |
04:19.47 | jonpry | cool. i don't think 5 seconds will work off the bat and we will end up needing the adaptive time thing |
04:19.54 | jonpry | are you taking it to zero? |
04:20.45 | jonpry | adaptive learning rate with adaptive time will be way cool too |
04:20.46 | *** join/#htc-linux Rob2223 (~Miranda@p4FFF3EE7.dip.t-dialin.net) |
04:20.50 | WisTilt2 | ? just running 14400 polls 1sec apart |
04:21.32 | jonpry | oh i though you were watching the meter or something and taking the log when it gets too low |
04:21.40 | *** join/#htc-linux arrrghhhTP2 (~arrrghhh_@107.29.229.114) |
04:22.45 | WisTilt2 | ah, no i have it in the console outputting each 1sec reading. when it finishes the last one it saves the data to the sd card with the filename i sent you |
04:23.48 | WisTilt2 | damn, arrrghhh you must try this next kernel my friend:) found the sucker holding up the show and now we have true full sleep in about 1second. |
04:24.05 | jonpry | i wonder if there is a way to identify individual batteries. in case people change it |
04:25.03 | arrrghhhTP2 | WisTilt2: Oo? |
04:25.16 | WisTilt2 | arrrghhh -->> 096154f32b61f2e654884459123925a8 awsome:) |
04:25.21 | arrrghhhTP2 | Heh |
04:25.25 | arrrghhhTP2 | Kk |
04:25.42 | WisTilt2 | jonpry: cant we read and match the battery id to a manufacture table of some sort? |
04:26.13 | jonpry | yeah there is a resistor in each battery |
04:26.17 | jonpry | that is read via adc |
04:26.38 | jonpry | and if its in some range you can tell like what capacity it is |
04:26.47 | jonpry | or was made to be |
04:27.24 | WisTilt2 | ah i see what you mean. yes that would be nice so we could reset on a battery with different characteristics |
04:27.28 | jonpry | i dunno if that number has a lot of entropy or something that could be exploited |
04:27.39 | jonpry | yeah like that |
04:29.06 | arrrghhhTP2 | Hrm I don't have dns in console |
04:29.06 | arrrghhhTP2 | Odd |
04:29.49 | jonpry | but internet works? |
04:30.23 | jonpry | just echo 8.8.8.8 > /etc/resolv.conf |
04:30.39 | arrrghhhTP2 | Heh |
04:30.53 | phh | echo nameserver 8.8.8.8 > /etc/resolv.conf |
04:31.02 | jonpry | or listen to him |
04:31.12 | phh | wait, he is not on android ? |
04:31.18 | jonpry | he is |
04:31.22 | jonpry | and your right |
04:31.22 | phh | on android it's more like setprop net.dns1 8.8.8.8 |
04:31.34 | jonpry | hrm |
04:31.41 | phh | yeah you love that i know |
04:31.48 | jonpry | no resolv.conf for busybox stuff? |
04:31.57 | phh | mmmmmmmmmm |
04:32.07 | phh | i'd say busybox uses bionic |
04:32.10 | phh | which uses properties |
04:32.22 | phh | but perhaps busybox is statically built |
04:32.37 | phh | ok, time to sleep. |
04:32.44 | jonpry | so one of the two? |
04:33.10 | arrrghhhTP2 | Lol |
04:33.49 | WisTilt2 | phh: you know that unbalanced irq 154 (or whatever it was), it was the proximity device. no longer erroring |
04:33.55 | jonpry | come on arrrghhhTP2 fix your internet |
04:34.44 | arrrghhhTP2 | :( |
04:34.56 | arrrghhhTP2 | is confused |
04:35.11 | arrrghhhTP2 | Internet working, not in terminal. |
04:35.43 | jonpry | arrrghhhTP2, did you do the echos? |
04:35.59 | arrrghhhTP2 | Not the setprop |
04:36.38 | jonpry | you did phh's nameserver one? |
04:36.59 | arrrghhhTP2 | Yea didn't work |
04:37.10 | jonpry | do setprop |
04:37.10 | arrrghhhTP2 | Unless I need to cycle something? |
04:37.13 | arrrghhhTP2 | Kk |
04:37.33 | jonpry | when will android get bash? |
04:37.56 | WisTilt2 | thats not right, dont think resolv.conf is in /etc like regular linux |
04:38.12 | jonpry | phh says bionic doesn't use it |
04:38.38 | arrrghhhTP2 | Just keeps telling me "ping: bad address" |
04:38.52 | jonpry | probably ipv6 |
04:39.15 | arrrghhhTP2 | Heh |
04:39.20 | arrrghhhTP2 | Modprobe ipv6? |
04:40.14 | jonpry | try ping 2001:4860:c004::68 |
04:40.48 | arrrghhhTP2 | I can ping 8.8.8.8 |
04:41.09 | jonpry | can you go to that address in android? |
04:41.45 | arrrghhhTP2 | I just wanted to wget in the terminal |
04:42.48 | jonpry | wget with the ip :p |
04:43.09 | arrrghhhTP2 | Heh |
04:43.16 | arrrghhhTP2 | Damnit.. |
04:47.41 | arrrghhhTP2 | Victory |
04:47.52 | arrrghhhTP2 | Had to use a pc to find ip tho, sad lol |
04:48.40 | arrrghhhTP2 | Alright reboot time. |
04:51.56 | jonpry | WisTilt2, is it done? |
04:52.25 | WisTilt2 | yep, about to pull it off onto the laptop and email it |
04:54.04 | jonpry | cool |
04:56.37 | WisTilt2 | jonpry: in your mailbox |
04:59.39 | *** join/#htc-linux arrrghhhTP2 (~arrrghhh_@107.29.229.114) |
04:59.58 | arrrghhhTP2 | Wis |
05:00.11 | arrrghhhTP2 | Damnit keep hitting the wrong key |
05:00.31 | WisTilt2 | hurry up, im one kernel ahead of you:) |
05:00.36 | arrrghhhTP2 | WisTilt2: sleeps fast! Had a failed wake already, getting dmesg now |
05:00.38 | arrrghhhTP2 | Lolut |
05:00.45 | arrrghhhTP2 | lolwut |
05:01.18 | WisTilt2 | yeah need to see log on the fails now. like that quick sleep and it really is shutting down that quick now |
05:01.22 | jonpry | hrm, that is seriously not linear towards the end |
05:02.40 | jonpry | http://imagebin.org/139972 |
05:05.24 | WisTilt2 | looks like when it got in the 3530 range it hung in that same area. do these batts do that when they're nearly discharged? dont know what the voltage is that is considered discharged on them |
05:06.03 | WisTilt2 | i never see my normal phone below 3700 or so then i charge it so 3500 sounds like its almost dead |
05:06.38 | jonpry | it should go lower |
05:06.54 | jonpry | and capacity should drop off faster, unless it is throttling the phone somehow |
05:07.13 | arrrghhhTP2 | WisTilt2: |
05:07.25 | arrrghhhTP2 | Crap |
05:07.47 | WisTilt2 | what happened? |
05:07.54 | arrrghhhTP2 | http://db.tt/P5KF51V |
05:08.00 | arrrghhhTP2 | ^^ |
05:08.07 | arrrghhhTP2 | I suck at using my phone :P |
05:08.39 | WisTilt2 | what am i looking for? |
05:08.52 | arrrghhhTP2 | Failed wake |
05:09.02 | arrrghhhTP2 | I didn't pull it with adb |
05:09.09 | arrrghhhTP2 | Same cycle tho |
05:09.11 | jonpry | the model generated from new data set is close, but not the same. and yields this http://imagebin.org/139975 |
05:09.26 | arrrghhhTP2 | Failed wake, then successful wake & logs pulled |
05:09.28 | WisTilt2 | seems like you get them shortly after booting mainly? |
05:09.30 | *** join/#htc-linux opdf2 (~asdfsd@c-67-173-70-13.hsd1.il.comcast.net) |
05:10.00 | arrrghhhTP2 | WisTilt2: I swear the phone had settled down... |
05:10.41 | arrrghhhTP2 | Maybe not |
05:10.43 | WisTilt2 | but sleeps are fast now and wakes nearly everytime after that one? |
05:10.49 | arrrghhhTP2 | I can sign off and test more |
05:10.51 | arrrghhhTP2 | Yup |
05:11.00 | arrrghhhTP2 | Didn't test too extensively |
05:11.08 | WisTilt2 | ok hit it numerous times |
05:11.24 | arrrghhhTP2 | Let me continue to test, unless you have some more madness? |
05:11.45 | WisTilt2 | i have one more change for you but go ahead and hit that one for a few first |
05:11.59 | arrrghhhTP2 | Heh ok |
05:12.11 | jonpry | WisTilt2, http://imagebin.org/139976 seconds model on first dataset |
05:12.12 | WisTilt2 | jonpry: is that blue line the model still? looks pretty close but not as close as without the heavier load |
05:12.25 | jonpry | blue is model |
05:12.52 | jonpry | i don't know that we are looking for close |
05:12.56 | WisTilt2 | i think its closer to the model on the second one |
05:12.59 | jonpry | looking for correct |
05:13.15 | jonpry | so for instance we know that correct is monotonic |
05:13.29 | jonpry | where as the red line is not even close |
05:14.07 | jonpry | and it should also be linear? |
05:14.14 | arrrghhhTP2 | Not sure if it's this app or what but it's taking 5-6s to sleep |
05:14.46 | jonpry | i think the model from your second data set it *way* better |
05:15.02 | WisTilt2 | sleep should always be around 1s now unless a background task is keeping it up |
05:15.40 | WisTilt2 | jonpry: yes i think if we were all over the map compared to the model we'd have a problem. i think this, with some fine tuning, should work pretty well |
05:15.56 | jonpry | WisTilt2, was it fully charged when you started? |
05:16.15 | WisTilt2 | on that second test it was showing 96% in winmo |
05:16.31 | WisTilt2 | i think the previous was 89% |
05:18.03 | arrrghhhTP2 | Let me quit then. |
05:18.28 | jonpry | WisTilt2, do you know if charge current is registering correctly? |
05:18.51 | jonpry | like it should go down with system load and such |
05:18.52 | *** join/#htc-linux Kasjopaja23 (~Tina@p579C1226.dip.t-dialin.net) |
05:19.44 | WisTilt2 | havent looked at what it reads with charger plugged in. is that what you mean? i can run it with charger and see what kind of current values it shows |
05:21.17 | jonpry | yeah with charger |
05:22.54 | *** join/#htc-linux arrrghhhTP2 (~arrrghhh_@107.29.229.114) |
05:23.21 | jonpry | trouble with numerical code is the fine tuning |
05:23.35 | arrrghhhTP2 | WisTilt2: http://db.tt/hPBUuGGh |
05:23.53 | WisTilt2 | interesting. panel on im seeing the similar current values as the last data but when i plug in charger after about 5secs current goes to zero and never changes. unplug charger and few secs later it shows values again |
05:24.07 | jonpry | yeah its in two different locations |
05:24.20 | jonpry | positive one place, negative another :p |
05:24.22 | WisTilt2 | oh |
05:24.30 | *** join/#htc-linux GhostMan (~Duper@46-116-51-174.bb.netvision.net.il) |
05:24.30 | WisTilt2 | arrrghhh: invalid paste |
05:24.50 | WisTilt2 | ill have to find that other location then |
05:25.36 | arrrghhhTP2 | Crap |
05:26.31 | arrrghhhTP2 | http://db.tt/hPBUuGG |
05:26.42 | arrrghhhTP2 | I guess I hit h lol sorry |
05:26.44 | *** join/#htc-linux ImCoKeMaN (~imcokeman@pool-96-249-148-95.hrbgpa.fios.verizon.net) |
05:26.51 | *** join/#htc-linux kvaster (~kvaster@93.84.112.82) |
05:27.01 | arrrghhhTP2 | Anyhoo, closed the app and sleep was fast again - awesome |
05:27.10 | WisTilt2 | try this kernel while i look over that one fecc2ed534bd251769f9be95fe683b9a |
05:27.17 | arrrghhhTP2 | But one complete failed wake, then a realllly slow wake |
05:27.27 | arrrghhhTP2 | And pulled logs |
05:27.38 | arrrghhhTP2 | Crap, I must go to bed dude... |
05:27.55 | WisTilt2 | ok np. its up there when you get a chance |
05:28.01 | arrrghhhTP2 | goin on vaca for the next week |
05:28.08 | arrrghhhTP2 | Gf is not happy lol |
05:28.19 | arrrghhhTP2 | I'll check it out tomorrow, thx dude. |
05:28.21 | WisTilt2 | damn, going to be weird without the super tester in here |
05:28.30 | jonpry | WisTilt2, you have htc_battery_smem.c? |
05:28.34 | arrrghhhTP2 | I'll still be around methinks. |
05:28.50 | WisTilt2 | k, image is on the server when you can |
05:28.51 | arrrghhhTP2 | Just goin on a snowboard trip, so days will be busy :D |
05:28.55 | arrrghhhTP2 | Thx dude |
05:28.59 | arrrghhhTP2 | Peace guys |
05:29.00 | WisTilt2 | ill be around tomorrow until noon or so |
05:29.07 | WisTilt2 | jonpry: yes |
05:29.20 | jonpry | so in htc_get_batt_smem_info() |
05:29.31 | jonpry | it extracts the data from the smem region |
05:29.44 | jonpry | i dunno what our smem_field_size is |
05:30.25 | WisTilt2 | ours is 4 |
05:30.40 | jonpry | but topaz is 2? |
05:30.51 | jonpry | same amss |
05:30.57 | WisTilt2 | yep and diamond also |
05:31.22 | WisTilt2 | wait, battery smem size you mean... |
05:31.23 | jonpry | so batt_32->batt_discharge is other one |
05:31.37 | WisTilt2 | on rhod its 4 |
05:31.40 | jonpry | smem_field_size |
05:33.14 | WisTilt2 | so batt_discharge is what we read during charge? |
05:33.15 | jonpry | i dunno what your setup looks like, but discharge is just the u32 after charge |
05:33.24 | jonpry | yeah i think they are backwards |
05:33.28 | WisTilt2 | figures |
05:34.48 | jonpry | and if your using code from htc_battery, it fails to copy that value from smem to its little voodoo buffer |
05:35.06 | rpierce99 | WisTilt2: I know you and arrrghhh have a good thing going, and I don't even want to do all the crap he does, but if you just need to bounce a kernel off a rhod400 feel free to hit me up |
05:35.46 | WisTilt2 | thanks rpierce99, you've tested a few of them yourself:) |
05:36.20 | rpierce99 | i've tested all of them, just filtered my feedback through arrrghhh until recently :) |
05:36.30 | WisTilt2 | you have the url to get the test image still? |
05:37.03 | rpierce99 | never have, always got the public build |
05:42.34 | jonpry | http://imagebin.org/139984 |
05:42.47 | jonpry | WisTilt2, graph of calculated and measured voltage |
05:43.22 | jonpry | its almost totally linear. i guess the distortions in the other graphs were from my linearizer |
05:43.36 | WisTilt2 | i like |
05:44.42 | jonpry | i do not understand :p |
05:45.18 | jonpry | 0% is 3.186 volts :p |
05:47.34 | WisTilt2 | that cant be right? isnt that way too low. maybe i just dont let mine get discharged that much, always charge when its no lower than 40% or so and voltage is still in the 3500 range i thought |
05:48.46 | jonpry | well its apparently not. the curves i got from ds2746 are just distorters |
05:51.05 | jonpry | it looks like bulk capacitance is constantish until 3.7V |
05:51.26 | jonpry | and its all over but the shouting at 3.4 |
05:52.45 | WisTilt2 | are there any specs for these batts that show soc voltages? |
05:52.59 | jonpry | no |
05:53.06 | jonpry | its a figure it out game |
05:53.09 | *** join/#htc-linux AstainHellbring (AstainHell@unaffiliated/astainhellbring) |
05:53.54 | jonpry | WisTilt2, i'm pretty sure we could analyze it out of a battery, but people would have to run it down. just fully charge, and let it die |
05:54.20 | *** join/#htc-linux BoominSVX (421f78ad@gateway/web/freenode/ip.66.31.120.173) |
05:54.28 | jonpry | but it might be constant for whatever chemistry is in them |
05:54.55 | BoominSVX | Maybe thats why I have to let my phone charge for 10 minutes if the batt dies before it'll turn on. |
05:55.02 | jonpry | and we could also ask cotulla to download curves from hd2's ds2746 |
05:55.32 | jonpry | BoominSVX thats because the phone draws more current than the charger can supply |
05:55.32 | WisTilt2 | i can do that and pull data until it dies. just need to output to sd card as i go so i dont lose the data |
05:56.12 | jonpry | i don't think its worth it for now. its like another layer of regressions |
05:56.44 | jonpry | we need to get something confirmed correct before we can start using the data for more stuff |
05:56.46 | BoominSVX | jonpry: when it dies in winmo, i can plug it in and turn it right on. Just seemed to me that android discharged it lower. |
05:56.57 | jonpry | oh it does |
05:57.02 | WisTilt2 | jonpry: that brings up a question... why are the current numbers only in the less than 100 range under load. certainly these devices draw more than 100ma with everything on dont they? |
05:57.38 | jonpry | i would think so |
05:57.52 | jonpry | but you just have panel on, not processor maxed out |
05:58.00 | WisTilt2 | yeah true |
05:58.08 | jonpry | i mean panel is 20ma @ 27V? |
05:58.30 | WisTilt2 | so the current values we're seeing are probably about right you think? |
05:58.49 | jonpry | is backlight on max? |
05:58.54 | WisTilt2 | yes |
05:59.01 | jonpry | might be low |
05:59.14 | WisTilt2 | thats why this last test got the phone so warm after 4hrs |
05:59.41 | jonpry | and 4 hours @ 80ma, only 320mah |
05:59.47 | jonpry | but battery almost dead |
05:59.53 | BoominSVX | jonpry: BTW, I have a confession. The carribean does not eat TP2's |
06:00.04 | WisTilt2 | lol |
06:00.16 | jonpry | what about wozzer's? |
06:00.16 | BoominSVX | My computer chair does. |
06:00.22 | BoominSVX | No idea |
06:00.30 | jonpry | hmm |
06:00.40 | jonpry | you didn't send it? |
06:01.07 | BoominSVX | No. I killed it. |
06:01.19 | jonpry | i thought the 18 wheeler did that |
06:01.27 | BoominSVX | That was the other one |
06:01.36 | BoominSVX | You were getting the horse trailer one |
06:01.50 | jonpry | ? |
06:02.10 | BoominSVX | I crushed it in the door of a horse trailer. :) |
06:02.57 | jonpry | so you lost 2 tp2's to mass destruction? |
06:03.16 | BoominSVX | There was nothing left of the Industrial Park Demolition Challange 2010 |
06:03.44 | jonpry | my god |
06:03.48 | BoominSVX | 3 actually, and I'm on boost so no service plans or insurance |
06:04.19 | jonpry | thats horrible |
06:04.56 | WisTilt2 | rpierce99: did that kernel blow up your phone? |
06:05.04 | jonpry | WisTilt2, it does not actually matter if the current is off by some factor. just model capacitance comes out different by same factor etc. |
06:05.05 | BoominSVX | anyway, sorry buddy. I feel like a d!ck, but it's been eating me up. I feel better now having confessed. |
06:05.22 | jonpry | yeah its ok |
06:05.28 | jonpry | we fixed the sound anyways |
06:05.37 | rpierce99 | WisTilt2: haha, being that this is the first that I've downloaded from you, when it didn't boot I assumed it was me doing something stupid |
06:05.44 | BoominSVX | :) I know! |
06:06.15 | WisTilt2 | forgot to tell you about the bootup, makes it look like phone locked up |
06:06.24 | jonpry | WisTilt2, thing is we need same units on charge and discharge, although we may be able to infer the relationship |
06:06.36 | rpierce99 | WisTilt2: no it's not that, I'm on one of those now, haret hangs |
06:06.37 | WisTilt2 | should get to the unlock screen in about 90secs or so though |
06:06.51 | rpierce99 | so i'm pretty sure I"m doing something dumb |
06:07.10 | BoominSVX | WisTilt2: kernel-pack.zip? I've got about 15 mins before I have to leave, but I can check it out tonight. |
06:07.16 | WisTilt2 | jonpry: got zero out of that location with and without charger |
06:07.26 | jonpry | f$%^&* |
06:07.45 | WisTilt2 | BoominSVX you have the url right? |
06:07.57 | BoominSVX | just need to know whats it's called |
06:08.26 | WisTilt2 | wistilt2-kernel-pack.zip |
06:09.00 | WisTilt2 | rpierce99: do you get the vibrate from haret or does it not get that far? |
06:09.07 | rpierce99 | nope |
06:09.54 | BoominSVX | WisTilt2: got it |
06:10.00 | WisTilt2 | thats not the kernel its something else then. it works with the posted stuff ok though? |
06:10.37 | jonpry | WisTilt2, what do we do then? |
06:10.39 | WisTilt2 | rpierce99 get the kernel pack and try it |
06:10.52 | jonpry | PMIC can measure this. why don't we have it? |
06:11.15 | rpierce99 | I think the transfer off my VM onto the phone botched it somehow, downloaded directly from the mac and put it on there and it worked fine |
06:11.17 | WisTilt2 | jonpry: im going to make sure that is the right smem addy, might not be correct |
06:11.30 | rpierce99 | that's why I wasn't saying anything, I knew it was something on my end |
06:11.42 | jonpry | need to find catptnoord |
06:11.52 | jonpry | er captnoord |
06:13.00 | bzo | haven't seen him in many months |
06:13.01 | jonpry | maybe somebody on xda can tell us if there is winmo app with negative currents |
06:13.44 | jonpry | hey bzo |
06:13.57 | bzo | nice progress on the battery algo |
06:14.03 | jonpry | thanks |
06:14.19 | jonpry | i think it will work for us |
06:14.56 | bzo | so what is left to do? |
06:15.11 | jonpry | well we are missing a linearizer |
06:15.16 | jonpry | i thought i had one :p |
06:15.21 | rpierce99 | WisTilt2: do you want logs for failed wakes? |
06:15.40 | jonpry | and it is hard to turn some algorithm into an actual application |
06:15.47 | WisTilt2 | maybe one, they'all be the same |
06:16.11 | jonpry | it needs to have code for reading configs and command line crap |
06:16.37 | jonpry | do logs, read save state... |
06:16.40 | jonpry | maybe UI |
06:16.59 | rpierce99 | [ 232.396484] msmfb_start_dma 6940.000 ms after vsync request |
06:17.05 | bzo | meh it's always this way, exciting intial work, then the mundane task of making it usable |
06:17.40 | rpierce99 | full log http://pastebin.com/uS29a7cn |
06:17.41 | WisTilt2 | rpierce99: same error. if you dont get any different ones we're good |
06:18.29 | rpierce99 | WisTilt2: but the sleeps and wakes are amazing |
06:18.32 | rpierce99 | very fast |
06:18.34 | jonpry | WisTilt2, i'm using some stupid app on winmo, battlog. it has current while charging and not |
06:19.02 | jonpry | but its much higher while charging |
06:19.19 | WisTilt2 | is it showing negative while charging? |
06:19.29 | jonpry | no |
06:20.12 | WisTilt2 | rpierce99 yeah fast sleep now and as fast wakes. boot up time should be much faster too. try switching to app menu then back to desktop, should be instant |
06:20.54 | WisTilt2 | jonpry: i can have it display that part of smem and see which offset is changing when charger is plugged in to find it |
06:21.07 | jonpry | sounds like a reasonable plan |
06:21.09 | WisTilt2 | i know one goes to zero |
06:21.14 | jonpry | :p |
06:21.25 | WisTilt2 | cant be too far off address wise |
06:21.40 | jonpry | i wouldn't think so |
06:21.44 | rpierce99 | in zeam it doesn't seem much different, it's animated though so I'm not sure it would be different |
06:21.53 | jonpry | bzo, devil is in the details |
06:22.52 | bzo | jonpry, it sure is. Just like at the camera stuff, it started 2 months ago, and it may finally get committed this weekend |
06:23.17 | bzo | err, started working 2 months ago |
06:24.48 | bzo | wonder if jb knew what he was getting into. He must be relieved to finally hand it off |
06:24.51 | rpierce99 | found an option to turn off the animated app drawer, it is very quick |
06:24.59 | WisTilt2 | rpierce99 what kind of battery life you getting with that last posted test kernel? |
06:25.38 | jonpry | bzo i'm excited to get camera anyways |
06:25.44 | rpierce99 | I'm usually on the lower end of the rhod400s with all the apps I have syncing, with light use I can go 12-14 hours |
06:26.14 | WisTilt2 | overnight in sleep with sync should get you under 1% per hr |
06:26.22 | WisTilt2 | this kernel will get a bit more |
06:26.32 | jonpry | 4 days? |
06:26.58 | bzo | WisTilt2: are rhod400/500 testers reporting < 1% per hour? |
06:27.24 | manekineko | yeeah, I see that power consumpmtion |
06:27.27 | manekineko | on my rhod400 |
06:27.33 | WisTilt2 | yes several. one reported .3% over a 10-12hr period in sleep |
06:27.40 | rpierce99 | I'll do a drain test tonight, i'll charge it now and when I go to sleep I'll leave it off the charger, should I boot back to winmo to get the final battery reading? |
06:27.43 | bzo | any auto syncing of apps manekineko? |
06:27.47 | WisTilt2 | i average around .5 |
06:28.07 | manekineko | I have all Google Sync on |
06:28.12 | bzo | damn, I've never gotten better than 1.7% |
06:28.24 | manekineko | Gmail, calendar, tasks, reader, uhh everything I guess |
06:28.29 | manekineko | contacts |
06:28.30 | rpierce99 | talk? |
06:28.32 | manekineko | talk |
06:28.36 | manekineko | chrome2phone |
06:28.38 | rpierce99 | reader? |
06:28.40 | manekineko | yup |
06:28.44 | manekineko | I like the Google apps hehe |
06:28.49 | rpierce99 | as do i |
06:28.51 | manekineko | nothing non-Google though other than ClockSync |
06:28.53 | bzo | wow, that's great with all that network activity |
06:29.01 | WisTilt2 | rpierce99: after you take it off charge, use data a bit and get the battery down a bit then let it sit until it doesnt change and calc from there |
06:29.01 | bzo | way better than winmo |
06:29.03 | manekineko | yeah, I get better battery life in Android than WinMo |
06:29.17 | manekineko | it is a bit erratic though |
06:29.19 | bzo | who would have though that even a few months ago |
06:29.32 | manekineko | sometimes battery life is phenomenal, sometimes not so much |
06:29.52 | WisTilt2 | manekineko which kernel you running? |
06:30.00 | manekineko | your test kernel, latest posted by arrrghhh |
06:30.11 | rpierce99 | WisTilt2: so start the test the moment it says it's fully charged in android, and get the final reading in the morning from android also? |
06:30.55 | WisTilt2 | ok. that one is good on power. this one is better by a little bit and arrrghhh will post it tomorrow. other enhancements in this one too |
06:31.08 | manekineko | sweet |
06:31.12 | manekineko | I don't suppose netloc is one of them? hehe |
06:31.56 | WisTilt2 | rpierce99 no, after charger is off do browsing or play sound or whatever for a few then let it settle until it stays on the same value and go from that point |
06:32.12 | WisTilt2 | its really not accurate until below 90% anyway |
06:32.20 | rpierce99 | ok so I just want to get a stable reading |
06:32.26 | WisTilt2 | correct |
06:33.03 | rpierce99 | so should I not charge it all the way up if >90% is inaccurate anyways |
06:33.11 | rpierce99 | i'm sure I won't need all 100% for 8 hours |
06:33.11 | WisTilt2 | manekineko nope not yet |
06:33.32 | WisTilt2 | close to 90% should be perfect |
06:33.42 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
06:33.51 | jonpry | bzo: have to get it built for arm too :p |
06:34.23 | bzo | jonpry: lol, your userland code is running on x86? |
06:34.34 | jonpry | well yeah :p |
06:35.15 | jonpry | thats the beauty of userland |
06:35.50 | bzo | tru, could be said about any modularized code |
06:36.08 | WisTilt2 | z80, thats serious stuff |
06:36.28 | WisTilt2 | or 8080? |
06:36.31 | jonpry | run on z80? |
06:36.38 | jonpry | would never get done |
06:36.51 | jonpry | its like teraflop |
06:36.51 | WisTilt2 | just thinking about the good old days |
06:37.04 | bzo | what was that consumer pc that ran on the z80, the sinclair or sth? |
06:37.15 | jonpry | i had a kaypro |
06:37.28 | jonpry | but nes was z80 |
06:37.37 | WisTilt2 | vector graphic or dont forget the good old trs-80 |
06:38.01 | bzo | ah, here it is: http://en.wikipedia.org/wiki/ZX81 |
06:38.03 | jonpry | c64 was 8080 |
06:38.05 | WisTilt2 | vector graphic with cpm os was the thing |
06:38.11 | bzo | was thinking we had come full circle with the chicklet keyboard |
06:38.11 | jonpry | oh yeah |
06:39.10 | jonpry | oO |
06:39.18 | bzo | lol, 1kB memory, 64kB max |
06:40.35 | jonpry | ram/rom? |
06:41.02 | bzo | ram I would think |
06:41.37 | bzo | good ol c64 was probably the first computer I really used though |
06:42.08 | jonpry | somewhat before my time :p |
06:42.20 | WisTilt2 | did you ever see the print spooler program for the c64? |
06:42.46 | WisTilt2 | or sargon chess? |
06:43.13 | bzo | eh, only remember programming in basic on the c64 |
06:43.50 | manekineko | hah, speaking of eratic battery life, my phone just got hit by the bug that drains it out while connected to the charger... |
06:44.31 | WisTilt2 | selling back to the grid huh? |
06:44.42 | manekineko | lol yup |
06:44.45 | manekineko | that's the pro side |
06:44.50 | manekineko | not having to pay for electricity anymore |
06:44.51 | bzo | jonpry: is the original mac more in your time? |
06:45.00 | jonpry | nope |
06:45.15 | jonpry | that's like 1976 |
06:45.29 | jonpry | but all mac's are too old for me |
06:45.34 | bzo | nah, mac is more current than that |
06:45.38 | bzo | even lisa |
06:45.41 | jonpry | always like last years hardware |
06:46.10 | jonpry | er 1986 |
06:46.30 | jonpry | apple IIe |
06:46.57 | jonpry | first computer i saw |
06:47.14 | *** join/#htc-linux cazh_ (~quassel@3007ds2-rd.0.fullrate.dk) |
06:47.25 | BoominSVX | I've still got a commador 64 7 floppies for oregon trail was the best |
06:47.45 | jonpry | it is 1976 |
06:47.45 | bzo | loved the apple iis, hate apple now |
06:47.46 | jonpry | http://en.wikipedia.org/wiki/Apple_I |
06:48.40 | WisTilt2 | i feel old now. my first computer was one i built, Heathkit H8 |
06:48.52 | WisTilt2 | late 70's |
06:49.12 | jonpry | at least its newer than apple I |
06:49.32 | bzo | haha, almost the analog age of computers |
06:49.57 | rpierce99 | my first computer was an 386SX, I was in the 4th grade, we had to buy a DX2 upgrade chip and cache seperately |
06:50.19 | manekineko | man that was a sweet machine when it came out |
06:50.21 | bzo | heathkit was awesome though |
06:50.28 | manekineko | I was so jealous of my friend that had one and its EGA graphics |
06:50.29 | jonpry | to get that floating point that rhod doesn't have? |
06:51.17 | WisTilt2 | yeah heathkit was great. i got my ham radio license in 1965 and heathkit had all the goodies for amateur radio back then |
06:52.37 | bzo | unfortunately heathkit was in the process of shutting down when I was a kid |
06:53.09 | WisTilt2 | BoominSVX: you get that kernel booted? |
06:53.30 | jonpry | ok, must sleep, ttyl |
06:53.36 | bzo | gn |
06:53.44 | WisTilt2 | nite jonpry, we'll work on the charge number tomorrow |
06:53.50 | BoominSVX | yes. i seem to be lacking in dropbox though |
06:54.19 | WisTilt2 | you mean log info not there? |
06:54.43 | BoominSVX | no last kmesg. Thats what i get for running a no vanilla build |
06:54.58 | rpierce99 | BoominSVX: have you rebooted? I don't think dropbox populates until the next book, it reads in the old kmsg |
06:55.08 | WisTilt2 | i had it disabled but thought i turned it back on in this kernel |
06:55.24 | BoominSVX | just 316b last kmesg |
06:55.40 | BoominSVX | and system-tombstones |
06:55.48 | BoominSVX | yes, i rebooted to check |
06:55.52 | *** join/#htc-linux CazH (~quassel@3007ds2-rd.0.fullrate.dk) |
06:55.59 | rpierce99 | oh ok |
06:56.15 | WisTilt2 | i must still have that disabled then. what do you think about the sleep wake times now? |
06:57.13 | BoominSVX | WisTilt2: It's beautiful. Even on a backlight on/blank screen, it comes right back... and quick |
06:57.31 | WisTilt2 | sleep happening within 1second? |
06:57.50 | BoominSVX | I use ADW so it may be hindering the speed. |
06:57.57 | BoominSVX | sleep almost instant, yes |
06:58.01 | WisTilt2 | what phone? |
06:58.13 | BoominSVX | Rhod 400 |
06:58.30 | WisTilt2 | should work the same on all rhods hopefully |
06:59.00 | BoominSVX | I can't wait till your stuff gets in the autobuild |
06:59.31 | BoominSVX | we all appreciate you friend. |
06:59.50 | WisTilt2 | wont commit it until i get the damn occasional non-wake issue completely squashed. |
07:00.49 | BoominSVX | yea, perfection is seldom achieved, but your closer than ever now. |
07:00.54 | WisTilt2 | bzo: will we gain anything by having a 256k ramconsole? its working very nice, especially in ebi instead of smi |
07:01.41 | bzo | doesn't seem like having a 128k buffer has been a problem for anyone |
07:01.47 | bzo | but hey, what's another 128k? |
07:02.20 | WisTilt2 | we dont have anything at ebi base i guess? thats where im running it and nothing stepping on it at all now |
07:02.44 | bzo | we do need to explicitly carve out a region for it |
07:02.46 | BoominSVX | WisTilt2: I do have one tiny little suggestion though. The keyboard bl... does it time out a little quick or is it just me? |
07:02.56 | bzo | you've probably just been lucky nothing is writing there |
07:03.17 | WisTilt2 | 5seconds, which was the default when i started in all this |
07:04.08 | *** join/#htc-linux Noellenchris (~kvirc@pool-173-61-114-241.cmdnnj.fios.verizon.net) |
07:04.32 | WisTilt2 | could increase that timeout to 10s |
07:04.48 | BoominSVX | I know, I don't mean anything by it. Just seems that 10 or 15 wouldn't hurt anything |
07:05.19 | BoominSVX | I time out quiet a bit, but maybe i'm just a slow texter. |
07:05.31 | WisTilt2 | it resets when typing but i think 5s might be too low if you pause while typing |
07:06.18 | WisTilt2 | let me change that to 10s... then when arrrghhh puts it up for the masses we'll see what kind of response we get |
07:07.24 | BoominSVX | yea, its not exactly a power hog, I guess we'll see what the masses say then |
07:08.12 | WisTilt2 | ok get this kernel pack. 10seconds timeout now |
07:08.32 | BoominSVX | I'll play with this kernel tonight and let arrrghhh know if I can find anything useful. Gotta get out of here. |
07:08.41 | WisTilt2 | ok sounds good. |
07:09.05 | BoominSVX | Thank you sir!! g'night |
07:09.36 | *** join/#htc-linux MacDrunk (~marper@201.165.161.195) |
07:10.27 | XirXes | same place as usual right WisTilt2? |
07:11.07 | *** join/#htc-linux cazh_ (~quassel@3007ds2-rd.0.fullrate.dk) |
07:11.34 | WisTilt2 | yep |
07:20.32 | WisTilt2 | XirXes: if you run with autobl off, you might want to dl the kernel pack i just put up that fixes it when in manual mode. |
07:22.50 | XirXes | i do run with auto bl on but ill dl the newest one anyway |
07:23.14 | WisTilt2 | k. thats the one arrrghhh will put up so you'll match that one |
07:24.21 | XirXes | what was all the stuff that isnt in the flying text anymore? |
07:25.03 | WisTilt2 | wasted cpu cycles as i like to call it |
07:25.12 | XirXes | lol indeed |
07:26.01 | WisTilt2 | just kernel boot that you cant read anyway as it flys off the screen and cant scroll back. its all in dmesg still |
07:28.54 | XirXes | it boots so much faster now |
07:29.40 | WisTilt2 | yep. wait until you see sleep |
07:30.14 | XirXes | i just barely let it sleep. pretty much instant |
07:30.33 | XirXes | didnt really get the oportunity to blink |
07:31.14 | XirXes | when i woke it back up it was instant too. i saw the black square tho |
07:31.34 | WisTilt2 | black square in upper left corner? |
07:32.09 | XirXes | thats the one |
07:32.35 | WisTilt2 | dont know what that is yet as its not always there |
07:33.16 | XirXes | i never noticed it before the move to 35 framebuffer so i assume its related but idk |
07:33.16 | WisTilt2 | if you get a non-wake just put it back to sleep and it will wake on next attempt. still working out this pan_display problem that happens now and then |
07:37.03 | XirXes | your really getting this thing running nice. i definitly feel like it does better than my g1 these days |
07:37.05 | *** join/#htc-linux rpierce99_ (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
07:37.10 | XirXes | not my g2 tho |
07:37.21 | XirXes | but that cant be helped |
07:38.57 | WisTilt2 | should be a bit more stable now. well see how it goes and let arrrghhh or myself know if there are any strange things we dont already know about. |
07:39.12 | WisTilt2 | im going to bed. catch you guys later |
07:39.25 | XirXes | night |
07:46.50 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
07:53.01 | *** join/#htc-linux Termana (~bradley@122.151.90.7) |
08:15.15 | *** join/#htc-linux Zeman4323 (~Zeman4323@CPE-65-30-190-208.wi.res.rr.com) |
08:18.17 | *** join/#htc-linux MacDrunk (~marper@201.165.161.195) |
08:31.10 | *** join/#htc-linux venom00ut (~venom00@unaffiliated/venom00) |
08:35.51 | *** join/#htc-linux GlemSom (~glemsom@0x5da34bca.cpe.ge-1-1-0-1105.sdnqu1.customer.tele.dk) |
09:05.07 | *** join/#htc-linux onen|openBmap (~quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
09:07.47 | *** join/#htc-linux CazH (~quassel@3007ds2-rd.0.fullrate.dk) |
09:12.34 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
09:23.14 | *** join/#htc-linux rob_w (~bob@ppp-188-174-88-17.dynamic.mnet-online.de) |
09:23.46 | *** join/#htc-linux rob_w (~bob@ppp-188-174-88-17.dynamic.mnet-online.de) |
09:25.44 | *** join/#htc-linux kvaster (~kvaster@93.84.112.82) |
09:35.13 | *** join/#htc-linux _twitch (~burning_a@64.112.96.58.static.exetel.com.au) |
09:36.34 | *** join/#htc-linux emwe (~emwe@cable-86-56-10-158.cust.telecolumbus.net) |
09:53.05 | *** join/#htc-linux greg- (greg-@port-4488.pppoe.wtnet.de) |
10:07.18 | *** join/#htc-linux balans1 (~Gebruiker@82-170-217-205.ip.telfort.nl) |
10:09.03 | *** join/#htc-linux cazh_ (~quassel@3007ds2-rd.0.fullrate.dk) |
10:13.17 | *** join/#htc-linux venom00ut (~venom00@unaffiliated/venom00) |
10:41.44 | *** join/#htc-linux camro (~camro@89-104-29-101.customer.bnet.at) |
10:50.46 | *** join/#htc-linux Erikson (~Erik@p54B76F26.dip.t-dialin.net) |
10:57.55 | *** join/#htc-linux bja (~bja@c-24-1-253-181.hsd1.il.comcast.net) |
11:19.04 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
11:19.17 | *** join/#htc-linux HD2Owner (57f54144@gateway/web/freenode/ip.87.245.65.68) |
11:19.32 | *** join/#htc-linux jameschurchman (u220@gateway/web/irccloud.com/x-yowbbswivngulaxh) |
11:40.31 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
11:53.17 | *** join/#htc-linux venom00ut (~venom00@unaffiliated/venom00) |
11:55.52 | *** join/#htc-linux kiozen (~kiozen@rgnb-4d053f3a.pool.mediaWays.net) |
12:03.41 | NetRipper | dcordes_, pong |
12:03.42 | NetRipper | sup? |
12:05.09 | NetRipper | dcordes_, if it's about Photon.. Cotulla worked on that and just tar.gz'd his source of both haret and the kernel |
12:05.17 | NetRipper | dcordes_, http://forum.xda-developers.com/showthread.php?t=952996 |
12:06.57 | NetRipper | dcordes_, if it's about htc-linux wiki.. the spamming has stopped, but i can't find a decent automated way to clear the wiki of all spam |
12:30.13 | *** join/#htc-linux dekar_ (~dekar@drms-590ed8af.pool.mediaWays.net) |
12:36.23 | *** join/#htc-linux LordDeath (~Lord|Lapt@cable-81-173-166-52.netcologne.de) |
12:41.57 | *** join/#htc-linux MassStash (~MassStash@c-67-175-41-173.hsd1.il.comcast.net) |
13:04.03 | *** join/#htc-linux D3tul3 (~Oliver@cpe-174-109-223-235.nc.res.rr.com) |
13:06.36 | *** join/#htc-linux GNUtoo|laptop (~gnutoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
13:09.52 | dcordes_ | NetRipper: yoo just chilling :) is the NL weather as nice as the Bavarian today ? |
13:10.04 | NetRipper | you mean gray and depressing? |
13:10.04 | dcordes_ | NetRipper: the cookie thing was temprary it works now |
13:10.05 | NetRipper | then yes |
13:10.09 | dcordes_ | NetRipper: thanks a lot :) |
13:10.16 | dcordes_ | :( |
13:10.44 | NetRipper | yea you have to allow session cookies for captcha to work |
13:10.56 | NetRipper | it's allowed by default on any browser |
13:11.06 | dcordes_ | did you create the custom captcha ? |
13:11.29 | dcordes_ | ya that's why I was wondering.. think I had it enabled. I'm using firefox 4 beta |
13:11.37 | dcordes_ | maybe that caused the problem |
13:11.46 | NetRipper | yea modified some existing php captcha to make it custom.. it's not a popular captcha so it's not auto-cracked or auto-send-to-chinese-that-get-paid-for-decipheering |
13:11.52 | dcordes_ | updated the [[Photon]] page with kernel and haret source link |
13:11.52 | unili882 | http://htc-linux.org/wiki/index.php?title=Photon |
13:12.03 | dcordes_ | and tweeted it |
13:12.06 | NetRipper | k |
13:12.14 | NetRipper | been there a while though :P |
13:12.28 | dcordes_ | nvm |
13:13.14 | NetRipper | i had updated the main page news thingy for it |
13:13.35 | dcordes_ | ah I thought it was Cotulla |
13:13.44 | *** join/#htc-linux LuHe (~LuHe@91-118-60-155.dynamic.adsl-line.inode.at) |
13:13.48 | NetRipper | cotulla made the photon and photonstatus pages |
13:14.12 | dcordes_ | ok |
13:15.14 | dcordes_ | hmm |
13:15.49 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
13:16.39 | dcordes_ | GNUtoo|laptop: didn't manage to prepare SHR for the HD2 yet |
13:17.07 | GNUtoo|laptop | dcordes_, hi |
13:17.09 | GNUtoo|laptop | ok |
13:17.13 | GNUtoo|laptop | but did you get the image? |
13:17.14 | *** join/#htc-linux RaiderX (5b6d2a71@gateway/web/freenode/ip.91.109.42.113) |
13:17.28 | RaiderX | hi |
13:19.55 | *** join/#htc-linux phh (~quassel@2a01:e35:2e4b:b2b0:250:8dff:fee1:c793) |
13:20.38 | dcordes_ | GNUtoo|laptop: 5d8d3a722cb6ae192a5e8e3a31d5ecab full-htcdream.tar.gz |
13:20.45 | dcordes_ | GNUtoo|laptop: is it the correct md5 ? |
13:21.31 | GNUtoo|laptop | dcordes_, no |
13:22.02 | dcordes_ | GNUtoo|laptop: ok then I should download it again |
13:22.04 | GNUtoo|laptop | dcordes_, the images was supposed to come from my server and to be a bit customized for the nexusone |
13:22.32 | dcordes_ | GNUtoo|laptop: is it compiled for cortex-a8 ? |
13:22.52 | dcordes_ | GNUtoo|laptop: we need to convince cotulla ;) the cortex image booted in < 10 secs for me |
13:22.58 | GNUtoo|laptop | dcordes_, yes, for n900 |
13:23.04 | dcordes_ | cool |
13:25.00 | GNUtoo|laptop | dcordes_, I'll PM you for the address of the file |
13:25.20 | dcordes_ | GNUtoo|laptop: thanks |
13:34.02 | *** join/#htc-linux RaiderX_ (5b6d2a71@gateway/web/freenode/ip.91.109.42.113) |
13:49.08 | *** join/#htc-linux gauner1986 (~Miranda@p5B382CEE.dip.t-dialin.net) |
13:50.46 | dcordes_ | bbl |
13:52.43 | *** join/#htc-linux Christie (~Esa@adsl-71-156-47-62.dsl.irvnca.sbcglobal.net) |
13:58.26 | *** join/#htc-linux jonpry (~jon@63.245.31.4) |
14:06.09 | *** join/#htc-linux Daevoq (~IceChat7@95.235.99.246) |
14:06.46 | *** join/#htc-linux _bukington (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
14:10.28 | *** join/#htc-linux D3tul3 (~Oliver@cpe-174-109-223-235.nc.res.rr.com) |
14:14.10 | *** part/#htc-linux HD2Owner (57f54144@gateway/web/freenode/ip.87.245.65.68) |
14:16.48 | *** join/#htc-linux MN-- (568620c6@gateway/web/freenode/ip.86.134.32.198) |
14:33.18 | *** join/#htc-linux tyween (~tyween@pool-71-163-117-57.washdc.fios.verizon.net) |
14:36.51 | *** join/#htc-linux MassStash (~MassStash@c-67-175-41-173.hsd1.il.comcast.net) |
14:39.02 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
14:56.04 | *** join/#htc-linux arrrghhh (~arrrghhh@c-71-237-40-111.hsd1.co.comcast.net) |
14:59.11 | *** join/#htc-linux localhost (~Chris@cpe-76-188-107-188.neo.res.rr.com) |
15:03.39 | *** join/#htc-linux Sanitoeter (freenode@unaffiliated/sanitoeter) |
15:04.21 | *** join/#htc-linux kvaster_ (~kvaster@93.84.112.82) |
15:10.35 | *** join/#htc-linux Erikson_ (~Erik@p54B74A30.dip.t-dialin.net) |
15:13.15 | *** part/#htc-linux Sanitoeter (freenode@unaffiliated/sanitoeter) |
15:15.26 | *** join/#htc-linux Segnale007 (~Segnale00@host57-255-dynamic.35-79-r.retail.telecomitalia.it) |
15:18.15 | *** join/#htc-linux rpierce99_ (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
15:41.46 | *** join/#htc-linux RaiderX (5b6d2a71@gateway/web/freenode/ip.91.109.42.113) |
15:42.38 | *** join/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |
15:46.02 | *** join/#htc-linux mitsutaka (~mitsutaka@KHP222227247006.ppp-bb.dion.ne.jp) |
15:46.29 | *** join/#htc-linux onen|openBmap (~quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
15:48.26 | Cotulla | bdh |
15:48.27 | Cotulla | hey |
15:51.08 | *** join/#htc-linux g3rm (~germo@89-77-81-175.dynamic.chello.pl) |
15:52.49 | *** join/#htc-linux rpierce99_ (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
15:53.35 | arrrghhh | bdh to you too |
15:55.15 | jonpry | Yeah putting fb in SMI will make big improvement |
15:55.53 | *** join/#htc-linux onen|openBmap_ (~quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
15:56.09 | Cotulla | wtf u still on it ? :) |
15:56.21 | jonpry | just until you implement it |
15:56.32 | *** join/#htc-linux Alex[sp3dev] (~alexander@ip-95-220-12-212.bb.netbynet.ru) |
15:56.47 | Cotulla | I implemented my battery driver, dunno how precision is it, but it doesn't want charge :( |
15:56.50 | Cotulla | strange... |
15:56.58 | Cotulla | same GPIO stuffs works inside MAGLDR |
15:57.07 | Cotulla | linux at start up clear GPIO configurations? |
15:57.09 | jonpry | Cotulla, can you dump the regs from ds2746 on leo? |
15:57.13 | Alex[sp3dev] | Cotulla: maybe it's just not updating the status |
15:57.31 | jonpry | i found the datasheet settings are really bad for htc battery |
15:57.47 | Alex[sp3dev] | jonpry: which kind of battery you have? |
15:58.23 | Cotulla | jonpry, u can use datasheet only as reference. I think HTC use changed scheme of layout. |
15:58.50 | Cotulla | but yes I can dump, not now however. tomorrow will dump it. |
15:59.14 | Cotulla | Alex[sp3dev, which status? |
15:59.30 | Cotulla | I mean I setup two GPIO inside MAGLDR and it charging. in the kernel it discharge...\ |
15:59.52 | Cotulla | btw who got this stupid idea to use spinlock in dexcomm? |
15:59.59 | Alex[sp3dev] | Cotulla: you get that it's discharging from registers, right? |
16:00.11 | Alex[sp3dev] | Cotulla: dunno. maybe it was copied from proc_comm? |
16:00.44 | jonpry | Alex[sp3dev], i dunno an htc battery that fits :p |
16:01.11 | Cotulla | I got data via dex |
16:01.14 | Cotulla | CUR < DCUR |
16:01.20 | Cotulla | in MAGLDR CUR > DCUR |
16:01.34 | Cotulla | I removed all charging GPIO references inside kernel and it still discharge |
16:01.42 | Cotulla | it's stupid to use spinlock there |
16:01.50 | Cotulla | mutex must be used :) |
16:01.57 | Alex[sp3dev] | Cotulla: do you know what register we can monitor during dex init to check if radio is inited? for example, to be able to boot off nand and instead of mdelay(6000) wait for it? |
16:02.37 | Cotulla | hm it's interesting question, my first DEX inside MAGLDR also fails with timeout, but smsm already inited |
16:02.43 | Cotulla | I will look |
16:03.23 | *** join/#htc-linux surge (~surge@pool-98-118-157-221.bflony.fios.verizon.net) |
16:03.27 | Alex[sp3dev] | Cotulla: maybe spinlock is there to allow using dex calls from interrupt context? (but who the fuck will do it?) |
16:03.41 | Cotulla | actual problem: (I saw some kind of workarounds in somebodies git) dex battery need more time, because it make a lot of operations inside, so there udelay() cause 100% cpu load |
16:04.01 | Cotulla | it will make effects on high resource tasks |
16:04.05 | Cotulla | like audio & video |
16:04.25 | Alex[sp3dev] | Cotulla: you mean, dex response takes more time? |
16:04.39 | Cotulla | for battery yes... |
16:04.57 | jonpry | is that a problem on battery_smem? |
16:04.57 | Cotulla | anyway I make separate dex_command_battery in my 32 tree |
16:05.08 | Cotulla | which execute only 8A |
16:05.34 | Alex[sp3dev] | then yes, try using a mutex and see if it is better. it is a good idea, as it will allow us to sleep while dex is coming from arm9 |
16:05.43 | Cotulla | not only mutex |
16:05.44 | jonpry | where are you getting charge current from. wistilt2 said it is not located right after discharge, where is should be |
16:05.55 | Cotulla | for irq-off it must be separate version |
16:06.06 | Cotulla | it can be without spin locks at all |
16:06.09 | Alex[sp3dev] | Cotulla: why do we need to disable irq at all? |
16:06.09 | Cotulla | because irq already off |
16:06.17 | Cotulla | for example PM sleep |
16:06.20 | Cotulla | there DEX call used |
16:06.27 | Alex[sp3dev] | Cotulla: but we can make a separate call |
16:06.30 | Cotulla | and I think there no irq-enabled |
16:06.37 | Alex[sp3dev] | just disable interrupts inside the pm function, not in dex |
16:06.48 | Cotulla | mutex will fail :) |
16:06.49 | Cotulla | yeah |
16:06.54 | Cotulla | separate funtioncs |
16:07.02 | Cotulla | jonpry, DEX8A |
16:07.12 | Alex[sp3dev] | yes, i will look into it after finishing most work on 35 |
16:07.12 | Cotulla | 5 words |
16:07.31 | Cotulla | Alex, so u know why it still discharging? |
16:07.46 | Alex[sp3dev] | Cotulla: no, i'm getting data via i2c. maybe dex is lying |
16:08.16 | Alex[sp3dev] | or maybe arm9 or linux toggles some gpio on boot and you're not setting it to the correct value |
16:08.35 | Cotulla | but MAGLDR show all right :P |
16:08.36 | Cotulla | okay |
16:08.38 | jonpry | Cotulla, we are doing 8a |
16:09.21 | Cotulla | okay I gotta do sound now I think |
16:09.23 | Cotulla | or microp |
16:09.57 | Alex[sp3dev] | and i'm back to some java stuff :( |
16:10.08 | *** join/#htc-linux nineX_ (~nunya@75-132-13-29.dhcp.stls.mo.charter.com) |
16:13.08 | *** join/#htc-linux siulmagic (~IceChat7@24.54.255.153) |
16:18.37 | jonpry | what is the magic command to make a modules tarball? |
16:19.33 | Alex[sp3dev] | find ~/foo/modules -name "*.o" | xargs cp -t . and then tar cvf ~/foo.gz . |
16:19.41 | Alex[sp3dev] | but maybe directly feed list of files to tar |
16:19.43 | Cotulla | hh |
16:20.04 | Cotulla | hm got 85 ma charge current |
16:20.13 | Cotulla | looks like it's USB 100MA |
16:20.34 | Cotulla | <4>[ 100.707611] [BATTERY] LEVEL=47, VOLT=3755, TEMP=238, CUR=86, DCUR=279 |
16:25.43 | Alex[sp3dev] | generally, mkdir x; find modules -name *.ko; cd x; tar cvf ../modules.tar . |
16:26.06 | Cotulla | copy by hands & press Pack to TAR |
16:26.27 | Cotulla | :P |
16:26.34 | Alex[sp3dev] | Cotulla: btw. smem battery was rather buggy on kovsky |
16:26.46 | Cotulla | kovsky 2746? |
16:26.52 | Alex[sp3dev] | yes |
16:26.57 | *** join/#htc-linux Andreyxxl[HD2EU] (~Andreyxxl@89.32.146.153) |
16:26.58 | Cotulla | so it's from different world |
16:27.11 | Cotulla | RHO & TPZ have not control chip |
16:27.13 | Alex[sp3dev] | yes. it's a better device |
16:27.21 | Cotulla | there level got from ADC |
16:27.38 | Cotulla | and "smem battery" sounds crazy |
16:27.44 | Cotulla | wtf smem. just i2c only |
16:28.02 | Alex[sp3dev] | yeah, using i2c and no problems |
16:28.03 | Cotulla | HTC Ace have DS2746 |
16:28.10 | Cotulla | but there some hard parameters |
16:28.33 | Cotulla | basic problem that u doesn't know real FL |
16:29.13 | jonpry | Alex[sp3dev] how are you getting battery info over i2c? |
16:29.18 | Cotulla | old htc devices assume that FL decreased for 2% (don't remember number) every full charge |
16:29.45 | Cotulla | u may implement not-very-user-friendly algo |
16:29.46 | Alex[sp3dev] | jonpry: just reading it via i2c. on x1 ds2746 is at 0x36 |
16:29.56 | Cotulla | add some kind of calibration |
16:29.59 | jonpry | oh, can you read out the params? |
16:30.08 | jonpry | i need ds2746 data points |
16:30.11 | Alex[sp3dev] | jonpry: yes, raw access to ds2746 |
16:30.24 | Cotulla | add special mode - battery calibration |
16:30.37 | Alex[sp3dev] | maybe just disassemble winmo driver properly? |
16:30.53 | Cotulla | turn on all devices and got current about 400ma when measure real capacity of battery |
16:31.20 | Cotulla | but users ofcourse need do this operation several times in year |
16:32.35 | Cotulla | but I think better for u get HTC Ace driver and try to find right values |
16:33.08 | jonpry | bleh, my driver is way cooler :p |
16:33.09 | Alex[sp3dev] | later. first need to finish implementing microp, bt, wifi and sound on 35 |
16:33.34 | Alex[sp3dev] | jonpry: no it is not. HTC Ace driver has DWORDs in it ;) |
16:34.18 | jonpry | jonpry driver has fortran |
16:34.21 | Cotulla | doubt it |
16:34.58 | jonpry | the powell algorithm is more or less the output of f2c |
16:35.04 | Cotulla | u have one/two devices with half died battery (?) and no professional testers & equipment |
16:35.15 | Cotulla | as well u have limited time to test it |
16:35.45 | Cotulla | as well same device may have different batteries |
16:35.48 | Alex[sp3dev] | https://github.com/Kali-/htc-kernel-ace/blob/master/drivers/power/ds2746_param.c DWORD ftw |
16:35.55 | jonpry | yeah working on battery switch problem |
16:36.00 | Cotulla | which have different parameters |
16:36.25 | jonpry | i'm hoping battery id has entropy |
16:36.50 | Cotulla | and at the end: if it was so easy, htc implemented such algo long time ago and used it on all devices, because it doesn't need calculating parameters |
16:36.58 | Cotulla | for every new device |
16:37.07 | jonpry | your just jealous |
16:37.16 | Cotulla | no.. |
16:37.22 | Cotulla | I just understand things... |
16:37.34 | Cotulla | limited of hobby abilities |
16:37.39 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
16:37.42 | jonpry | its not my fault i can write new better code, faster than you can try all the broken htc crap |
16:37.54 | Cotulla | make it at first :) |
16:38.00 | Cotulla | and let it work on all batteries |
16:38.28 | Cotulla | if such algo existed, they was implemented long time ago before u, I am sure. |
16:38.44 | Cotulla | same true for camera, u never got nice shoots using datasheet only |
16:39.16 | Alex[sp3dev] | Cotulla: i never got to see the datasheet in first place.. oh, i did, but after copying wince driver ;) |
16:39.29 | jonpry | look nobody has made this before. its based on paper written in 10/10 and vastly extended |
16:39.51 | Cotulla | I think they use some equipment, like few batteries connected to discharge scheme, which collects data, monitor values, build curves and etc |
16:40.19 | Cotulla | maybe as well have few batteries which are somekind of dead |
16:40.37 | jonpry | and then use one curve for all of them |
16:40.39 | jonpry | genious |
16:40.43 | jonpry | and it works so well |
16:40.55 | Cotulla | at least it works for new battery during 1- 1.5 year |
16:41.18 | Cotulla | I remember Toshiba G900 - there was also ADC based level detection and there it SUCKS |
16:41.28 | jonpry | just remember folks, when your meter give you bad readings, its because the battery is bad |
16:41.30 | Cotulla | there 20% means 0 |
16:42.13 | Cotulla | as well I saw few parameters for different batteries in dlls |
16:45.41 | Cotulla | hey |
16:45.52 | Cotulla | GNUtoo search u, dcordes |
16:46.55 | Cotulla | "look nobody has made this before. its based on paper written in 10/10 and vastly extended' <---- u sure it's working??? maybe there fatal mistake inside |
16:48.29 | Cotulla | Alex, ur sound works great? or should I port from 27 myself? |
16:49.02 | Alex[sp3dev] | Cotulla: it works on rpc part, but you need to port sound routing and audioparams from 27 |
16:51.13 | Cotulla | hm |
16:53.33 | Alex[sp3dev] | Cotulla: i'm listening to sapphire now ;) |
16:53.50 | Cotulla | ? |
16:54.08 | Alex[sp3dev] | Cotulla: a track by Andy Hunter.. said it to confuse you |
16:54.14 | Cotulla | okay ;) |
16:55.08 | Cotulla | heh |
16:55.48 | Alex[sp3dev] | i should say that my loox 720 has better sound than my laptop |
16:55.55 | Cotulla | I am coding under "Bach Toccata & Fuge d-moll" now :) |
17:01.14 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5DE0.dip.t-dialin.net) |
17:06.20 | Cotulla | hm maybe I need gpio_request |
17:06.26 | Alex[sp3dev] | you do |
17:06.34 | Cotulla | wtf?? |
17:06.39 | Cotulla | it's not working without? |
17:06.42 | Alex[sp3dev] | it will work |
17:06.46 | Alex[sp3dev] | but print a huge warning |
17:06.54 | Cotulla | it doesn't pring |
17:06.55 | Cotulla | print |
17:07.04 | Cotulla | for gpio_set_value |
17:07.50 | Alex[sp3dev] | maybe on 32 it won't... in 35 and later they've added a lot of debugging messages and tests to make sure gpios are used properly and drivers don't fight for them |
17:08.38 | Cotulla | it show only at direction config |
17:08.59 | Alex[sp3dev] | anyway, it's just a warning |
17:10.33 | Cotulla | u sure... |
17:10.38 | Cotulla | wtf it's not working |
17:11.16 | Cotulla | funny |
17:11.23 | Cotulla | so much code |
17:11.24 | Cotulla | for gpio |
17:11.37 | Cotulla | wtf |
17:11.44 | Cotulla | and it located in 3-4 different place |
17:11.50 | Alex[sp3dev] | yes, but now there's a generic gpio framework for all SOCs and a sysfs interface for it |
17:12.06 | Cotulla | why not put it to one folder? |
17:12.20 | Cotulla | as well put there readme.txt |
17:12.22 | Alex[sp3dev] | and simple drivers like gpio keys and bitbang i2c are used without changes across different SOCs |
17:12.24 | Cotulla | with small description |
17:12.28 | Cotulla | of call flow |
17:12.28 | ali1234 | because then people would go "herp derp why isn't sysfs code all in one place" |
17:12.30 | Alex[sp3dev] | Cotulla: there is a readme |
17:12.49 | Alex[sp3dev] | it is in Documentation/gpio.txt |
17:13.08 | Cotulla | let me guess? outdated? |
17:13.11 | Alex[sp3dev] | nope |
17:13.27 | Alex[sp3dev] | not yet ;) |
17:13.39 | Alex[sp3dev] | because all this gpio stuff was written not so long ago |
17:13.56 | Cotulla | hm |
17:13.57 | Cotulla | <4>[ 1.344116] [BATTERY] charge(1, 0) |
17:13.57 | Cotulla | <4>[ 1.344940] [BATTERY] charge 0 1 1 |
17:14.09 | Alex[sp3dev] | what do the numbers signify? |
17:14.13 | Cotulla | before request it was zero |
17:14.24 | Cotulla | there CHGEENABLE |
17:14.29 | Cotulla | AC_SPEED |
17:14.32 | Cotulla | USB_SPEED |
17:14.38 | ali1234 | it was over 18 months that the gpio system was rewritten to allow drivers to request gpios |
17:14.50 | Alex[sp3dev] | ali1234: 18 months is not much |
17:15.17 | Alex[sp3dev] | it was around 23-25 kernel iirc |
17:15.44 | ali1234 | it didn't start showing up in arm drivers until about 2009 |
17:16.16 | Cotulla | wtf enable is 1 |
17:16.18 | Cotulla | it must be 0! |
17:16.27 | Alex[sp3dev] | whaat? |
17:16.37 | Cotulla | printk("[BATTERY] charge %d %d %d\n", |
17:16.37 | Cotulla | gpio_get_value(RHO_GPIO_CHG_AC_SPEED), |
17:16.37 | Cotulla | gpio_get_value(RHO_GPIO_CHG_USB_SPEED), |
17:16.37 | Cotulla | gpio_get_value(RHO_GPIO_CHG_ENABLE)); |
17:17.17 | Cotulla | http://pastebin.com/grSVYjys |
17:17.22 | Cotulla | whole code of this function |
17:18.01 | Alex[sp3dev] | maybe set direction as input first? or i dunno |
17:18.32 | Cotulla | it's done already in probe |
17:18.43 | Alex[sp3dev] | but it may be reset when you do set_value, right? |
17:18.55 | Cotulla | no... |
17:18.57 | Cotulla | it just pins |
17:19.06 | Cotulla | in MAGLDR I setup them and it's working! |
17:20.18 | Cotulla | assembler code looks normal |
17:21.04 | *** join/#htc-linux GNUtoo|nexusone (~GNUtoo@host157-58-dynamic.116-80-r.retail.telecomitalia.it) |
17:22.21 | Cotulla | hm or maybe this gpio used somewhere without my clue |
17:22.48 | Alex[sp3dev] | well, it's your code :P |
17:23.41 | Cotulla | but I doubt in it |
17:27.38 | *** join/#htc-linux greg-hd2 (~yaaic@port-4488.pppoe.wtnet.de) |
17:30.52 | Cotulla | that is looks nice in linux - modules params |
17:31.20 | Alex[sp3dev] | just don't overuse them when not needed. but great for testing |
17:49.01 | *** join/#htc-linux greg-hd2 (~yaaic@port-4488.pppoe.wtnet.de) |
17:49.25 | *** join/#htc-linux kvaster_ (~kvaster@vpn-e0.bas-net.by) |
18:07.17 | *** join/#htc-linux lolmensch (d955bb13@gateway/web/freenode/ip.217.85.187.19) |
18:09.34 | *** join/#htc-linux emwe (~emwe@cable-86-56-10-158.cust.telecolumbus.net) |
18:11.47 | Cotulla | where dalvik elf located? |
18:12.07 | Alex[sp3dev] | in /system/xbin, i guess |
18:14.29 | Cotulla | wtf this shit still not charging\ |
18:14.30 | Cotulla | %) |
18:14.40 | Alex[sp3dev] | the world is against you |
18:19.08 | *** join/#htc-linux bja (~bja@c-24-1-253-181.hsd1.il.comcast.net) |
18:19.52 | *** join/#htc-linux venom00ut (~venom00@unaffiliated/venom00) |
18:21.56 | *** join/#htc-linux Segnale007 (~Segnale00@host57-255-dynamic.35-79-r.retail.telecomitalia.it) |
18:30.17 | Cotulla | wtf |
18:30.18 | Cotulla | really |
18:30.34 | Cotulla | VOLT: 3728 TEMP: 341 CUR: 411 DCUR: 303 LVL: 38 |
18:36.01 | jonpry | are current and dcurrent in different units? |
18:36.18 | Cotulla | in same |
18:36.31 | Cotulla | in MAGLDR it's charging, in the kernel - no |
18:36.34 | jonpry | like my battery is fuly charged and i have cur=1709, dcur=340 |
18:36.42 | Alex[sp3dev] | maybe something's draining more power in kernel? |
18:36.54 | Cotulla | wait |
18:36.56 | Cotulla | data from dex |
18:37.02 | Cotulla | show that there no charging current |
18:37.07 | Cotulla | and voltage go down |
18:38.10 | Cotulla | <4>[ 0.692718] [BATTERY] DEX DATA T=60E V=D65 C=38 D=1AE R=1264 |
18:38.10 | Cotulla | <4>[ 0.693176] [BATTERY] LEVEL=30, VOLT=3717, TEMP=358, CUR=13, DCUR=276 |
18:38.10 | Cotulla | <6>[ 0.693420] batt: 30%, 3717 mV, -263 mA (-263 avg), 35.8 C |
18:39.00 | Cotulla | hm then |
18:39.01 | Cotulla | <4>[ 50.707397] [BATTERY] DEX DATA T=618 V=D5E C=175 D=1B5 R=1264 |
18:39.01 | Cotulla | <4>[ 50.707824] [BATTERY] LEVEL=27, VOLT=3710, TEMP=356, CUR=86, DCUR=280 |
18:39.01 | Cotulla | <6>[ 50.708068] batt: 27%, 3710 mV, -194 mA (-194 avg), 35.6 C |
18:39.11 | Cotulla | looks like USB speed not setuped |
18:39.38 | *** join/#htc-linux DuperMan (~Duper@93-172-20-227.bb.netvision.net.il) |
18:40.33 | jonpry | i wonder how mine negotiated 1.7amps |
18:40.46 | jonpry | battery is *hot* |
19:07.55 | *** join/#htc-linux bzo (~chatzilla@c-76-126-175-200.hsd1.ca.comcast.net) |
19:16.00 | *** join/#htc-linux greg-hd2 (~yaaic@port-4488.pppoe.wtnet.de) |
19:23.20 | *** join/#htc-linux |Jeroen| (~jeroen@d5152B25B.access.telenet.be) |
19:24.49 | *** join/#htc-linux localhost (~Chris@cpe-76-188-107-188.neo.res.rr.com) |
19:58.53 | *** join/#htc-linux _twitch (~burning_a@64.112.96.58.static.exetel.com.au) |
19:59.19 | *** join/#htc-linux Elmstrom (~quassel@4807ds1-arno.0.fullrate.dk) |
20:06.52 | *** join/#htc-linux tp2Probs (590c01fb@gateway/web/freenode/ip.89.12.1.251) |
20:07.02 | tp2Probs | hi @ all |
20:07.32 | tp2Probs | some1 here? |
20:14.42 | *** join/#htc-linux crawling (crawling@a89-152-195-220.cpe.netcabo.pt) |
20:15.18 | *** join/#htc-linux programmer8922 (~Evan@67.219.164.162) |
20:18.36 | *** join/#htc-linux surge (~surge@pool-98-118-157-221.bflony.fios.verizon.net) |
20:19.06 | tp2Probs | when i boot android on my rhod400_de the internet browser open and want me to install LauncherPro |
20:22.07 | *** join/#htc-linux MN-- (~yaaic@host86-134-32-198.range86-134.btcentralplus.com) |
20:30.31 | Alex[sp3dev] | ok, time to implement microp keypad and optical joystick :P |
20:36.19 | bzo | hi Alex[sp3dev] |
20:36.48 | Alex[sp3dev] | bzo: hello |
20:37.17 | bzo | wanted to ask your opinion: is board model id detection better in devices as atag or htc_hw? |
20:38.42 | Alex[sp3dev] | bzo: atag.. then we can just parse board name from userspace.. but we can do it on board early init and patch from there probably.. anyway, i dunno.. luckily, there's only one X1 board. unless some dude with a prototype comes in |
20:39.35 | bzo | ok, thanks. we'll probably having something in htc_hw anyways to service userland |
20:39.50 | bzo | but for kernel use, it seemed better to me to do atag, like emwe did for the monodie detection |
20:40.19 | Alex[sp3dev] | i want to get rid of htc_hw anyway. so better use atag. we can patch haret, it can get board name from wince. and we'll come up with something for nand bootloader then |
20:41.07 | bzo | I'll probably pull it from spl like the nand kernel is doing |
20:42.12 | Alex[sp3dev] | bzo: i'm afraid we'll have to overwrite spl with our bootloader in ram, so probably it'd be better to pull it off nand. but that's long before that |
20:43.22 | bzo | <PROTECTED> |
20:43.31 | Alex[sp3dev] | atag |
20:43.37 | bzo | yeah |
20:43.56 | Cotulla | wtf ppl? read from smem model name and parse it by fixed list? |
20:44.07 | Alex[sp3dev] | Cotulla: is it guaranteed to be there? |
20:44.15 | Cotulla | why not? |
20:44.18 | Cotulla | or in drv_glob |
20:44.29 | Cotulla | SPL reads model id to some locationm |
20:44.53 | bzo | the nand kernel uses MSM_SPL_BASE + 0x81068 |
20:45.01 | bzo | think that will still be there for nand boot? |
20:45.25 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5DE0.dip.t-dialin.net) |
20:45.47 | Alex[sp3dev] | i'm afraid that if we come up with our own loader, it will overwrite the spl in ram. or can we have interrupt vectors at 0xffffxxxx something? |
20:46.02 | Cotulla | and why u want remove htc_hw |
20:46.20 | Cotulla | userspace drivers can detect it nice |
20:46.46 | Alex[sp3dev] | Cotulla: because it is a dirty mess. vibra can be moved out of there, audio should be implemented as acoustic, and board type should be parsed from /proc/cpuinfo |
20:46.58 | Cotulla | it's not mess |
20:47.18 | Cotulla | <PROTECTED> |
20:47.30 | Cotulla | htc_hw can contain data in any format |
20:47.45 | Cotulla | like model, version, revision |
20:48.01 | bzo | Cotulla: so you think we should just keep model detection in htc_hw? |
20:48.10 | Cotulla | why not? |
20:48.11 | Alex[sp3dev] | ok, we can limit htc_hw only to that. other stuff like audio and vibra should be moved out of there |
20:48.27 | Cotulla | android userspace drivers may need to check which model |
20:48.33 | Cotulla | like common led drivers and etc |
20:48.49 | bzo | yeah, userland needs model for keyboard map |
20:48.50 | Alex[sp3dev] | led drivers should be detected by probing /sys/class/leds |
20:48.54 | bzo | right now it is passed with module param |
20:48.58 | Cotulla | and it can contains more info |
20:49.00 | Cotulla | like model name |
20:49.05 | Cotulla | RHO TPZ KVS .. etc |
20:49.08 | Cotulla | revision |
20:49.12 | Alex[sp3dev] | but yes, we need to export model revision to userspace |
20:49.16 | Alex[sp3dev] | like, rhod400, rhod200 |
20:49.18 | Cotulla | version like RHO300 and RHO100 |
20:49.28 | Cotulla | revision I mean board version |
20:49.45 | Cotulla | it may contains size of ram / rom |
20:49.48 | Cotulla | also |
20:50.00 | Cotulla | but htc_hw bad name :P maybe hw_info better |
20:50.22 | Alex[sp3dev] | Cotulla: sorry, but size of ram is already exported in many places, and rom size - via mtd subsystem. don't go htc way, don't duplicate existing stuff |
20:51.42 | Cotulla | why not |
20:51.48 | Cotulla | next version will have new mtd interface |
20:51.51 | Cotulla | not compatible |
20:51.54 | Alex[sp3dev] | it will not |
20:52.00 | Cotulla | while we will still able to use our own |
20:52.15 | Alex[sp3dev] | <PROTECTED> |
20:52.16 | Cotulla | as well we can put this values in our own format |
20:52.28 | Alex[sp3dev] | but i don't want to argue with you |
20:52.36 | Alex[sp3dev] | because it is counter-productive |
20:52.57 | bzo | anyways, time to get back to playing with SMI anyways :P |
20:53.11 | Alex[sp3dev] | yeah, two times anyways is even more anyways |
20:53.13 | Cotulla | own interface <<--- it means it already will be how we want |
20:53.29 | Cotulla | and we don't need worry about other things |
20:53.35 | Alex[sp3dev] | don't suffer NIH |
20:56.31 | Cotulla | at the end it will be easy |
20:56.34 | Cotulla | just open read close |
20:56.36 | Cotulla | and job done |
20:56.58 | Alex[sp3dev] | Cotulla: open /proc/meminfo, read first line - and you get memory size |
20:57.07 | Cotulla | yeah and parse it |
20:57.16 | Cotulla | as well I talk about total memory size |
20:57.19 | Cotulla | including pmem and etcf |
20:57.23 | Cotulla | like 128 256 and etc |
20:57.33 | Alex[sp3dev] | why do you need that? |
20:58.19 | Cotulla | maybe adjust memory sizes |
20:59.14 | Alex[sp3dev] | Cotulla: anyway, userspace can only adjust depending on usable ram size. pmem stuff is fixed.. just don't add any code until you know you need it. never add something you *might* need in future |
21:03.20 | Cotulla | heh |
21:04.01 | Alex[sp3dev] | what are you working on at the monent? |
21:04.14 | Cotulla | I am doing homework in MathCad :P |
21:04.17 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
21:04.23 | Cotulla | while RHO charging |
21:04.39 | Alex[sp3dev] | which kind of homework? which subject? |
21:04.45 | Cotulla | some with matirx |
21:04.54 | Cotulla | then I continue with sound or microp |
21:05.08 | Cotulla | or will try to run desire sense |
21:05.23 | Alex[sp3dev] | doesn't it depend on gles 2.0? |
21:05.42 | Cotulla | don't know |
21:05.44 | Cotulla | yet |
21:05.54 | Cotulla | but version from 2.1 worked on 7200 right? |
21:06.03 | Alex[sp3dev] | i just think that if it were not, it would have been ported already |
21:16.05 | Cotulla | hm maybe) |
21:16.22 | Cotulla | anyway sound is important part |
21:16.43 | Alex[sp3dev] | i will finish keypad and joystick first, and then come to sound |
21:30.11 | *** join/#htc-linux kiozen (~kiozen@rgnb-4d053f3a.pool.mediaWays.net) |
21:47.44 | *** join/#htc-linux JesusFreak316 (~JesusFrea@pool-173-65-106-39.tampfl.fios.verizon.net) |
21:50.58 | *** join/#htc-linux ftoz (~root@cst-prg-96-7.vodafone.cz) |
22:02.48 | *** join/#htc-linux rpierce99 (~rpierce99@71-82-139-28.dhcp.roch.mn.charter.com) |
22:28.48 | *** join/#htc-linux Curious_ (8bb3cffd@gateway/web/freenode/ip.139.179.207.253) |
22:28.58 | Curious_ | does anyone have experience of "qsub" ? |
22:30.46 | Curious_ | paralel processing? |
22:30.48 | Curious_ | anything? |
22:30.51 | Alex[sp3dev] | nope |
22:33.27 | *** part/#htc-linux Curious_ (8bb3cffd@gateway/web/freenode/ip.139.179.207.253) |
22:37.46 | *** join/#htc-linux BoTToEsP (~maximo@212.21.250.251.dyn.user.ono.com) |
22:47.00 | *** join/#htc-linux D3tul3 (~Oliver@cpe-174-109-223-235.nc.res.rr.com) |
22:56.55 | *** join/#htc-linux RaiderX (5b6d2a71@gateway/web/freenode/ip.91.109.42.113) |
22:57.25 | *** join/#htc-linux JesusFreak316 (~JesusFrea@pool-173-65-106-39.tampfl.fios.verizon.net) |
22:57.34 | RaiderX | hey |
23:08.14 | RaiderX | Cotulla |
23:47.21 | *** join/#htc-linux siulmagic (~IceChat7@24.54.255.153) |
23:49.31 | *** join/#htc-linux Segnale007 (~Segnale00@host57-255-dynamic.35-79-r.retail.telecomitalia.it) |
23:50.04 | *** part/#htc-linux Cotulla (~opera@nat004-252-205-109.tvoe.tv) |