00:00.22 | rpierce99 | meter is back up to 40, so if that's accurate the life is pretty good in comparison |
00:00.42 | WisTilt2 | were you just in a call to drop it like that? |
00:00.43 | rpierce99 | but i doubt it's right |
00:00.47 | rpierce99 | nope |
00:00.56 | rpierce99 | just screen on/screen off |
00:01.32 | WisTilt2 | yeah probably need new model to get the state of that battery across all levels |
00:01.58 | WisTilt2 | mine is pretty darn accurate now. run a new model every couple months |
00:17.25 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-vujbiydaitgptskb) |
00:20.10 | *** join/#htc-linux avinashhm (~avinash-h@192.91.66.186) |
00:45.57 | WisTilt2 | bzo you still at the kbd? |
00:46.17 | bzo | what's up? |
00:47.16 | WisTilt2 | figured out how this oc is pumping memory up also. PLL2 gets changed to the max oc rate and axi follows it. this is mine at 672mhz oc |
00:47.16 | WisTilt2 | PLL2 @ f8005338: MODE=00000007 L=00000023 M=00000000 N=00000001 freq=672000000 Hz (672 MHz) |
00:47.41 | WisTilt2 | axi and ahb oc from there |
00:48.17 | WisTilt2 | i also changed the table so the highest value has axi at 192mhz and works quite fast |
00:48.30 | bzo | I had assumed that axi/ahb followed pll0/1, but maybe it follows whatever pll the cpu is using? |
00:48.56 | WisTilt2 | yep exactly what its doing, following the cpu. we need to adjust the tables though so they are optimized |
00:49.07 | bzo | is 192 the 40% OC? |
00:49.09 | WisTilt2 | this thing is hauling the mail now |
00:49.27 | WisTilt2 | 45% |
00:49.47 | arrrghhh | hauling the mail now. can't say i've ever heard that phrase before WisTilt2 :P |
00:50.01 | WisTilt2 | axi at 200 is ok too but no noticeable gain and probably pushing it |
00:50.09 | WisTilt2 | lol |
00:50.16 | WisTilt2 | thats an old saying |
00:50.22 | WisTilt2 | for old people i guess:) |
00:50.24 | bzo | maybe we should create an axi_192mhz variable and have it work like the existing 160/200 ones? |
00:50.31 | WisTilt2 | yes i agree |
00:50.40 | arrrghhh | hahaha |
00:51.05 | WisTilt2 | i have the logic that determines that commented out so it can actually run at the higher levels but 192var would be perfect |
00:51.33 | bzo | and we could just tie it being enabled to having an oc_freq_khz? |
00:52.21 | WisTilt2 | yep. that way people can oc whatever they want and ahb and axi will follow along, just need to change some of the values in the tables and should be sweet |
00:52.45 | jonpry | isn't the axi_200 stuff for turbo devices like ours? |
00:52.47 | WisTilt2 | once jonpry gets composite working these babies are going to fly |
00:52.58 | bzo | btw, I'm using the .27 panel code on .39, and my power consumption seems to be back down to less than 2%/hr |
00:53.01 | WisTilt2 | axi_200 never tests true the way it is |
00:53.16 | arrrghhh | .27 panel code on .39 |
00:53.20 | arrrghhh | sounds like blasphemy |
00:53.29 | WisTilt2 | bzo you need the fixed panel code for .39, somehow i missed stuff when we moved it over |
00:53.50 | bzo | arrrghhh: most of our device specific code is a copy from .27 |
00:54.02 | arrrghhh | yea, i remember peoples sayin that |
00:54.04 | WisTilt2 | last night i got .58% per hour, that was with bma150 off also |
00:54.22 | bzo | it got missed because .39 was "forked" before all those changes |
00:54.39 | WisTilt2 | yep, jonpry had to go and get ahead of the curve so fast hehe |
00:55.15 | bzo | WisTilt2: do you have anything newer on the panel than what .27 has? |
00:55.45 | WisTilt2 | dont think so. .27 panel is my stuff still isnt it? should all be there |
00:55.53 | WisTilt2 | the init part anyway |
00:56.02 | bzo | jonpry: the ax_160 is for our "turbo" devices, the 200 is for newer stuff |
00:56.49 | bzo | WisTilt2: do you want to push it, or shall I? |
00:57.09 | WisTilt2 | checking .27 to see if its all there hang on 1 |
00:57.40 | WisTilt2 | nope its not there in .27 on the current git either |
00:57.53 | WisTilt2 | all the vsync/hsync stuff is gone |
00:58.07 | bzo | ok, it's all you then |
00:58.44 | WisTilt2 | after i added it back yesterday i could swear the stuff on the panel looks sharper |
01:00.00 | jonpry | what is non turbo speed then? |
01:00.14 | arrrghhh | quittin time, cya guys |
01:00.30 | bzo | from what the acpuclock tables have, 128mhz |
01:01.20 | bzo | I guess the mobile guys are not big into running at full rated spec |
01:01.30 | bzo | I mean wtf is 160mhz also? |
01:01.51 | jonpry | axi might be synchronous with ram |
01:02.11 | bzo | you mean async? |
01:02.19 | jonpry | no |
01:02.39 | bzo | I don't follow |
01:02.49 | WisTilt2 | axi is for sure. chip allows ahb or axi and we're in axi |
01:02.50 | jonpry | like on omap3 they have this think called the l3 interconnect speed, which more or less has to be the same as the ddr interface speed |
01:02.59 | jonpry | er thing |
01:03.22 | bzo | why wouldn't you run it at the rated ram speed though? i.e. 133mhz, 166mhz, etc |
01:03.46 | jonpry | so you "can" clock l3 to probably 250mhz. but this isn't really an option with 166mhz ram for example |
01:04.35 | bzo | oh, actually, it's probably the closest they can divide the cpu clock to |
01:05.09 | jonpry | sounds right |
01:05.41 | WisTilt2 | panel commit is pushed |
01:06.37 | WisTilt2 | jonpry: ive been running axi at 192mhz all day, you think we're pushing it? worked at 200 also and i haven't tried higher. |
01:07.07 | jonpry | i dunno. does that mean ram is running at 192mhz also? |
01:07.13 | WisTilt2 | yep |
01:07.23 | bzo | it's hard to imagine ram manufactured 3 yrs ago that wouldn't bin to at least 200mhz |
01:08.03 | jonpry | they don't sell better than 5ns lpddr parts |
01:08.04 | WisTilt2 | i dont see anywhere in our code that the register that sets ahb/axi is ever changed and the default for this chip is axi mode. |
01:08.41 | bzo | I think 5ns was the top bin for all ddr2 |
01:09.02 | bzo | but toward the end, all the parts could pretty much hit that bin |
01:09.49 | bzo | hopefully htc actually bought 166mhz ram to support turbo mode |
01:10.04 | bzo | because in that case, going up to 192/200 is not a huge jump up in spec |
01:10.45 | WisTilt2 | yeah, no telling with them though. ill try going up to say 220 or so and see if it crashes |
01:10.51 | jonpry | what is the next speed? |
01:11.08 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
01:11.20 | WisTilt2 | 211 |
01:11.30 | WisTilt2 | 230 after that |
01:11.45 | WisTilt2 | maybe ill just go for 230 first:) |
01:11.48 | jonpry | 230 sounds like a winner |
01:12.27 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
01:13.24 | bzo | hmm, it is slightly problematic though that axi is tied to cpu freq |
01:13.36 | bzo | tricky to maximize both value at the same time |
01:18.31 | WisTilt2 | no smoke pouring out of it so far. benchmark time |
01:18.43 | *** join/#htc-linux leviathan (~quassel@2001:470:26:484:6ef0:49ff:fee6:8dca) |
01:20.28 | WisTilt2 | wow |
01:21.45 | WisTilt2 | yeah that made a significant difference. memory went up to 252 and overall is now 524 |
01:24.58 | fakker | poof |
01:26.33 | *** join/#htc-linux Rob2222 (~Miranda@p4FFF0387.dip.t-dialin.net) |
01:28.19 | WisTilt2 | bzo: no errors or any crashing so far and this thing is really fast. ill run it at 230 the rest of the evening and see how it does. still have cpu at 672mhz btw |
01:29.51 | WisTilt2 | here's the freq table im using if you want to give it a go -> http://pastebin.com/nMgMqcgF |
01:35.02 | jonpry | touchpad gets like 3000 in quadrant |
01:35.22 | WisTilt2 | nice |
01:35.32 | WisTilt2 | stock clocks? |
01:35.47 | jonpry | yes |
01:35.55 | jonpry | 2800 or something |
01:36.11 | jonpry | and people oc it by 700mhz or so pretty regularly |
01:37.44 | *** join/#htc-linux detule (~oliver@pool-96-234-141-27.bltmmd.east.verizon.net) |
01:38.07 | WisTilt2 | thats some overclocking. whats the cpu freq normally? |
01:38.13 | jonpry | 1.2ghz |
01:38.27 | jonpry | buts its most likely a 1.5ghz part |
01:39.47 | *** join/#htc-linux hardwalker (~hardwalke@122-117-115-146.HINET-IP.hinet.net) |
01:39.55 | WisTilt2 | well this thing is still flying and ive run everything i can think of to crash it so im leaving it like this. gotta get out of here and get my grand kids for the xmas parade that starts in an hour. |
01:40.22 | WisTilt2 | jonpry, dont know if you caught my comment about gpu1 @ 13mb? |
01:57.51 | *** join/#htc-linux Cass (~Cass@188-220-34-222.zone11.bethere.co.uk) |
02:02.32 | *** join/#htc-linux CoKeSero (~imcokeman@pool-96-240-154-182.hrbgpa.fios.verizon.net) |
02:47.56 | *** join/#htc-linux dr1337 (~textual@42.241.174.158) |
03:01.04 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
03:01.42 | *** join/#htc-linux XirXes_ (~XirXes@67-2-17-115.slkc.qwest.net) |
03:15.55 | *** join/#htc-linux swc|666 (~gecko@unaffiliated/swc666/x-4934821) |
03:22.25 | *** join/#htc-linux surge (surge@pool-72-88-82-28.bflony.fios.verizon.net) |
03:41.35 | *** join/#htc-linux surge (surge@pool-72-88-82-28.bflony.fios.verizon.net) |
04:53.24 | *** join/#htc-linux Rob2223 (~Miranda@pD9FAC2D9.dip.t-dialin.net) |
04:58.23 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
05:17.25 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
05:24.05 | jonpry | dur |
05:27.17 | rpierce99 | I'm at 16h 8m and still not dead! |
05:27.51 | jonpry | is that a record? |
05:28.04 | rpierce99 | no |
05:29.15 | rpierce99 | just happy because like 5h ago it was saying like 20%, i'm sure it's just a bad model |
05:29.36 | rpierce99 | trying to generate a good one by letting it die, but it's taking so long! |
05:29.50 | jonpry | using it and stuff makes it good |
05:35.02 | *** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net) |
05:45.29 | *** join/#htc-linux giantbicycle (d23d7a24@gateway/web/freenode/ip.210.61.122.36) |
05:47.52 | rpierce99 | haha, neocore without textures just got me a 30.4! new record! |
06:20.12 | *** join/#htc-linux Bry8Star_ (~Bry8Star@gateway/tor-sasl/bry8star) |
06:39.09 | *** join/#htc-linux swc|666 (~gecko@unaffiliated/swc666/x-4934821) |
06:39.10 | *** join/#htc-linux XeKToReX (~xTx@115-64-132-224.static.tpgi.com.au) |
06:39.14 | *** join/#htc-linux XeKToReX- (~xTx@115-64-132-224.static.tpgi.com.au) |
06:39.21 | *** join/#htc-linux dr1337 (~textual@CPE-120-147-24-40.lflg2.win.bigpond.net.au) |
07:02.35 | *** join/#htc-linux kiozen (~kiozen@p5DDF2BCD.dip.t-dialin.net) |
07:07.47 | *** join/#htc-linux Sandvold (~Sandvold@213.236.244.131) |
07:20.08 | *** join/#htc-linux bukington (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
08:31.07 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-owosphyuyealafwd) |
08:38.40 | *** part/#htc-linux giantbicycle (d23d7a24@gateway/web/freenode/ip.210.61.122.36) |
08:41.58 | *** join/#htc-linux dobrin (~dobrin@85.91.150.26) |
08:54.30 | *** join/#htc-linux arif-ali (~arif-ali@ip-81-23-53-226.ask4internet.com) |
09:18.32 | dr1337 | i don't think the dequeue native buffer error in ICS is due to Texture_External |
10:20.08 | *** join/#htc-linux Sand_work (~Sandvold@213.236.244.131) |
10:20.18 | *** join/#htc-linux bukington__ (~bukington@fac34-2-82-228-151-145.fbx.proxad.net) |
10:29.39 | *** join/#htc-linux mitsutaka (~mitsutaka@rt.miraclelinux.com) |
10:39.23 | *** join/#htc-linux GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
10:42.33 | *** join/#htc-linux gauner1986 (~Miranda@87.253.171.200) |
10:55.09 | *** join/#htc-linux XirXes (~XirXes@67-2-24-176.slkc.qwest.net) |
10:57.52 | *** join/#htc-linux mdeejay (~MDJ@46.182.128.248) |
11:24.51 | *** join/#htc-linux Sand_work (~Sandvold@213.236.244.131) |
11:46.29 | *** join/#htc-linux mickeyl (~mickey@openmoko/coreteam/mickey) |
11:52.20 | *** join/#htc-linux ImCoKeMaN (~imcokeman@pool-96-249-151-84.hrbgpa.fios.verizon.net) |
12:38.37 | *** join/#htc-linux detule (~detule@pool-96-234-141-27.bltmmd.east.verizon.net) |
12:39.41 | *** join/#htc-linux Sandvold (~Sandvold@213.236.244.131) |
13:05.32 | *** join/#htc-linux rzk (~rzk@95-24-54-101.broadband.corbina.ru) |
13:12.09 | *** join/#htc-linux lamikr (lamikr@nat/nokia/x-fhruqlvmyvlxbwyb) |
13:14.20 | *** join/#htc-linux helicopter88 (~helicopte@host128-84-dynamic.37-79-r.retail.telecomitalia.it) |
13:18.56 | *** join/#htc-linux Rajko (~rajkosto@ds.wan.rajkonet.info) |
13:23.12 | ftoz | Hi, anyone knows how to compile i2cdetect for pxa |
13:34.54 | *** join/#htc-linux skodde (~skodde@unaffiliated/skodde) |
13:35.26 | *** join/#htc-linux Sandvold (~Sandvold@207.80-202-111.nextgentel.com) |
13:36.12 | *** join/#htc-linux TheXev (~user@166.sub-174-252-201.myvzw.com) |
13:45.09 | *** part/#htc-linux mdeejay (~MDJ@46.182.128.248) |
13:48.41 | *** part/#htc-linux ftoz (~root@85.162.196.208) |
14:03.38 | *** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com) |
14:07.05 | *** join/#htc-linux [acl] (~abel@cpe-69-203-141-229.si.res.rr.com) |
14:10.38 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:16.51 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:20.00 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:21.24 | *** join/#htc-linux NeoMatrixJR (~chatzilla@173-20-63-62.client.mchsi.com) |
14:22.44 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:25.46 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:27.04 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-190-178.bmobile.ne.jp) |
14:29.01 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:31.19 | *** join/#htc-linux bartman (~bart@2607:f2c0:a000:175:2e0:81ff:fe47:3d01) |
14:32.00 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:35.05 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:35.39 | *** join/#htc-linux d3tul3 (~detule@hw-ma-6l13f61.mat.jhu.edu) |
14:35.46 | d3tul3 | hey rpierce99 |
14:36.21 | *** join/#htc-linux XeKToReX (~xTx@115-64-132-224.static.tpgi.com.au) |
14:36.35 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-190-178.bmobile.ne.jp) |
14:37.43 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:41.01 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:44.14 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:47.55 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:50.05 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:52.48 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:54.44 | rpierce99 | hey d3tul3 |
14:55.40 | d3tul3 | you have a moment to try out mac adb support on 3.0? |
14:56.01 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
14:56.05 | *** join/#htc-linux Rob2222 (~Miranda@pD9FAC2D9.dip.t-dialin.net) |
14:56.05 | rpierce99 | in a few, send over a link and i'll jump on it when i'm done eating breakfast |
14:56.25 | rpierce99 | i'm also generating a battery model, so it might be a little bit |
14:56.36 | d3tul3 | sure whenever you get to it http://dl.dropbox.com/u/38520332/3.0/30ker_mod_11-29.tar.gz |
14:58.35 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:01.41 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:04.13 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:04.53 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-190-178.bmobile.ne.jp) |
15:05.43 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:08.06 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:09.47 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:12.04 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:13.38 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:15.47 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:15.59 | *** join/#htc-linux TheXev (~user@166.sub-174-252-201.myvzw.com) |
15:17.38 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:19.46 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:22.01 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:23.38 | *** join/#htc-linux rajkosto (~rajkosto@ds.wan.rajkonet.info) |
15:26.07 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:27.32 | *** join/#htc-linux Rajko (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:30.03 | *** join/#htc-linux bitrot (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
15:32.26 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:33.08 | *** join/#htc-linux emwe (~mweirauch@cable-86-56-10-252.cust.telecolumbus.net) |
15:34.14 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:34.27 | *** join/#htc-linux helicopter88 (~helicopte@host128-84-dynamic.37-79-r.retail.telecomitalia.it) |
15:36.29 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:38.17 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:40.24 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:42.23 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:44.21 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:47.33 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:52.32 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:52.49 | *** join/#htc-linux rob_w (~bob@ppp-93-104-172-111.dynamic.mnet-online.de) |
15:54.53 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:54.57 | *** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net) |
15:54.59 | crypticmofo | hi all |
15:55.08 | crypticmofo | anyone here on a tp2 running android ? |
15:55.31 | crypticmofo | if so how is it |
15:56.05 | rpierce99 | gets better seemingly every day, but its risk free, so just try it |
15:57.24 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
15:58.00 | crypticmofo | aw yea |
15:58.03 | crypticmofo | i just read the status |
15:58.18 | crypticmofo | i wish i had programming knowledge and what not i could help |
15:58.57 | rpierce99 | #xdandroid is where you'd want to discuss the particular build for the tp2 |
15:59.05 | crypticmofo | thanks |
15:59.32 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:05.10 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:08.14 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:11.43 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:12.41 | *** join/#htc-linux AstainHellbring (~AstainHel@unaffiliated/astainhellbring) |
16:14.38 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-190-178.bmobile.ne.jp) |
16:16.40 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:19.00 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:22.18 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:24.30 | *** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net) |
16:30.15 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:33.15 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:34.01 | *** join/#htc-linux paulk (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
16:36.48 | *** join/#htc-linux avinashhm (~avinash-h@192.94.92.11) |
16:43.27 | jonpry | hi all |
16:44.17 | *** join/#htc-linux MethoS- (~clemens@134.102.106.250) |
16:46.09 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:47.46 | detule | hey jonpry |
16:48.23 | *** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net) |
16:48.27 | crypticmofo | umm k |
16:48.53 | crypticmofo | rpierce99 can you give me the link to the xandroid chan again if you don't mind ? |
16:49.16 | rpierce99 | #xdandroid, all you do is type "/join #xdandroid" and you don't need a link |
16:49.24 | crypticmofo | oh |
16:49.25 | crypticmofo | rotfl |
16:49.29 | crypticmofo | i was doing xandroid |
16:49.32 | crypticmofo | not xdandroid |
16:50.18 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:52.02 | detule | rpierce99, i changed the kernel pack (same link) this one is up to date with the vsync commit from last night |
16:52.13 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
16:52.24 | rpierce99 | k, my phone has been generating the battery model all morning |
16:52.30 | rpierce99 | hopefully its a good one after all this time |
16:53.09 | jonpry | i had trouble with some of wistilt2's pm patches before |
16:53.36 | jonpry | he put something in and said it was down to 30ma or something. but i measured it and it was like almost 250ma in collapse on my phone |
16:53.37 | detule | well locally i've reverted the IDLE stuff |
16:54.00 | detule | it causes some overall quirkiness in operation on 3.0 |
16:54.06 | jonpry | reverted his patches and it was down to 50 again. he said this wasn't possible or something |
16:56.41 | detule | so did hacking out those 12c's from the binary fix the missing textures in neocore? |
16:57.13 | rpierce99 | hey jonpry does ba tree app prevent sleep, or do i need to turn on don't sleep when plugged in |
16:57.44 | jonpry | detule, yes when used w/ the patches libEGL |
16:57.52 | jonpry | rpierce99, shouldn't prevent sleep |
16:58.30 | rpierce99 | so if its generating a model i need to prevent sleep myself |
16:58.47 | jonpry | if you want it to keep processing |
16:58.58 | rpierce99 | k, that probably explains why its taking so long :) |
16:59.39 | jonpry | i think we need to implement a texture allocator. and seriously need more gpu1 |
17:00.09 | arrrghhh | more cowbell? |
17:00.33 | jonpry | ? |
17:00.41 | *** join/#htc-linux Sandvold (~Sandvold@207.80-202-111.nextgentel.com) |
17:00.47 | arrrghhh | sorry, bad joke. |
17:00.54 | detule | jonpry, wanna share these patched binaries -> these work without changes in pmem allocation? |
17:01.22 | jonpry | yeah no pmem changes. i can email you the libgles. the egl is from that link |
17:01.39 | jonpry | maybe want to try my cm7 egl. it might be patched, and we even have source |
17:02.00 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:02.11 | detule | sure, let's try the cm |
17:04.08 | jonpry | should have it |
17:05.39 | jonpry | so check out this texture situation. we have 8mb - 0x2F0000 to mess with. so ~5MB |
17:05.58 | jonpry | say something wants to paint like a background image. probably 480x800 |
17:06.17 | jonpry | has to allocate a 1024x1024 texture. say its 8888. thats 4MB |
17:06.22 | jonpry | so only 1 left |
17:09.35 | detule | ok i was wondering are we at all using those ~5MB currently? |
17:09.59 | jonpry | 3d apps will |
17:10.54 | detule | this via calls in the binary that i can't see ? ugh i hate this |
17:11.11 | Sandvold | <PROTECTED> |
17:11.15 | detule | plus the no_allocator flag is tipped on gpu1 right, so they can't use it if gralloc is allocating there |
17:11.54 | jonpry | yeah its not like that |
17:12.06 | jonpry | the whole 8MB is mmap'd into the process |
17:12.39 | jonpry | the bottom 0x2f0000 is pseudo managed by gralloc. using is own allocator implementation |
17:12.58 | jonpry | the upper portion is managed internally by the blob |
17:13.06 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:15.04 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:15.32 | arrrghhh | Sandvold, that's vague |
17:15.58 | rpierce99 | arrrghhh: no it's not, he wrote and/or copied code and/or files |
17:16.07 | arrrghhh | lol |
17:16.12 | arrrghhh | that's somehow more vague. |
17:16.19 | rpierce99 | exactly |
17:16.25 | rpierce99 | i answered the question as asked |
17:16.29 | arrrghhh | indeed |
17:16.50 | Sandvold | :P |
17:17.21 | *** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net) |
17:17.45 | rpierce99 | there's the man, the myth, the legend |
17:17.49 | Sandvold | okey: for the adreno200 does anyone have an idea what the ankuch guy edited to get HW acc to work |
17:18.05 | Sandvold | and if it works at all, don't have a HD2 around to test it |
17:18.07 | jonpry | on ICS? |
17:18.12 | arrrghhh | Sandvold, what is this for? |
17:18.14 | arrrghhh | if it already works... |
17:18.53 | Sandvold | on ICS, i got desire and we don't have HW acc |
17:19.15 | Sandvold | so if anyone knew at all what he had done, then it would be nice to get some pointers |
17:19.27 | arrrghhh | oic. not sure there's many HD2 devs left in here. Cotulla pops in randomly. |
17:19.32 | arrrghhh | never heard of ankuch tho |
17:21.00 | Sandvold | me neither, 31 posts on xda and suddenly he got HW acc, and no gits to look for what he edited, but he said he would release the code in the near future, so it's not to big of a deal |
17:21.36 | jonpry | i dunno who ankuch id |
17:21.38 | jonpry | is |
17:22.21 | *** join/#htc-linux Alex[sp3dev] (~alexander@178.176.144.6) |
17:22.23 | WisTilt2 | Morning guys. Jonpry, 230mhz on axi is not stable enough when the device warms up a bit. 192 looks like the safest top end, haven't had any probs at that rate even when very warm. |
17:23.10 | jonpry | smoke pooring out yet? |
17:23.11 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:24.04 | Alex[sp3dev] | WisTilt2: do these overclocks give noticeable 2d improvement with standard gpu memory setup? |
17:24.08 | *** join/#htc-linux furtardo (~mks@nat/yahoo/x-vphizfwrqszbtzbz) |
17:24.13 | WisTilt2 | close to it when it got warm at 230. it really didnt like that speed much and 192 is plenty fast anyway |
17:25.09 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:25.24 | WisTilt2 | Alex[sp3dev]: tbo ive been looking past 2d benchmarks and only looking at memory, cpu,io. i think my best 2d was 98 on quadrant which was much higher than before so probably does help 2d a bit. |
17:25.48 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-128.dynamic.mnet-online.de) |
17:27.26 | jonpry | Alex[sp3dev], ever try larger gpu1? |
17:27.33 | Alex[sp3dev] | jonpry: nope |
17:27.37 | *** join/#htc-linux detule (~detule@hw-ma-6l13f61.mat.jhu.edu) |
17:27.41 | jonpry | needz moar texture |
17:27.58 | WisTilt2 | jonpry, you didnt catch either of my comments to you about that i guess:( |
17:28.15 | jonpry | i did |
17:28.20 | jonpry | doesn't work |
17:28.36 | WisTilt2 | yes and dont know why that is |
17:28.48 | jonpry | i'm hoping there is some kind of patch to libGLES that can be done |
17:28.58 | WisTilt2 | why can gpu0 change size but gpu1 must be 8mb |
17:29.04 | *** join/#htc-linux bitrot (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:29.35 | jonpry | and winmo uses 2+13 |
17:29.38 | WisTilt2 | Alex[sp3dev] does kovs have 32 or 64mb smi? |
17:29.51 | Alex[sp3dev] | WisTilt2: 32 |
17:29.57 | WisTilt2 | ok nm then |
17:30.21 | Alex[sp3dev] | it is some first-gen msm7200A, does not overclock over 650 mhz |
17:30.50 | WisTilt2 | 7200A not the 7201? |
17:30.56 | Willd | WisTilt2: Which libGLES do you use? |
17:30.58 | Willd | 1.0 or 1.1? |
17:31.09 | Alex[sp3dev] | WisTilt2: american is 01, european is 00 |
17:31.12 | WisTilt2 | Willd using jonpry's right now |
17:31.17 | jonpry | 1.1 |
17:31.37 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:31.51 | Willd | jonpry: And you're having no problems with it in smi? |
17:32.17 | jonpry | gpu0 in smi, gpu1 in ebi. does not work with gpu1 in smi2 |
17:32.58 | Willd | It didn't? |
17:33.17 | Willd | WisTilt2: I thought you got it working with gpu1 in smi? |
17:33.27 | jonpry | i guess it used to do more before i patched it |
17:33.29 | WisTilt2 | smi2+8 but i have it unlocked |
17:33.45 | WisTilt2 | black screen with gpu1 in smi2 base |
17:33.48 | Willd | Oh |
17:34.04 | Willd | WisTilt2: Thought you got textures.. |
17:34.05 | WisTilt2 | that why i think there is some alignment problem |
17:34.15 | *** join/#htc-linux leopesto (~leopesto@84.55.250.234) |
17:34.28 | WisTilt2 | i did but not in ebi |
17:34.48 | *** join/#htc-linux mgross029 (6b0a0bda@gateway/web/freenode/ip.107.10.11.218) |
17:35.16 | jonpry | textures but no smoke and flames |
17:35.54 | Willd | jonpry: Okay. |
17:36.04 | WisTilt2 | Alex[sp3dev] when you were trying gpu oc were you doing it directly via the registers or what? |
17:36.05 | jonpry | afaik the only combo that really works is ebi, patched libgles and patched libegl |
17:36.15 | *** join/#htc-linux bzo (~chatzilla@c-174-62-79-238.hsd1.ca.comcast.net) |
17:36.25 | Alex[sp3dev] | WisTilt2: via pll registers |
17:36.48 | Alex[sp3dev] | WisTilt2: i was not trying, i was overclocking. it did bring a couple fps, but not many |
17:37.02 | arrrghhh | 4-5fps IIRC Alex[sp3dev] |
17:37.20 | jonpry | that would be pretty good on birds |
17:37.41 | bzo | I thought we were fpu limited on birds? |
17:38.05 | jonpry | another 4-5fps would be like double |
17:38.50 | bzo | WisTilt2: to OC the memory, did you make any chances beside the table entries? |
17:38.56 | bzo | s/chances/changes |
17:38.57 | WisTilt2 | yes |
17:39.06 | WisTilt2 | hang on |
17:39.52 | WisTilt2 | comment out the axi_160mhz stuff that forces it to 160mhz |
17:40.02 | WisTilt2 | otherwise axi stays at 160 max |
17:40.19 | WisTilt2 | thats down in the fixup |
17:40.29 | bzo | hmm, did that. I'm not seeing any difference in the benches when I put the axi up to 192 |
17:41.11 | WisTilt2 | you took out all the other IF's below this -> if (pll0_needs_fixup && t->pll == ACPU_PLL_0) |
17:41.11 | WisTilt2 | SLOWER_BY(t->a11clk_src_div, 2); |
17:41.55 | WisTilt2 | also changed max axi khz in board file to 200 but with those commented out it shouldnt matter |
17:42.31 | WisTilt2 | in dmesg at boot, what does your adjusted table show for axi at the top rates? |
17:42.47 | bzo | I just forced axi_160mhz=0, the table does reflect the 192 in dmesg |
17:43.06 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:43.31 | WisTilt2 | you're gsm right? |
17:44.01 | bzo | no, rhod400 |
17:44.16 | arrrghhh | another hoodlum |
17:44.35 | WisTilt2 | i cant remember whos got what half the time. so you should have made the table changes in this table /* 7x01/7x25 turbo with CDMA-only modem */ |
17:44.50 | WisTilt2 | which i know you already know, just confirming |
17:45.00 | bzo | no, all the rhods use the same pll config |
17:45.02 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:45.20 | detule | turbo w gsm right? |
17:45.26 | bzo | yes |
17:45.27 | WisTilt2 | ? not from the tests i did with rpierce99 they dont |
17:45.49 | WisTilt2 | i had to change the cdma table for his to get axi to change |
17:46.04 | bzo | the wrhods need the higher pll0 gsm freq because they are dual mode |
17:46.26 | bzo | that's odd, I changed the gsm table, and it is reflected in dmesg |
17:46.28 | WisTilt2 | but i had a lot of other stuff commented and added so that may not be accurate |
17:47.24 | WisTilt2 | what does your adjusted table looked like at boot if you want to paste it |
17:48.12 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:48.33 | bzo | I'll have to reboot |
17:49.00 | bzo | WisTilt2: I see you pushed the panel init seq, any reason for me not to also push the power logic of the .27 code? |
17:49.12 | WisTilt2 | i just want to compare it to mine. i dont think i changed anything else though |
17:49.58 | detule | jonpry, no go w CM EGL |
17:49.59 | WisTilt2 | which power logic we talking about? not that gpio stuff that turns off panel |
17:50.14 | bzo | what I'm running right now is the .27 version, with the init seq you just added |
17:50.36 | bzo | the .27 has rhod specific power on/off stuff |
17:50.48 | WisTilt2 | vreg stuff or gpio? |
17:50.56 | jonpry | detule, no textures or just fail? |
17:51.02 | detule | no textures |
17:51.08 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-128.dynamic.mnet-online.de) |
17:51.09 | bzo | I think mainly not turning off the vreg for rhod400/500 |
17:51.17 | detule | rebooting with EGL from the link |
17:51.39 | *** join/#htc-linux Akirax (~androirc@117.Red-88-27-159.staticIP.rima-tde.net) |
17:51.48 | WisTilt2 | yeah the vreg stuff is good. i know there was some gpio stuff at one time that wasn't right and panel vregs are what should be there |
17:52.28 | bzo | seems like we need to do more digging around on the panel power for rhod400/500 |
17:52.42 | bzo | maybe that is why the sleep power is so much worse than gsm |
17:52.57 | WisTilt2 | aren't those also eid panels? |
17:53.22 | WisTilt2 | the panel sleep registers should be the same |
17:53.48 | detule | jonpry, got it going with that EGL -> any clue where this one is from? |
17:53.57 | bzo | the .27 code has 2 vregs controlled for non-cdma rhods |
17:53.58 | detule | it can't be just a simple patch -> bad boy is 4K larger |
17:54.05 | bzo | wonder if there is some equiv we're missing for cdma |
17:54.28 | jonpry | detule, well its different lineage |
17:54.44 | jonpry | there are lots of patches to cm7 egl |
17:54.51 | WisTilt2 | 400/500 should be panel type 0x14 so same vregs should be for 210-500's |
17:55.28 | WisTilt2 | i know the auo rhod100's were the only ones different when i was testing all this stuff last year |
17:55.33 | bzo | that's what we first assumed, but after a bunch of testing we ended up not doing any vreg control in .27 for the rhod400/500 |
17:55.35 | jonpry | i found some code on google that suggested at least one method. but it was horrible. basically killed eglinitialization in the middle. i have a theory as to what exactly that does though |
17:55.42 | *** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net) |
17:56.18 | detule | i am starting to develop a serious dislike for blobs |
17:56.27 | Alex[sp3dev] | detule: only starting? |
17:56.28 | WisTilt2 | bzo: i wonder if back then we still had that funky gpio power stuff in for 400/500 and thats why vregs didnt work. you have vregs patched for 400/500 locally and its working? |
17:57.04 | bzo | no, I'm running the .27 version which disabled vreg control for the rhodw |
17:57.07 | *** join/#htc-linux bitrot (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:57.15 | bzo | it appears that the vreg IDs are different in those devices than gsm |
17:57.21 | detule | neocore 20.1 identical to what i get in froyo |
17:57.46 | bzo | turning off the gsm panel vreg on cdma breaks other stuff |
17:58.20 | WisTilt2 | ah, ok that rings a bell. vreg should work if we get the right id's then for those devices |
17:58.35 | bzo | we'll have to ask [acl] when we catch him, I think he did the most digging into this |
17:58.49 | WisTilt2 | so you're pushing the fix to disable vreg on those that sounds like a plan until we get the id's |
17:58.56 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
17:59.04 | emwe | bzo: WisTilt2: vregs used for RHODW will kill data more or less instantly in sleep. need to trace pcom vreg calls in haret to find out what it is on RHODW. |
17:59.23 | bzo | yeah, the .39 version is a hack really, it enables the vregs but never turns them off |
17:59.40 | WisTilt2 | hi emwe. hopefully cdma doesn't use same vreg for powering data and panel:) |
17:59.42 | emwe | bzo: WisTilt2: also added to more gpio toggled on panel collapse/suspend traced via haret. |
17:59.59 | bzo | WisTilt2: but then again if you're seeing good sleep power without turning off the vreg, maybe there's no point |
18:00.02 | emwe | WisTilt2: well, if we toggle the once which are in there, data/radio dies immedeately. |
18:00.20 | emwe | s/once/ones |
18:01.02 | bzo | emwe: so was it ever established that we should control any gpios for panel sleep? |
18:01.56 | emwe | bzo: i just traced what happens in wince... the two new might be digitizer related or so. |
18:02.21 | WisTilt2 | emwe does it kill only data or does the whole radio die so you cant get calls either? |
18:02.34 | emwe | WisTilt2: from the looks it kills radio entirely. |
18:02.47 | emwe | so x-signal-bars |
18:02.56 | WisTilt2 | thats not good. no way were they stupid enough to power radio and panel off same vreg |
18:02.57 | emwe | couldn't even get it back on with airplane-toggle. |
18:03.29 | jonpry | detule, buries in here http://code.google.com/p/openeve/issues/attachmentText?id=108&aid=1080002000&name=gb-cm7-110521.patch&token=01f23178c898243d1654142146eda434 |
18:03.29 | bzo | emwe: often times the vreg changes are logged in the wince dmesg |
18:03.32 | emwe | Alex[sp3dev]: hey. you got a haret cheat sheet for yourself where have noted down tracing memory from pcom/dex messages by chance? |
18:04.18 | bzo | emwe: i have tried it before, you have to mmutrace the dex ring buffers |
18:04.29 | Alex[sp3dev] | emwe: i have not ever traced pcom. i disassembled all drivers and nk.exe when writing panel and camera |
18:04.34 | detule | jonpry, how about this http://code.google.com/p/openeve/issues/detail?id=106#c15 |
18:05.00 | jonpry | yeah thats the same thing |
18:05.13 | emwe | Alex[sp3dev]: good you got those skills :) thanks. |
18:05.16 | jonpry | its ugly though |
18:05.33 | Alex[sp3dev] | emwe: anything particular confuses you about dex? |
18:05.37 | emwe | detule: yah, i am just too lazy to assemble the cmds myself. you got haret commands at hand by chance? |
18:05.56 | emwe | Alex[sp3dev]: nah, wan't to see what pcom calls regarding vreg setup are issued. |
18:06.10 | jonpry | the jist of the problem is that it returns the extension pointer from any opengl renderer that supports it. so the whole thing is pretty is busted if pixelflinger does the extension and your blob doesn't |
18:06.10 | emwe | Alex[sp3dev]: assuming it's the same as we do. (controlling them via dex) |
18:06.49 | bzo | WisTilt2: http://pastebin.com/MA06xc6M |
18:07.42 | Alex[sp3dev] | emwe: as for panel, i'm sure it is done properly by markinus and abel. actually, vregs are not hard to find in disasm, they're called via an ioctl in most drivers. you could get a kovs/raph dll and compare it with linux code drivers |
18:08.47 | WisTilt2 | bzo: that looks correct. you dont see any change in memory speed going from stock to this setting? |
18:09.16 | emwe | Alex[sp3dev]: disptools.dll is the right starting point? |
18:09.21 | WisTilt2 | what freq is your PLL2 at after fixup? |
18:09.26 | WisTilt2 | should be 768mhz |
18:09.36 | bzo | emwe: was a long time ago, don't remember really but I think it involved mmutracing the addresses around +0xfc100 |
18:09.58 | emwe | giving it a go later. thanks guys. |
18:10.00 | bzo | WisTilt2: yes to both |
18:10.16 | detule | ok so this return NULL, returning no pointer at all for these extensions, that doesn't mess other things up? |
18:10.40 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5667.dip.t-dialin.net) |
18:10.43 | WisTilt2 | bzo: this is mine currently running at 614400 and memory is far higher than without it -> http://pastebin.com/04cdUF0W |
18:11.09 | bzo | what are you using to bench? |
18:11.11 | Alex[sp3dev] | emwe: yep |
18:11.19 | WisTilt2 | quadrant that does all the tests |
18:11.43 | WisTilt2 | not to mention noticeably faster just using the device |
18:11.44 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:12.06 | bzo | I'm using the free one so it only shows the overall, but that score was lower than what you mentioned, even though mine has a higher CPU OC |
18:12.20 | WisTilt2 | whats your total score? |
18:12.37 | detule | i think those IO operations seriously affect the quadrant score |
18:12.40 | bzo | 513 I think? |
18:12.46 | detule | like my ext4 score is in the 200s |
18:12.57 | detule | because somehow it hates those IO operations |
18:13.00 | WisTilt2 | at 672mhz oc my best was 454 i think it was |
18:13.06 | WisTilt2 | 545 |
18:13.23 | WisTilt2 | let me run it at 614400, i dont remember |
18:13.36 | bzo | I think that's what you said yesterday |
18:14.01 | bzo | I should try down clocking to 614400, maybe there's some weird multiplier stuff going on as related to the axi? |
18:14.13 | WisTilt2 | let me run this and curious what differences your memory score is from mine |
18:14.46 | WisTilt2 | thats possible. highest ive tried is 672 |
18:15.01 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:15.28 | *** join/#htc-linux [acl] (~abel@96.246.167.90) |
18:15.29 | WisTilt2 | ok at 614400 total is 501, memory is at 246 |
18:15.31 | detule | also do you both have jit enabled/disabled? perhaps that too is affecting some of the quadrant scores |
18:15.40 | WisTilt2 | i have jit disabled |
18:15.43 | bzo | same |
18:15.44 | WisTilt2 | jit:fast |
18:15.47 | [acl] | emwe: yo |
18:15.52 | jonpry | hi [acl] |
18:15.56 | [acl] | sup bretheren |
18:16.03 | rpierce99 | i thought it was int:fast |
18:16.15 | emwe | [acl]: yo. supper time. ttyl. sry. |
18:16.16 | jonpry | [acl], how can we get more gpu1? |
18:16.18 | WisTilt2 | yeah whatever it is but :fast is what i have |
18:16.32 | [acl] | emwe: damn.. ok let me know when ur back |
18:16.43 | jonpry | i fixed 3d on gb for ya |
18:16.55 | bzo | WisTilt2: that 614400 tes is with axi=192? |
18:16.59 | [acl] | jonpry: great now help me figure this out. |
18:17.02 | WisTilt2 | [acl] thanks for saving me the trouble finding that gsm gpio for prox |
18:17.10 | WisTilt2 | bzo: yes |
18:17.14 | [acl] | jonpry: on haret kernel the damn vregs for gsm dont match my findings |
18:17.14 | jonpry | hrm |
18:17.24 | [acl] | jonpry: for panel that is |
18:17.42 | *** join/#htc-linux GNUtoo (~gnutoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
18:17.44 | [acl] | so im wondering if diff gsm rhods use diff vregs |
18:18.03 | [acl] | all i can say for sure, whatever is on haret now doesnt match what i have for a rhod 300 |
18:18.12 | WisTilt2 | if everyone would just get rhod300's we wouldn't have all this trouble:) |
18:18.17 | jonpry | can't all the gsm rhods use the same winmo image? |
18:18.38 | [acl] | jonpry: no clue.. do they? i know for cdma they are sort of similar if not identical |
18:18.41 | [acl] | not sure about gsm |
18:18.46 | [acl] | specially with the damn rhod 100 |
18:18.57 | [acl] | that thing should be labeled blackstone instead of rhod |
18:19.05 | [acl] | :-p |
18:19.17 | WisTilt2 | rhod100=paperweight |
18:19.19 | jonpry | it's been awhile since i downloaded one. but iirc enerygyrom did not specify a rhod version |
18:19.28 | [acl] | interesting |
18:19.36 | arrrghhh | lol |
18:19.46 | arrrghhh | [acl], AFAIK all CDMA RHOD's can use the same ROM's |
18:19.51 | arrrghhh | and all GSM RHOD's can use the same ROM's |
18:19.55 | [acl] | arrrghhh: thanks |
18:19.57 | arrrghhh | just can't mix GSM/CDMA, obviously. |
18:19.58 | arrrghhh | np |
18:20.07 | [acl] | in that case the gsm vregs are wrong on kernel |
18:20.14 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:20.22 | [acl] | should be bits 11 and 13 instead of whatever is being used now |
18:20.35 | jonpry | interesting |
18:20.45 | emwe | [acl]: man, i need to prep supper. you got good luck with RHODW vregs? need to look what you got... |
18:21.18 | bzo | [acl] entirely possible since WisTilt2 does not seem to be seeing any power differences on .39/.27, where .39 doesn't disable vreg |
18:21.18 | [acl] | emwe: well im still fixing the vregs for gsm. |
18:21.35 | emwe | you got some for cdma? or none at all. those we got kill data/radio immedeately on sleep |
18:22.04 | [acl] | emwe: cdma is a diff beast. uses 2 gpio but i cant tell which vreg yet. It isnt needed as much as gsm |
18:22.05 | emwe | [acl]: for me RHOD400 on GSM that is. network seems not to matter, though. just the variant. |
18:22.28 | [acl] | gsm can pass out and never wake up so needs vreg. cdma is fine and dandy just turning off the panel |
18:22.31 | emwe | [acl]: look at .35. added the two gpio. figured via haret. not sure we need more vregs. |
18:22.37 | emwe | ah. hm. |
18:22.42 | emwe | so i got another power sucker.. |
18:22.53 | [acl] | emwe: yeah do we do. gpio is not enough to power the panel. |
18:23.03 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:23.17 | emwe | ok, cool thing then :) |
18:23.27 | emwe | so, now supperina time. |
18:23.54 | detule | jonpry, how is this return NULL not breaking other calls that request extension pointers |
18:24.37 | jonpry | extension are called on an if they exist basis |
18:24.47 | [acl] | bzo: well i checked with Jb and we both recorded the same vregs. so patch is needed |
18:25.04 | *** join/#htc-linux bitrot (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:25.04 | jonpry | so it does stupid things like detects an extension in pixelflinger. then tries to use it w/ hardware renderer on |
18:25.06 | WisTilt2 | bzo: .39 does disable vreg in mddi_panel_blank |
18:25.30 | [acl] | WisTilt2: what vregs are you disabling ? |
18:25.49 | WisTilt2 | gp2 and gp4 |
18:26.10 | WisTilt2 | that all came from .27 i believe |
18:26.11 | jonpry | detule, this patch is totally not ideal, because it will also force surfaceflinger into doing some pretty slow things even though its using software renderer |
18:26.18 | [acl] | not sure where those came from, but that has to change |
18:26.31 | [acl] | WisTilt2: whatever vregs are 11 and 13, those are the ones should be used |
18:26.45 | [acl] | prob got lazy and it was left overs from topaz |
18:26.47 | [acl] | bastards |
18:26.54 | WisTilt2 | ok let me check that out. so those should be good on all rhods then? |
18:27.01 | [acl] | no, not cdma |
18:27.02 | jonpry | all the good stuff is |
18:27.03 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:27.26 | [acl] | detule: i need your help for a test. I emailed the list a few days ago |
18:27.35 | [acl] | with the correct gpio for prox |
18:27.37 | [acl] | for gsm |
18:27.38 | detule | rhod400 |
18:27.42 | WisTilt2 | 11/13 is rhod 210 and 300 then ? |
18:27.53 | [acl] | detule: no for gsm. it was 0x63 i think |
18:28.00 | [acl] | WisTilt2: i found that on a 300 |
18:28.23 | detule | [acl], ok i thought you were asking for me to test it out |
18:28.25 | WisTilt2 | k. ill set that up and give it a go. guess we need to add machine variant in panel code then |
18:28.49 | [acl] | detule: well you were the only one know who had a prox test |
18:28.53 | [acl] | for frx right ? |
18:29.04 | [acl] | wait ur cdm |
18:29.04 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:29.07 | [acl] | fawk |
18:29.10 | [acl] | never mind |
18:29.25 | detule | i can compile a froyo test kernel if you find a device to test it on |
18:29.34 | [acl] | im sure we can find some pig on xda |
18:29.36 | WisTilt2 | bzo: you're running the current .39 panel file right? |
18:29.50 | [acl] | those pigs will run anything |
18:30.07 | [acl] | anyways folks ill brb. meeting time. |
18:30.08 | bzo | WisTilt2: .27 panel code + your added seq for .39 |
18:30.22 | bzo | it's pretty much the same except for variant detection and vreg |
18:30.27 | WisTilt2 | so you have the vreg disable commented out in blank? |
18:30.42 | WisTilt2 | or in a variant |
18:31.02 | bzo | yes, for rhod400/500 vreg is not touched |
18:31.55 | WisTilt2 | ok was going to say its disabling it. if you already have all the variant stuff for the 400/500 then push it and ill make the changes for gsm vregs after i test them |
18:31.57 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:32.21 | WisTilt2 | no point in me coding variant if you already did it:) |
18:32.34 | bzo | ok |
18:32.42 | bzo | hmm, you're right vreg is getting disabled |
18:32.53 | bzo | wonder why it's not killing the radio for wcdma? |
18:32.54 | WisTilt2 | in panel blank right? |
18:33.07 | *** part/#htc-linux Alex[sp3dev] (~alexander@178.176.144.6) |
18:33.20 | bzo | yes |
18:34.46 | detule | jonpry, so these pixelflinger extensions that are not in the blob can we stub those out |
18:35.53 | rpierce99 | your 2nd favorite tablet is rooted jonpry |
18:37.02 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:38.28 | bzo | WisTilt2: pushed |
18:39.45 | WisTilt2 | k. this makes no sense. acl said vreg should be 11/13 but those are currently rftx and rfrx2 |
18:40.09 | bzo | ignore what the labels are, those were originally from the dream |
18:40.15 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:40.44 | WisTilt2 | ok |
18:41.11 | bzo | really, we should either define a machine specific set, or just go to using the raw ids |
18:41.37 | WisTilt2 | agreed. we need some organizing |
18:44.02 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:44.31 | WisTilt2 | bzo: that looks good. vregs changed so we'll see shortly if it works and maybe draws less in sleep also |
18:44.48 | *** join/#htc-linux vinceweis (4463ed13@gateway/web/freenode/ip.68.99.237.19) |
18:46.00 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:48.10 | bzo | WisTilt2: get quadrant of 464 with 614/192 |
18:48.24 | bzo | so it doesn't seem like the mem speed is getting changed for me |
18:48.48 | WisTilt2 | what memory score did you get, or does your's show that at the bottom |
18:49.01 | bzo | doesn't show me that |
18:50.00 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:50.58 | *** join/#htc-linux LordDeath (~LordDeath@xdsl-87-78-106-12.netcologne.de) |
18:51.08 | bzo | WisTilt2: can you git diff your acpuclock to double check none of your old mem OC code is still there? |
18:51.43 | bzo | because arrrghhh was seeing the results of the mem OC in your built kernel right? |
18:52.06 | WisTilt2 | i just actually set everything back to the git and only made the axi 192 change and commented out those IF's to be sure. |
18:52.26 | WisTilt2 | building now so ill see what score i get with same conditions as yours |
18:53.00 | *** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
18:54.15 | detule | i found a very effective task killer kills PIDs that my task killer widget can't get |
18:54.47 | detule | it's called angry birds -> after start/stopping it i have +90MB free according to this readout |
18:56.02 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
19:00.13 | *** join/#htc-linux Rajko (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs) |
19:02.31 | WisTilt2 | bzo: quadrant of 519 with 614/192 here. that is with the git acpuclock and 192 for axi and those IF's in fixup commented. |
19:02.55 | bzo | that is a mystery |
19:02.56 | WisTilt2 | arrrghhh ping ping |
19:03.47 | WisTilt2 | only other thing i have done is i have fb running in smi1, which could be that difference. |
19:05.46 | bzo | could be, refreshing the fb could usck up a lot of bandwidth |
19:07.15 | *** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com) |
19:08.03 | WisTilt2 | bzo: so run that again and we'll compare the individual numbers |
19:10.36 | WisTilt2 | bzo: just to make sure we're talking the right IF's, lines 744-749 commented out in acpuclock |
19:11.42 | bzo | I commented out the lines before that of axi_160mhz= and axi_200mhz= |
19:11.53 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-128.dynamic.mnet-online.de) |
19:12.38 | bzo | hmm, got a 521/246 with this quadrant |
19:13.27 | WisTilt2 | memory is 246? mine is 248 so we're right on |
19:13.38 | WisTilt2 | did you move fb? |
19:13.48 | *** join/#htc-linux gnutoo_ (~GNUtoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it) |
19:13.52 | bzo | no, I guess you get a better score with the paid version lol |
19:14.40 | WisTilt2 | well now you can change axi and see if memory changes |
19:15.10 | bzo | I'll try going back to regular mem speed |
19:26.11 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-128.dynamic.mnet-online.de) |
19:27.23 | bzo | WisTilt2: 508/248 with 614mhz/default mem |
19:27.50 | WisTilt2 | hmm, what axi value did it use in default? |
19:27.56 | bzo | 160 |
19:28.10 | WisTilt2 | is ahb 153600 |
19:28.16 | bzo | yes |
19:28.49 | WisTilt2 | ok let me run mine default and see. |
19:32.13 | *** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com) |
19:40.59 | WisTilt2 | bzo: 494/208 with 614/default here. which table are you changing axi in? |
19:41.33 | bzo | I reset acpuclock to git default |
19:41.52 | WisTilt2 | yeah but when you up axi where are you changing that to 192? |
19:42.45 | bzo | where the comment starts 7x01/7x25 turbo with GSM capable modem |
19:44.00 | WisTilt2 | ok, im changing line 134 and 135 from 120000 to 192000 and 122880 to 192000. have you tried making that change in the turbo cdma table for the heck of it? |
19:44.26 | bzo | no, because it prints out the table I changed in dmesg |
19:44.53 | WisTilt2 | run benchmark on memory only and see what you get |
19:45.23 | WisTilt2 | i just ran memory only and got 210 1st time, 208 2nd time |
19:45.54 | *** join/#htc-linux kiozen (~kiozen@ppp-88-217-6-59.dynamic.mnet-online.de) |
19:48.07 | bzo | hmm, around 200 |
19:50.06 | WisTilt2 | im booting with axi 192 again and going to run memory only. maybe something is skewed when you run full test. |
19:50.22 | WisTilt2 | should go from 208 up to 248+ |
19:50.36 | bzo | I ran the full test again and got 528/253 |
19:50.49 | bzo | maybe just running the mem test doesn't ramp up the cpu all the way? |
19:51.28 | WisTilt2 | well if you run memory test only it should still be relative with the increase |
19:52.02 | WisTilt2 | but you are probably right, cpu scaling may be causing the fluctuations |
19:52.06 | bzo | if I run cpu+mem, I get 254 mem |
19:53.16 | WisTilt2 | i just compared mem test @ axi 160 = 210 and @ axi 192 its 248-250 |
19:53.34 | *** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com) |
19:55.16 | WisTilt2 | bzo: weird lol. cpu+mem gave me mem=250 |
19:55.35 | WisTilt2 | thats only 2 above running by itself though |
19:55.35 | bzo | for 614/160? |
19:55.40 | WisTilt2 | 614/192 |
19:55.48 | WisTilt2 | i didnt try cpu+mem @ 160 |
19:56.12 | WisTilt2 | cpu is 1105 |
19:56.20 | bzo | isn't that what you got before for 192? |
19:56.36 | WisTilt2 | no, 160 i got 208-210 |
19:57.12 | bzo | I'm confused, I asked 614/160 and u said 614/192? |
19:58.25 | WisTilt2 | lol. well with cpu=614400 and axi 160mhz i get 208-210 mem test only. axi @ 192mhz i get 248-250 mem test only |
19:58.49 | WisTilt2 | only thing im changing is the 192000 in those 2 fields in table |
19:58.57 | *** join/#htc-linux vinceweis_ (4463ed13@gateway/web/freenode/ip.68.99.237.19) |
19:59.10 | bzo | so what was weird about "cpu+mem gave me mem=250"? |
20:00.00 | WisTilt2 | dont know but strange yes. cpu+mem with axi @ 192 i see 250 so mine isn't that much different from mem test only |
20:00.19 | bzo | ok |
20:01.05 | WisTilt2 | let me build from a clean git tree and only make those changes. maybe i still have some left over code talking directly to the registers who knows. i have so much stuff going on its possible |
20:03.02 | WisTilt2 | btw, those vregs acl said are definitely correct for the 300. only dropped power drain in sleep 1ma but i can tell when panel turns on the vregs are working, you get a snowy looking screen for a split second before graphics come on. |
20:03.36 | bzo | hmm, wonder if it is worth it then? |
20:03.57 | bzo | It sounds like one of the gpios emwe traced may be to power off the touchscreen |
20:04.02 | bzo | maybe that will be more power savings |
20:04.15 | WisTilt2 | 1ma probably not. the sleep mode for the panel is supposed to power off the chip itself so the regs are just the leftover 1ma |
20:04.40 | emwe | yeah, the gpio are just cosmetics... |
20:04.56 | emwe | so abel said vreg 11 and 13? |
20:05.02 | WisTilt2 | yes |
20:05.10 | WisTilt2 | they are working on the 300 at least |
20:06.05 | emwe | hm, we were toggling wince idx 3 and 4 on non-RHODW. hm :) |
20:06.20 | WisTilt2 | i believe in these panels when power is applied they init to their default state so that's why im seeing the blip before the main init's happen and graphics get drawn |
20:06.25 | bzo | emwe: you don't think the gpio is useful? |
20:06.46 | emwe | well, it has a 2ma consumption. yes, might be useful. but not *the* power saver. |
20:06.58 | emwe | don't hurt for me. |
20:07.22 | emwe | no issues since yesterday. |
20:08.01 | emwe | whonder what happens if i try 11/13 instead 3/4 ... |
20:08.56 | WisTilt2 | emwe what device is that? |
20:09.05 | emwe | RHOD400 on GSM here |
20:09.18 | WisTilt2 | might be a good test |
20:09.38 | emwe | so perhaps we are identical in that respect. who knows... |
20:09.53 | emwe | btw, pulled your vsync patch. missed that as well from .27 |
20:10.19 | WisTilt2 | yeah dont know what happened there. i had it for the 100's but missed all the others |
20:10.21 | *** join/#htc-linux bikerer (~bike@ti0128a380-dhcp0338.bb.online.no) |
20:11.10 | emwe | ah right, yeah. i got the 100 as well. |
20:11.12 | bikerer | woaah, are all the androd-msm-2.6.32 kernels broken totally? i cant compile things like coda and reiserfs amongst a million others |
20:11.59 | bikerer | tho thankfully less broken then huawis |
20:15.51 | detule | rpierce99, what's the verdict |
20:15.55 | *** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50) |
20:16.10 | rpierce99 | oh damn, lol i haven't tested it, i'll do that now |
20:16.29 | arrrghhh | bikerer, none of us are working on/with .32... |
20:17.38 | bikerer | arrrghhh, kk |
20:23.58 | rpierce99 | detule: still broken for me |
20:25.48 | *** join/#htc-linux helicopter88 (~helicopte@host128-84-dynamic.37-79-r.retail.telecomitalia.it) |
20:25.55 | detule | rpierce99, i got one more http://dl.dropbox.com/u/38520332/3.0/30ker_mod_11-29%232.tar.gz |
20:30.15 | detule | it's the first time i've been able to run a full logcat, also push pull works over here as well |
20:33.32 | rpierce99 | the first one worked for you? |
20:33.54 | detule | the first one worked one worked sporadically |
20:34.00 | rpierce99 | this one is working |
20:34.09 | rpierce99 | hasn't fully booted yet but ls and ps worked |
20:34.26 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-93-210.dynamic.mnet-online.de) |
20:40.40 | detule | alright hasn't blow up? |
20:40.53 | rpierce99 | nope still going strong |
20:41.11 | detule | great should make swapping kernels an easier affair |
20:41.31 | rpierce99 | yes, if we can get this patch into all of the other .3x and 3.x trees |
20:41.36 | rpierce99 | what was wrong? |
20:42.34 | detule | well i changed two things, the first kernel -> there was a limit on the amount of current that clients can draw out of the usb vbus that was something not so sane (only 2mA0 |
20:44.09 | detule | the second kernel -> enabled dualspeed for the the gadget driver which apparently adds support for dual-speed controllers |
20:44.41 | rpierce99 | so the mac is a dualspeed controller and and it wasn't getting enough power |
20:45.10 | rpierce99 | nice work |
20:46.19 | WisTilt2 | bzo: guess i have some of my other test code mingled in somewhere because im seeing the same results you are now with the clean git. changing axi in table makes no difference so after lunch i'll see what else i did. |
20:48.05 | rpierce99 | attempting my first kexec, wish me luck :) |
20:48.29 | detule | you'll be in love |
20:49.37 | emwe | bzo: do we yet support setting EBI1_CLK at all in clock-wince? whonder if that axi frequency playing has an effect. |
20:51.12 | arrrghhh | i've had kexec hang a few times |
20:51.17 | arrrghhh | but when it does work, 'tis awesome. |
20:51.59 | rpierce99 | yeah it looks like it hung and the android_usb gadget high speed config #1 |
20:52.08 | rpierce99 | s/and/at/ |
20:53.39 | rpierce99 | it was plugged in when i tried to kexec, to the laptop, so there maybe be something with the different usb gadget settings or adb messing with it |
20:53.56 | *** join/#htc-linux kiozen (~kiozen@ppp-93-104-93-210.dynamic.mnet-online.de) |
21:05.02 | detule | WisTilt2, when you are not busy, you think you can do some .gitignore + "rm --cached" magic on the 3.0 tree? :) |
21:08.11 | *** join/#htc-linux YataroX (user@54.sub-75-214-32.myvzw.com) |
21:13.51 | *** join/#htc-linux [acl] (~abel@96.246.167.90) |
21:14.24 | *** join/#htc-linux mgross029 (c0234f46@gateway/web/freenode/ip.192.35.79.70) |
21:18.49 | WisTilt2 | detule: guess you're talking about my autobuild, i can do that after i get these clock changes integrated:) |
21:19.28 | detule | sure thing, thanks for taking care of the autobuild, makes life easy |
21:19.48 | WisTilt2 | [acl]: those vregs are good on the 300. they only save us another 1ma in sleep but they are now working correctly. |
21:20.06 | [acl] | cool |
21:20.31 | [acl] | 210 should be the same |
21:20.32 | WisTilt2 | panel sleep mode powers off the chip itself so that extra 1ma is what the vreg's are drawing i guess |
21:22.10 | [acl] | WisTilt2: i only have a week or so with this gsm rhod before i have to return it. so im trying to get all the info out of it. |
21:22.11 | WisTilt2 | we can get jonpry to try that on his 210 to verify. bzo added machine variant to exclude 400/500 so if 210 works we'll leave it. |
21:22.37 | WisTilt2 | [acl] you're doing a great job so far:) i can always send you another one if you need for testing |
21:22.50 | *** join/#htc-linux detule (~detule@unaffiliated/d3tul3) |
21:22.56 | [acl] | ill let you know. |
21:23.10 | [acl] | thanks for the offer |
21:23.28 | [acl] | jonpry: yo.. ok i have some time now.. whats up with your progress ? anything juicy ? |
21:23.35 | WisTilt2 | unless JB's not using the one i sent him anymore, he can send you that one, either way we'll get you one if you need it. |
21:37.55 | [acl] | emwe: bro these are safe to wipe |
21:37.59 | [acl] | http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/commit/2a95877a891f035af1fefea5a564608cfe37362d |
21:38.03 | [acl] | they were needed for froyo |
21:38.05 | [acl] | but not ginger |
21:38.16 | [acl] | ls handles all that bawshit |
21:38.35 | emwe | just wanted to keep for "ideas" :) |
21:38.49 | emwe | you tried vreg 11/13 already? |
21:38.56 | emwe | on your RHOD400 i mean... |
21:39.10 | [acl] | on the 400? nope. It doesnt need it as bad as gsm |
21:39.10 | emwe | i can blank/unblank fine... |
21:39.21 | emwe | i'd say it's the opposite. |
21:39.25 | [acl] | gsm would go to sleep and never wake up. so needed vreg to give it a kick |
21:39.34 | emwe | ok, yeah, but power drain wise? |
21:39.41 | emwe | i am at 40%@7hours |
21:39.46 | emwe | overnight |
21:40.31 | [acl] | im sure im not getting the most out of it. |
21:40.38 | [acl] | still over 12 hours tho |
21:40.58 | [acl] | but then again it depends on what you do. |
21:41.43 | emwe | idle + googlesync + k9 only |
21:42.15 | emwe | during the day i am plugged mostly. listening to music at work. but i am only watching overnight "stats" so to say. |
21:42.37 | emwe | hm, 11/13 just killed my radio again. |
21:42.54 | [acl] | yeah i dont think thats for cdma |
21:42.58 | [acl] | its not on the wince code |
21:43.08 | [acl] | ive yet to locate it |
21:43.16 | emwe | ok. |
21:44.37 | [acl] | i have to patch .27 tonight. |
21:44.47 | [acl] | i couldnt paply that cifs patch that came in |
21:44.49 | [acl] | not sure why |
21:45.12 | [acl] | but i want to do the vregs tonight and some more changes on the gpio list. |
21:45.56 | [acl] | holy poop you ported the LS code ? woa.. awesome. you sir have saved me time |
21:46.38 | [acl] | the LS is the same for gsm. However it doesnt work on nand. Something is missing that im just not getting. I may need to try to enable it via microp instead of gpio. |
21:46.39 | emwe | ls is in there for quite a while |
21:46.45 | [acl] | i did not know |
21:46.46 | emwe | just updated your value array |
21:46.57 | [acl] | well thank you |
21:46.58 | [acl] | lol |
21:47.21 | emwe | and i got a bosch official bma150 driver in :P |
21:47.40 | [acl] | ahh i had to back port mine |
21:47.42 | emwe | had to adjust userland to support it, though. |
21:48.06 | emwe | so we can still use the other kernels and be good. |
21:48.34 | emwe | found it on CAs tree. and i rather take code from the company which manufactured the thing... |
21:49.13 | [acl] | interesting |
21:49.37 | [acl] | does it have the ability to change the delay? thats one thing im missing |
21:49.47 | [acl] | im fixed at a 200ms poll time |
21:49.54 | [acl] | but i know userland can request different rates |
21:49.55 | emwe | ofc it does |
21:50.03 | emwe | but yeah, it is 200ms what userland wants. so... |
21:50.11 | emwe | even 100ms in gallery3d iirc |
21:50.31 | [acl] | hmm cool |
21:50.33 | emwe | let's say it's working fine. |
21:50.53 | emwe | look at the board power hooks for it. a bit sluggish what i did... |
21:51.14 | emwe | bma150 power wise is likely vreg or just the spi bus... dunno |
21:53.15 | [acl] | damn |
21:54.25 | [acl] | i guess i need to see the bma driver code and see how it works. im just using a ported one |
21:55.29 | emwe | didn't compare them. just saw bma150-microp.c was a no-go. |
21:55.39 | emwe | and then there's been those 100 htc variants around there. |
21:55.46 | [acl] | haha yeah |
21:55.50 | [acl] | i think i took the supersonics |
21:56.02 | [acl] | or some other bma one |
21:56.05 | [acl] | desirec |
21:56.07 | [acl] | not sure |
21:56.30 | emwe | see ^^ |
21:56.53 | [acl] | this bad boy? |
21:56.53 | [acl] | http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/blobs/htc-msm-2.6.35/drivers/input/misc/bma150.c |
21:57.28 | emwe | yap. |
21:57.31 | [acl] | directly from bosch huh .. |
21:57.43 | [acl] | damn so you cant use the aosp libsensors |
21:57.59 | [acl] | you had to roll your own i suppose |
21:58.16 | emwe | we are using our own anyway. |
21:58.26 | [acl] | own way ? |
21:58.40 | emwe | its a AkmSensor fork. |
21:58.48 | emwe | puh... already wrote this once today.. |
21:59.06 | [acl] | interesting |
21:59.07 | emwe | it's been put together to find the akm or the bma sensor |
21:59.15 | emwe | not just one thing. |
21:59.18 | [acl] | oo ic |
21:59.26 | emwe | and i added some differentiation for old or new bma driver |
22:00.08 | emwe | it's EvdevSensor in our tree. but it can be slimmed down again. it was planned as a multi-sensor all-in-one class inititally by stinebd. |
22:00.52 | [acl] | ill have to see |
22:06.06 | [acl] | emwe: this is something we will need to discuss later |
22:06.07 | [acl] | http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/blobs/htc-msm-2.6.35/arch/arm/mach-msm/board-htcrhodium-panel.c |
22:06.46 | *** join/#htc-linux mastermerlin (~Adium@p4FEE5667.dip.t-dialin.net) |
22:06.55 | emwe | regarind nand? yeah. |
22:07.12 | emwe | it's the .27 stuff more or less. |
22:07.14 | [acl] | but i gotta go now.. just landed a new client..lol. so time for a quick meeting |
22:07.21 | WisTilt2 | either of you guys know if we are not using all the params in clock-wince msm_clock_parameters? |
22:08.42 | [acl] | WisTilt2: if we are not ? |
22:09.02 | WisTilt2 | are some not used from that table and setup elsewhere? |
22:09.03 | emwe | as in not setting all clocks? |
22:09.13 | WisTilt2 | like adsp_clk for example |
22:09.27 | [acl] | WisTilt2: adsp is done by a9 so should be left alone |
22:09.41 | WisTilt2 | we're using pmdh not emdh right? |
22:09.53 | [acl] | yup |
22:10.32 | *** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net) |
22:10.33 | WisTilt2 | k. major changing in progress:) |
22:12.00 | [acl] | i keep all the clocks on nand code. so i can keep track of what shuts them down . this wya i know if a9 handles it or not. |
22:12.56 | WisTilt2 | so is adsp still running at 250mhz or do we know |
22:13.09 | [acl] | we dont know since no one touches it :-(. |
22:13.15 | [acl] | all i know its goes on and off on its own |
22:15.13 | [acl] | emwe: can you see if you can apply that cifs patch ? |
22:16.26 | emwe | [acl]: save you the trouble, do make menuconfig and copy .config over to arch/arm/configs/htc_msm_android_defconfig |
22:16.40 | emwe | and if you are at it, hyc request some network module ages ago as well :) |
22:17.48 | [acl] | man thats going to change so much |
22:17.58 | [acl] | god knows what else wasnt made by menu config |
22:19.05 | *** join/#htc-linux pw (~pw@coffee-addicts.org) |
22:19.05 | emwe | nah, it should be good |
22:19.14 | emwe | i've never hand-edited the bitch. |
22:19.49 | [acl] | you did but you know how old this config is |
22:19.54 | [acl] | i mean you may have not |
22:19.57 | [acl] | but you never know |
22:20.39 | emwe | i always copied over from .config. there must be no surprises. |
22:21.44 | [acl] | well thats what i mean, if the .config is diff than the defconfig that means its dirty |
22:21.52 | [acl] | in reality it should be close or identical |
22:22.05 | emwe | it *is* identical. |
22:22.15 | [acl] | oo |
22:22.44 | emwe | i always menuconfiged on .27 and i think i was the last messing with htc_msm_android_defconfig. |
22:23.11 | *** join/#htc-linux ellisway (ellis@83.167.180.118) |
22:23.16 | [acl] | emwe: ohh ok.. i didnt know you already checked it |
22:23.32 | *** join/#htc-linux eway (ellis@188-220-43-90.zone11.bethere.co.uk) |
22:23.41 | [acl] | anyways bro i gotta go now. ill ttyl |
22:24.31 | emwe | laters log reader ;) |
22:24.39 | arrrghhh | heh |
22:38.29 | *** join/#htc-linux mitsutaka (~mitsutaka@g1-27-253-191-66.bmobile.ne.jp) |
23:17.13 | *** join/#htc-linux d3tul3 (~detule@pool-96-234-141-27.bltmmd.east.verizon.net) |
23:19.34 | *** join/#htc-linux dr1337 (~textual@112.97.96.58.static.exetel.com.au) |
23:21.10 | *** join/#htc-linux mes (~mes@S0106000ce55186df.cc.shawcable.net) |
23:29.42 | *** join/#htc-linux MethoS-- (~clemens@134.102.106.250) |
23:37.55 | *** join/#htc-linux MethoS-- (~clemens@134.102.106.250) |
23:38.10 | WisTilt2 | arrrghhh: without any oc'ing whats the best fps you get in neocore when textures are working? |
23:38.23 | arrrghhh | that's a good question |
23:38.32 | arrrghhh | i've seen everything from 15-18fps... |
23:38.37 | arrrghhh | i don't think i've seen more than 18 w/o OC tho. |
23:38.55 | WisTilt2 | how much more do you get when oc'd and how much ocing? |
23:39.30 | WisTilt2 | just a ballpark |
23:40.16 | d3tul3 | WisTilt2, 3.0 stock scores ~20.5 for me in neocore |
23:40.27 | d3tul3 | what do you have it up to? |
23:40.34 | arrrghhh | maybe 2-4 FPS more WisTilt2 |
23:40.34 | WisTilt2 | that with textures? |
23:40.40 | arrrghhh | i don't think i've seen over 20fps on RHOD tho |
23:40.44 | d3tul3 | yes with textures |
23:40.54 | WisTilt2 | you both have 400's |
23:41.05 | WisTilt2 | i know you do arrrghhh |
23:41.08 | d3tul3 | yes |
23:41.19 | arrrghhh | indeedy |
23:41.29 | d3tul3 | this with jonpry's patched _qcom blob and the egl blob from that thread |
23:42.15 | WisTilt2 | well funny thing is the gpu is running off PLL0/4 all the time so on cdma the gpu is running at 49mhz and gsm its 61mhz. way under its rated speed |
23:42.26 | arrrghhh | damn |
23:42.27 | WisTilt2 | no one ever changed the divider for it |
23:42.42 | arrrghhh | ll |
23:42.46 | rpierce99 | lol |
23:42.47 | arrrghhh | s/ll/lol/ |
23:43.03 | WisTilt2 | so you get better fps with oc when pll0 goes up but thats it, not much |
23:43.22 | rpierce99 | when you put up the test kernel for this can you include d3tul3's patch to usb? :) |
23:43.38 | WisTilt2 | im trying to find what that gpu is rated at and have no idea but im pretty sure its a hell of a lot higher than 61mhz |
23:43.53 | rpierce99 | you would think |
23:44.01 | WisTilt2 | usb patch? what'd he fix |
23:44.06 | rpierce99 | mac adb |
23:44.10 | WisTilt2 | cool, what was it |
23:44.21 | d3tul3 | er I can commit it in the .39 tree |
23:44.47 | rpierce99 | detule: well i changed two things, the first kernel -> there was a limit on the amount of current that clients can draw out of the usb vbus that was something not so sane (only 2mA0 |
23:44.47 | rpierce99 | [2:44pm] detule: the second kernel -> enabled dualspeed for the the gadget driver which apparently adds support for dual-speed controllers |
23:44.50 | d3tul3 | if you give me an hour or two i need to find a better way to say yes to one defconfig |
23:45.15 | WisTilt2 | ah, good find |
23:45.49 | rpierce99 | sorry didn't mean to derail |
23:45.56 | rpierce99 | continue fixing our gpu |
23:47.02 | d3tul3 | i was under the impression gpu, along with most other things run off of PLL1 |
23:47.49 | WisTilt2 | me too but it looks like pll0. either way the divider is locked at 4 so its still never going to run at where it should be |
23:48.56 | d3tul3 | yeah but 960/4 (is PLL1 960?) makes for a saner value than 49mhz |
23:49.01 | WisTilt2 | i need to make a test kernel for one of you guys to run on those cdma's since they use 196 instead of 245 so i can get the bitmask that is being set |
23:49.46 | WisTilt2 | when does pll1 actually get to 960? 480 is the highest since its /2 in that rate |
23:50.12 | WisTilt2 | gpu runs off the adjusted table pll |
23:50.53 | dr1337 | hey what's the difference between msm7627 and qsd8k? |
23:51.12 | dr1337 | according to wiki they are essentially the same |
23:51.25 | *** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com) |
23:51.30 | d3tul3 | brb |
23:52.35 | *** join/#htc-linux d3tul3 (~oliver@pool-96-234-141-27.bltmmd.east.verizon.net) |
23:52.54 | WisTilt2 | arrrghhh or rpierce99 can you dl this kernel and grep dmesg for GPU MASK: value |
23:53.03 | d3tul3 | WisTilt2, i am just looking at the PLL dump at bootup which also lists PLL0 for my CDMA device at 245mhz |
23:53.07 | arrrghhh | i can in ~30mins or so |
23:53.21 | rpierce99 | will be too late |
23:54.11 | *** join/#htc-linux jonpry (~jon@unaffiliated/jonpry) |
23:54.48 | d3tul3 | this is what I am seeing http://pastebin.com/d77V3UvD PLL1 listed at 960 though i guess that doesn't account for any dividers |
23:57.13 | WisTilt2 | cdma devices should be on 196mhz i thought |
23:57.59 | d3tul3 | PLL3 is 196, that might be different on gsm |
23:58.30 | WisTilt2 | d3tul3 check your adjusted table and see what rates you have that are derived off those pll's |
23:58.53 | d3tul3 | alright what's a good way to check that adj table |
23:59.13 | WisTilt2 | its the one either above or below what you pasted |
23:59.22 | *** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star) |
23:59.32 | WisTilt2 | right above it |