IRC log for #htc-linux on 20111129

00:00.22rpierce99meter is back up to 40, so if that's accurate the life is pretty good in comparison
00:00.42WisTilt2were you just in a call to drop it like that?
00:00.43rpierce99but i doubt it's right
00:00.47rpierce99nope
00:00.56rpierce99just screen on/screen off
00:01.32WisTilt2yeah probably need new model to get the state of that battery across all levels
00:01.58WisTilt2mine 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.57WisTilt2bzo you still at the kbd?
00:46.17bzowhat's up?
00:47.16WisTilt2figured 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.16WisTilt2PLL2 @ f8005338: MODE=00000007 L=00000023 M=00000000 N=00000001 freq=672000000 Hz (672 MHz)
00:47.41WisTilt2axi and ahb oc from there
00:48.17WisTilt2i also changed the table so the highest value has axi at 192mhz and works quite fast
00:48.30bzoI had assumed that axi/ahb followed pll0/1, but maybe it follows whatever pll the cpu is using?
00:48.56WisTilt2yep exactly what its doing, following the cpu.  we need to adjust the tables though so they are optimized
00:49.07bzois 192 the 40% OC?
00:49.09WisTilt2this thing is hauling the mail now
00:49.27WisTilt245%
00:49.47arrrghhhhauling the mail now.  can't say i've ever heard that phrase before WisTilt2 :P
00:50.01WisTilt2axi at 200 is ok too but no noticeable gain and probably pushing it
00:50.09WisTilt2lol
00:50.16WisTilt2thats an old saying
00:50.22WisTilt2for old people i guess:)
00:50.24bzomaybe we should create an axi_192mhz variable and have it work like the existing 160/200 ones?
00:50.31WisTilt2yes i agree
00:50.40arrrghhhhahaha
00:51.05WisTilt2i have the logic that determines that commented out so it can actually run at the higher levels but 192var would be perfect
00:51.33bzoand we could just tie it being enabled to having an oc_freq_khz?
00:52.21WisTilt2yep.  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.45jonpryisn't the axi_200 stuff for turbo devices like ours?
00:52.47WisTilt2once jonpry gets composite working these babies are going to fly
00:52.58bzobtw, 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.01WisTilt2axi_200 never tests true the way it is
00:53.16arrrghhh.27 panel code on .39
00:53.20arrrghhhsounds like blasphemy
00:53.29WisTilt2bzo you need the fixed panel code for .39, somehow i missed stuff when we moved it over
00:53.50bzoarrrghhh: most of our device specific code is a copy from .27
00:54.02arrrghhhyea, i remember peoples sayin that
00:54.04WisTilt2last night i got .58% per hour, that was with bma150 off also
00:54.22bzoit got missed because .39 was "forked" before all those changes
00:54.39WisTilt2yep, jonpry had to go and get ahead of the curve so fast hehe
00:55.15bzoWisTilt2: do you have anything newer on the panel than what .27 has?
00:55.45WisTilt2dont think so.  .27 panel is my stuff still isnt it?  should all be there
00:55.53WisTilt2the init part anyway
00:56.02bzojonpry: the ax_160 is for our "turbo" devices, the 200 is for newer stuff
00:56.49bzoWisTilt2: do you want to push it, or shall I?
00:57.09WisTilt2checking .27 to see if its all there hang on 1
00:57.40WisTilt2nope its not there in .27 on the current git either
00:57.53WisTilt2all the vsync/hsync stuff is gone
00:58.07bzook, it's all you then
00:58.44WisTilt2after i added it back yesterday i could swear the stuff on the panel looks sharper
01:00.00jonprywhat is non turbo speed then?
01:00.14arrrghhhquittin time, cya guys
01:00.30bzofrom what the acpuclock tables have, 128mhz
01:01.20bzoI guess the mobile guys are not big into running at full rated spec
01:01.30bzoI mean wtf is 160mhz also?
01:01.51jonpryaxi might be synchronous with ram
01:02.11bzoyou mean async?
01:02.19jonpryno
01:02.39bzoI don't follow
01:02.49WisTilt2axi is for sure. chip allows ahb or axi and we're in axi
01:02.50jonprylike 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.59jonpryer thing
01:03.22bzowhy wouldn't you run it at the rated ram speed though? i.e. 133mhz, 166mhz, etc
01:03.46jonpryso you "can" clock l3 to probably 250mhz. but this isn't really an option with 166mhz ram for example
01:04.35bzooh, actually, it's probably the closest they can divide the cpu clock to
01:05.09jonprysounds right
01:05.41WisTilt2panel commit is pushed
01:06.37WisTilt2jonpry: 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.07jonpryi dunno. does that mean ram is running at 192mhz also?
01:07.13WisTilt2yep
01:07.23bzoit's hard to imagine ram manufactured 3 yrs ago that wouldn't bin to at least 200mhz
01:08.03jonprythey don't sell better than 5ns lpddr parts
01:08.04WisTilt2i 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.41bzoI think 5ns was the top bin for all ddr2
01:09.02bzobut toward the end, all the parts could pretty much hit that bin
01:09.49bzohopefully htc actually bought 166mhz ram to support turbo mode
01:10.04bzobecause in that case, going up to 192/200 is not a huge jump up in spec
01:10.45WisTilt2yeah, no telling with them though.  ill try going up to say 220 or so and see if it crashes
01:10.51jonprywhat is the next speed?
01:11.08*** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star)
01:11.20WisTilt2211
01:11.30WisTilt2230 after that
01:11.45WisTilt2maybe ill just go for 230 first:)
01:11.48jonpry230 sounds like a winner
01:12.27*** join/#htc-linux rpierce99 (~rpierce99@96-42-102-103.dhcp.stcd.mn.charter.com)
01:13.24bzohmm, it is slightly problematic though that axi is tied to cpu freq
01:13.36bzotricky to maximize both value at the same time
01:18.31WisTilt2no 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.28WisTilt2wow
01:21.45WisTilt2yeah that made a significant difference. memory went up to 252 and overall is now 524
01:24.58fakkerpoof
01:26.33*** join/#htc-linux Rob2222 (~Miranda@p4FFF0387.dip.t-dialin.net)
01:28.19WisTilt2bzo: 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.51WisTilt2here's the freq table im using if you want to give it a go -> http://pastebin.com/nMgMqcgF
01:35.02jonprytouchpad gets like 3000 in quadrant
01:35.22WisTilt2nice
01:35.32WisTilt2stock clocks?
01:35.47jonpryyes
01:35.55jonpry2800 or something
01:36.11jonpryand 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.07WisTilt2thats some overclocking.  whats the cpu freq normally?
01:38.13jonpry1.2ghz
01:38.27jonprybuts 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.55WisTilt2well 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.22WisTilt2jonpry, 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.05jonprydur
05:27.17rpierce99I'm at 16h 8m and still not dead!
05:27.51jonpryis that a record?
05:28.04rpierce99no
05:29.15rpierce99just happy because like 5h ago it was saying like 20%, i'm sure it's just a bad model
05:29.36rpierce99trying to generate a good one by letting it die, but it's taking so long!
05:29.50jonpryusing 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.52rpierce99haha, 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.32dr1337i 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.12ftozHi, 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.46d3tul3hey 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.44rpierce99hey d3tul3
14:55.40d3tul3you 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.05rpierce99in a few, send over a link and i'll jump on it when i'm done eating breakfast
14:56.25rpierce99i'm also generating a battery model, so it might be a little bit
14:56.36d3tul3sure 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.59crypticmofohi all
15:55.08crypticmofoanyone here on a tp2 running android ?
15:55.31crypticmofoif so how is it
15:56.05rpierce99gets 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.00crypticmofoaw yea
15:58.03crypticmofoi just read the status
15:58.18crypticmofoi wish i had programming knowledge and what not i could help
15:58.57rpierce99#xdandroid is where you'd want to discuss the particular build for the tp2
15:59.05crypticmofothanks
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.27jonpryhi 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.46detulehey jonpry
16:48.23*** join/#htc-linux crypticmofo (~crypticmo@c-67-164-217-108.hsd1.ca.comcast.net)
16:48.27crypticmofoumm k
16:48.53crypticmoforpierce99 can you give me the link to the xandroid chan again if you don't mind ?
16:49.16rpierce99#xdandroid, all you do is type "/join #xdandroid" and you don't need a link
16:49.24crypticmofooh
16:49.25crypticmoforotfl
16:49.29crypticmofoi was doing xandroid
16:49.32crypticmofonot xdandroid
16:50.18*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs)
16:52.02detulerpierce99, 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.24rpierce99k, my phone has been generating the battery model all morning
16:52.30rpierce99hopefully its a good one after all this time
16:53.09jonpryi had trouble with some of wistilt2's pm patches before
16:53.36jonpryhe 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.37detulewell locally i've reverted the IDLE stuff
16:54.00detuleit causes some overall quirkiness in operation on 3.0
16:54.06jonpryreverted his patches and it was down to 50 again. he said this wasn't possible or something
16:56.41detuleso did hacking out those 12c's from the binary fix the missing textures in neocore?
16:57.13rpierce99hey jonpry does ba tree app prevent sleep, or do i need to turn on don't sleep when plugged in
16:57.44jonprydetule, yes when used w/ the patches libEGL
16:57.52jonpryrpierce99, shouldn't prevent sleep
16:58.30rpierce99so if its generating a model i need to prevent sleep myself
16:58.47jonpryif you want it to keep processing
16:58.58rpierce99k, that probably explains why its taking so long :)
16:59.39jonpryi think we need to implement a texture allocator. and seriously need more gpu1
17:00.09arrrghhhmore cowbell?
17:00.33jonpry?
17:00.41*** join/#htc-linux Sandvold (~Sandvold@207.80-202-111.nextgentel.com)
17:00.47arrrghhhsorry, bad joke.
17:00.54detulejonpry, wanna share these patched binaries -> these work without changes in pmem allocation?
17:01.22jonpryyeah no pmem changes. i can email you the libgles. the egl is from that link
17:01.39jonprymaybe 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.11detulesure, let's try the cm
17:04.08jonpryshould have it
17:05.39jonpryso check out this texture situation. we have 8mb - 0x2F0000 to mess with. so ~5MB
17:05.58jonprysay something wants to paint like a background image. probably 480x800
17:06.17jonpryhas to allocate a 1024x1024 texture. say its 8888. thats 4MB
17:06.22jonpryso only 1 left
17:09.35detuleok i was wondering are we at all using those ~5MB currently?
17:09.59jonpry3d apps will
17:10.54detulethis via calls in the binary that i can't see ? ugh i hate this
17:11.11Sandvold<PROTECTED>
17:11.15detuleplus the no_allocator flag is tipped on gpu1 right, so they can't use it if gralloc is allocating there
17:11.54jonpryyeah its not like that
17:12.06jonprythe whole 8MB is mmap'd into the process
17:12.39jonprythe bottom 0x2f0000 is pseudo managed by gralloc. using is own allocator implementation
17:12.58jonprythe 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.32arrrghhhSandvold, that's vague
17:15.58rpierce99arrrghhh: no it's not, he wrote and/or copied code and/or files
17:16.07arrrghhhlol
17:16.12arrrghhhthat's somehow more vague.
17:16.19rpierce99exactly
17:16.25rpierce99i answered the question as asked
17:16.29arrrghhhindeed
17:16.50Sandvold:P
17:17.21*** join/#htc-linux WisTilt2 (~wisgreg@wireless251.wirelesstcp.net)
17:17.45rpierce99there's the man, the myth, the legend
17:17.49Sandvoldokey: for the adreno200 does anyone have an idea what the ankuch guy edited to get HW acc to work
17:18.05Sandvoldand if it works at all, don't have a HD2 around to test it
17:18.07jonpryon ICS?
17:18.12arrrghhhSandvold, what is this for?
17:18.14arrrghhhif it already works...
17:18.53Sandvoldon ICS, i got desire and we don't have HW acc
17:19.15Sandvoldso if anyone knew at all what he had done, then it would be nice to get some pointers
17:19.27arrrghhhoic.  not sure there's many HD2 devs left in here.  Cotulla pops in randomly.
17:19.32arrrghhhnever heard of ankuch tho
17:21.00Sandvoldme 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.36jonpryi dunno who ankuch id
17:21.38jonpryis
17:22.21*** join/#htc-linux Alex[sp3dev] (~alexander@178.176.144.6)
17:22.23WisTilt2Morning 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.10jonprysmoke pooring out yet?
17:23.11*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs)
17:24.04Alex[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.13WisTilt2close 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.24WisTilt2Alex[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.26jonpryAlex[sp3dev], ever try larger gpu1?
17:27.33Alex[sp3dev]jonpry: nope
17:27.37*** join/#htc-linux detule (~detule@hw-ma-6l13f61.mat.jhu.edu)
17:27.41jonpryneedz moar texture
17:27.58WisTilt2jonpry, you didnt catch either of my comments to you about that i guess:(
17:28.15jonpryi did
17:28.20jonprydoesn't work
17:28.36WisTilt2yes and dont know why that is
17:28.48jonpryi'm hoping there is some kind of patch to libGLES that can be done
17:28.58WisTilt2why 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.35jonpryand winmo uses 2+13
17:29.38WisTilt2Alex[sp3dev] does kovs have 32 or 64mb smi?
17:29.51Alex[sp3dev]WisTilt2: 32
17:29.57WisTilt2ok nm then
17:30.21Alex[sp3dev]it is some first-gen msm7200A, does not overclock over 650 mhz
17:30.50WisTilt27200A not the 7201?
17:30.56WilldWisTilt2: Which libGLES do you use?
17:30.58Willd1.0 or 1.1?
17:31.09Alex[sp3dev]WisTilt2: american is 01, european is 00
17:31.12WisTilt2Willd using jonpry's right now
17:31.17jonpry1.1
17:31.37*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs)
17:31.51Willdjonpry: And you're having no problems with it in smi?
17:32.17jonprygpu0 in smi, gpu1 in ebi. does not work with gpu1 in smi2
17:32.58WilldIt didn't?
17:33.17WilldWisTilt2: I thought you got it working with gpu1 in smi?
17:33.27jonpryi guess it used to do more before i patched it
17:33.29WisTilt2smi2+8 but i have it unlocked
17:33.45WisTilt2black screen with gpu1 in smi2 base
17:33.48WilldOh
17:34.04WilldWisTilt2: Thought you got textures..
17:34.05WisTilt2that why i think there is some alignment problem
17:34.15*** join/#htc-linux leopesto (~leopesto@84.55.250.234)
17:34.28WisTilt2i did but not in ebi
17:34.48*** join/#htc-linux mgross029 (6b0a0bda@gateway/web/freenode/ip.107.10.11.218)
17:35.16jonprytextures but no smoke and flames
17:35.54Willdjonpry: Okay.
17:36.04WisTilt2Alex[sp3dev] when you were trying gpu oc were you doing it directly via the registers or what?
17:36.05jonpryafaik 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.25Alex[sp3dev]WisTilt2: via pll registers
17:36.48Alex[sp3dev]WisTilt2: i was not trying, i was overclocking. it did bring a couple fps, but not many
17:37.02arrrghhh4-5fps IIRC Alex[sp3dev]
17:37.20jonprythat would be pretty good on birds
17:37.41bzoI thought we were fpu limited on birds?
17:38.05jonpryanother 4-5fps would be like double
17:38.50bzoWisTilt2: to OC the memory, did you make any chances beside the table entries?
17:38.56bzos/chances/changes
17:38.57WisTilt2yes
17:39.06WisTilt2hang on
17:39.52WisTilt2comment out the axi_160mhz stuff that forces it to 160mhz
17:40.02WisTilt2otherwise axi stays at 160 max
17:40.19WisTilt2thats down in the fixup
17:40.29bzohmm, did that. I'm not seeing any difference in the benches when I put the axi up to 192
17:41.11WisTilt2you took out all the other IF's below this -> if (pll0_needs_fixup && t->pll == ACPU_PLL_0)
17:41.11WisTilt2SLOWER_BY(t->a11clk_src_div, 2);
17:41.55WisTilt2also changed max axi khz in board file to 200 but with those commented out it shouldnt matter
17:42.31WisTilt2in dmesg at boot, what does your adjusted table show for axi at the top rates?
17:42.47bzoI 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.31WisTilt2you're gsm right?
17:44.01bzono, rhod400
17:44.16arrrghhhanother hoodlum
17:44.35WisTilt2i 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.50WisTilt2which i know you already know, just confirming
17:45.00bzono, 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.20detuleturbo w gsm right?
17:45.26bzoyes
17:45.27WisTilt2? not from the tests i did with rpierce99 they dont
17:45.49WisTilt2i had to change the cdma table for his to get axi to change
17:46.04bzothe wrhods need the higher pll0 gsm freq because they are dual mode
17:46.26bzothat's odd, I changed the gsm table, and it is reflected in dmesg
17:46.28WisTilt2but i had a lot of other stuff commented and added so that may not be accurate
17:47.24WisTilt2what 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.33bzoI'll have to reboot
17:49.00bzoWisTilt2: 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.12WisTilt2i just want to compare it to mine.  i dont think i changed anything else though
17:49.58detulejonpry, no go w CM EGL
17:49.59WisTilt2which power logic we talking about?  not that gpio stuff that turns off panel
17:50.14bzowhat I'm running right now is the .27 version, with the init seq you just added
17:50.36bzothe .27 has rhod specific power on/off stuff
17:50.48WisTilt2vreg stuff or gpio?
17:50.56jonprydetule, no textures or just fail?
17:51.02detuleno textures
17:51.08*** join/#htc-linux kiozen (~kiozen@ppp-93-104-86-128.dynamic.mnet-online.de)
17:51.09bzoI think mainly not turning off the vreg for rhod400/500
17:51.17detulerebooting with EGL from the link
17:51.39*** join/#htc-linux Akirax (~androirc@117.Red-88-27-159.staticIP.rima-tde.net)
17:51.48WisTilt2yeah 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.28bzoseems like we need to do more digging around on the panel power for rhod400/500
17:52.42bzomaybe that is why the sleep power is so much worse than gsm
17:52.57WisTilt2aren't those also eid panels?
17:53.22WisTilt2the panel sleep registers should be the same
17:53.48detulejonpry, got it going with that EGL -> any clue where this one is from?
17:53.57bzothe .27 code has 2 vregs controlled for non-cdma rhods
17:53.58detuleit can't be just a simple patch -> bad boy is 4K larger
17:54.05bzowonder if there is some equiv we're missing for cdma
17:54.28jonprydetule, well its different lineage
17:54.44jonprythere are lots of patches to cm7 egl
17:54.51WisTilt2400/500 should be panel type 0x14 so same vregs should be for 210-500's
17:55.28WisTilt2i know the auo rhod100's were the only ones different when i was testing all this stuff last year
17:55.33bzothat'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.35jonpryi 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.18detulei am starting to develop a serious dislike for blobs
17:56.27Alex[sp3dev]detule: only starting?
17:56.28WisTilt2bzo: 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.04bzono, 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.15bzoit appears that the vreg IDs are different in those devices than gsm
17:57.21detuleneocore 20.1 identical to what i get in froyo
17:57.46bzoturning off the gsm panel vreg on cdma breaks other stuff
17:58.20WisTilt2ah, ok that rings a bell.  vreg should work if we get the right id's then for those devices
17:58.35bzowe'll have to ask [acl] when we catch him, I think he did the most digging into this
17:58.49WisTilt2so 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.04emwebzo: 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.23bzoyeah, the .39 version is a hack really, it enables the vregs but never turns them off
17:59.40WisTilt2hi emwe.  hopefully cdma doesn't use same vreg for powering data and panel:)
17:59.42emwebzo: WisTilt2: also added to more gpio toggled on panel collapse/suspend traced via haret.
17:59.59bzoWisTilt2: but then again if you're seeing good sleep power without turning off the vreg, maybe there's no point
18:00.02emweWisTilt2: well, if we toggle the once which are in there, data/radio dies immedeately.
18:00.20emwes/once/ones
18:01.02bzoemwe: so was it ever established that we should control any gpios for panel sleep?
18:01.56emwebzo: i just traced what happens in wince... the two new might be digitizer related or so.
18:02.21WisTilt2emwe does it kill only data or does the whole radio die so you cant get calls either?
18:02.34emweWisTilt2: from the looks it kills radio entirely.
18:02.47emweso x-signal-bars
18:02.56WisTilt2thats not good. no way were they stupid enough to power radio and panel off same vreg
18:02.57emwecouldn't even get it back on with airplane-toggle.
18:03.29jonprydetule, buries in here http://code.google.com/p/openeve/issues/attachmentText?id=108&aid=1080002000&name=gb-cm7-110521.patch&token=01f23178c898243d1654142146eda434
18:03.29bzoemwe: often times the vreg changes are logged in the wince dmesg
18:03.32emweAlex[sp3dev]: hey. you got a haret cheat sheet for yourself where have noted down tracing memory from pcom/dex messages by chance?
18:04.18bzoemwe: i have tried it before, you have to mmutrace the dex ring buffers
18:04.29Alex[sp3dev]emwe: i have not ever traced pcom. i disassembled all drivers and nk.exe when writing panel and camera
18:04.34detulejonpry, how about this http://code.google.com/p/openeve/issues/detail?id=106#c15
18:05.00jonpryyeah thats the same thing
18:05.13emweAlex[sp3dev]: good you got those skills :) thanks.
18:05.16jonpryits ugly though
18:05.33Alex[sp3dev]emwe: anything particular confuses you about dex?
18:05.37emwedetule: yah, i am just too lazy to assemble the cmds myself. you got haret commands at hand by chance?
18:05.56emweAlex[sp3dev]: nah, wan't to see what pcom calls regarding vreg setup are issued.
18:06.10jonprythe 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.10emweAlex[sp3dev]: assuming it's the same as we do. (controlling them via dex)
18:06.49bzoWisTilt2: http://pastebin.com/MA06xc6M
18:07.42Alex[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.47WisTilt2bzo: that looks correct. you dont see any change in memory speed going from stock to this setting?
18:09.16emweAlex[sp3dev]: disptools.dll is the right starting point?
18:09.21WisTilt2what freq is your PLL2 at after fixup?
18:09.26WisTilt2should be 768mhz
18:09.36bzoemwe: was a long time ago, don't remember really but I think it involved mmutracing the addresses around +0xfc100
18:09.58emwegiving it a go later. thanks guys.
18:10.00bzoWisTilt2: yes to both
18:10.16detuleok 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.43WisTilt2bzo: this is mine currently running at 614400 and memory is far higher than without it -> http://pastebin.com/04cdUF0W
18:11.09bzowhat are you using to bench?
18:11.11Alex[sp3dev]emwe: yep
18:11.19WisTilt2quadrant that does all the tests
18:11.43WisTilt2not 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.06bzoI'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.20WisTilt2whats your total score?
18:12.37detulei think those IO operations seriously affect the quadrant score
18:12.40bzo513 I think?
18:12.46detulelike my ext4 score is in the 200s
18:12.57detulebecause somehow it hates those IO operations
18:13.00WisTilt2at 672mhz oc my best was 454 i think it was
18:13.06WisTilt2545
18:13.23WisTilt2let me run it at 614400, i dont remember
18:13.36bzoI think that's what you said yesterday
18:14.01bzoI should try down clocking to 614400, maybe there's some weird multiplier stuff going on as related to the axi?
18:14.13WisTilt2let me run this and curious what differences your memory score is from mine
18:14.46WisTilt2thats 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.29WisTilt2ok at 614400 total is 501, memory is at 246
18:15.31detulealso do you both have jit enabled/disabled? perhaps that too is affecting some of the quadrant scores
18:15.40WisTilt2i have jit disabled
18:15.43bzosame
18:15.44WisTilt2jit:fast
18:15.47[acl]emwe: yo
18:15.52jonpryhi [acl]
18:15.56[acl]sup bretheren
18:16.03rpierce99i thought it was int:fast
18:16.15emwe[acl]: yo. supper time. ttyl. sry.
18:16.16jonpry[acl], how can we get more gpu1?
18:16.18WisTilt2yeah whatever it is but :fast is what i have
18:16.32[acl]emwe: damn.. ok let me know when ur back
18:16.43jonpryi fixed 3d on gb for ya
18:16.55bzoWisTilt2: that 614400 tes is with axi=192?
18:16.59[acl]jonpry: great now help me figure this out.
18:17.02WisTilt2[acl] thanks for saving me the trouble finding that gsm gpio for prox
18:17.10WisTilt2bzo: yes
18:17.14[acl]jonpry: on haret kernel the damn vregs for gsm dont match my findings
18:17.14jonpryhrm
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.12WisTilt2if everyone would just get rhod300's we wouldn't have all this trouble:)
18:18.17jonprycan'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.17WisTilt2rhod100=paperweight
18:19.19jonpryit's been awhile since i downloaded one. but iirc enerygyrom did not specify a rhod version
18:19.28[acl]interesting
18:19.36arrrghhhlol
18:19.46arrrghhh[acl], AFAIK all CDMA RHOD's can use the same ROM's
18:19.51arrrghhhand all GSM RHOD's can use the same ROM's
18:19.55[acl]arrrghhh: thanks
18:19.57arrrghhhjust can't mix GSM/CDMA, obviously.
18:19.58arrrghhhnp
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.35jonpryinteresting
18:20.45emwe[acl]: man, i need to prep supper. you got good luck with RHODW vregs? need to look what you got...
18:21.18bzo[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.35emweyou 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.05emwe[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.31emwe[acl]: look at .35. added the two gpio. figured via haret. not sure we need more vregs.
18:22.37emweah. hm.
18:22.42emweso 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.17emweok, cool thing then :)
18:23.27emweso, now supperina time.
18:23.54detulejonpry, how is this return NULL not breaking other calls that request extension pointers
18:24.37jonpryextension 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.04jonpryso it does stupid things like detects an extension in pixelflinger. then tries to use it w/ hardware renderer on
18:25.06WisTilt2bzo: .39 does disable vreg in mddi_panel_blank
18:25.30[acl]WisTilt2: what vregs are you disabling ?
18:25.49WisTilt2gp2 and gp4
18:26.10WisTilt2that all came from .27 i believe
18:26.11jonprydetule, 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.54WisTilt2ok let me check that out.  so those should be good on all rhods then?
18:27.01[acl]no, not cdma
18:27.02jonpryall 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.38detulerhod400
18:27.42WisTilt211/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.23detule[acl], ok i thought you were asking for me to test it out
18:28.25WisTilt2k. 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.25detulei 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.36WisTilt2bzo: 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.08bzoWisTilt2: .27 panel code + your added seq for .39
18:30.22bzoit's pretty much the same except for variant detection and vreg
18:30.27WisTilt2so you have the vreg disable commented out in blank?
18:30.42WisTilt2or in a variant
18:31.02bzoyes, for rhod400/500 vreg is not touched
18:31.55WisTilt2ok 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.21WisTilt2no point in me coding variant if you already did it:)
18:32.34bzook
18:32.42bzohmm, you're right vreg is getting disabled
18:32.53bzowonder why it's not killing the radio for wcdma?
18:32.54WisTilt2in panel blank right?
18:33.07*** part/#htc-linux Alex[sp3dev] (~alexander@178.176.144.6)
18:33.20bzoyes
18:34.46detulejonpry, so these pixelflinger extensions that are not in the blob can we stub those out
18:35.53rpierce99your 2nd favorite tablet is rooted jonpry
18:37.02*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs)
18:38.28bzoWisTilt2: pushed
18:39.45WisTilt2k. this makes no sense. acl said vreg should be 11/13 but those are currently rftx and rfrx2
18:40.09bzoignore 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.44WisTilt2ok
18:41.11bzoreally, we should either define a machine specific set, or just go to using the raw ids
18:41.37WisTilt2agreed.  we need some organizing
18:44.02*** join/#htc-linux rajkosto (~rajkosto@cable-94-189-244-139.dynamic.sbb.rs)
18:44.31WisTilt2bzo: 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.10bzoWisTilt2: get quadrant of 464 with 614/192
18:48.24bzoso it doesn't seem like the mem speed is getting changed for me
18:48.48WisTilt2what memory score did you get, or does your's show that at the bottom
18:49.01bzodoesn'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.08bzoWisTilt2: can you git diff your acpuclock to double check none of your old mem OC code is still there?
18:51.43bzobecause arrrghhh was seeing the results of the mem OC in your built kernel right?
18:52.06WisTilt2i 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.26WisTilt2building 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.15detulei found a very effective task killer kills PIDs that my task killer widget can't get
18:54.47detuleit'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.31WisTilt2bzo: 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.55bzothat is a mystery
19:02.56WisTilt2arrrghhh ping ping
19:03.47WisTilt2only other thing i have done is i have fb running in smi1, which could be that difference.
19:05.46bzocould 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.03WisTilt2bzo: so run that again and we'll compare the individual numbers
19:10.36WisTilt2bzo: just to make sure we're talking the right IF's, lines 744-749 commented out in acpuclock
19:11.42bzoI 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.38bzohmm, got a 521/246 with this quadrant
19:13.27WisTilt2memory is 246? mine is 248 so we're right on
19:13.38WisTilt2did you move fb?
19:13.48*** join/#htc-linux gnutoo_ (~GNUtoo@host40-58-dynamic.116-80-r.retail.telecomitalia.it)
19:13.52bzono, I guess you get a better score with the paid version lol
19:14.40WisTilt2well now you can change axi and see if memory changes
19:15.10bzoI'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.23bzoWisTilt2: 508/248 with 614mhz/default mem
19:27.50WisTilt2hmm, what axi value did it use in default?
19:27.56bzo160
19:28.10WisTilt2is ahb 153600
19:28.16bzoyes
19:28.49WisTilt2ok let me run mine default and see.
19:32.13*** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com)
19:40.59WisTilt2bzo: 494/208 with 614/default here.  which table are you changing axi in?
19:41.33bzoI reset acpuclock to git default
19:41.52WisTilt2yeah but when you up axi where are you changing that to 192?
19:42.45bzowhere the comment starts 7x01/7x25 turbo with GSM capable modem
19:44.00WisTilt2ok, 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.26bzono, because it prints out the table I changed in dmesg
19:44.53WisTilt2run benchmark on memory only and see what you get
19:45.23WisTilt2i 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.07bzohmm, around 200
19:50.06WisTilt2im booting with axi 192 again and going to run memory only.  maybe something is skewed when you run full test.
19:50.22WisTilt2should go from 208 up to 248+
19:50.36bzoI ran the full test again and got 528/253
19:50.49bzomaybe just running the mem test doesn't ramp up the cpu all the way?
19:51.28WisTilt2well if you run memory test only it should still be relative with the increase
19:52.02WisTilt2but you are probably right, cpu scaling may be causing the fluctuations
19:52.06bzoif I run cpu+mem, I get 254 mem
19:53.16WisTilt2i 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.16WisTilt2bzo: weird lol. cpu+mem gave me mem=250
19:55.35WisTilt2thats only 2 above running by itself though
19:55.35bzofor 614/160?
19:55.40WisTilt2614/192
19:55.48WisTilt2i didnt try cpu+mem @ 160
19:56.12WisTilt2cpu is 1105
19:56.20bzoisn't that what you got before for 192?
19:56.36WisTilt2no, 160 i got 208-210
19:57.12bzoI'm confused, I asked 614/160 and u said 614/192?
19:58.25WisTilt2lol. 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.49WisTilt2only 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.10bzoso what was weird about "cpu+mem gave me mem=250"?
20:00.00WisTilt2dont 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.19bzook
20:01.05WisTilt2let 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.02WisTilt2btw, 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.36bzohmm, wonder if it is worth it then?
20:03.57bzoIt sounds like one of the gpios emwe traced may be to power off the touchscreen
20:04.02bzomaybe that will be more power savings
20:04.15WisTilt21ma 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.40emweyeah, the gpio are just cosmetics...
20:04.56emweso abel said vreg 11 and 13?
20:05.02WisTilt2yes
20:05.10WisTilt2they are working on the 300 at least
20:06.05emwehm, we were toggling wince idx 3 and 4 on non-RHODW. hm :)
20:06.20WisTilt2i 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.25bzoemwe: you don't think the gpio is useful?
20:06.46emwewell, it has a 2ma consumption. yes, might be useful. but not *the* power saver.
20:06.58emwedon't hurt for me.
20:07.22emweno issues since yesterday.
20:08.01emwewhonder what happens if i try 11/13 instead 3/4 ...
20:08.56WisTilt2emwe what device is that?
20:09.05emweRHOD400 on GSM here
20:09.18WisTilt2might be a good test
20:09.38emweso perhaps we are identical in that respect. who knows...
20:09.53emwebtw, pulled your vsync patch. missed that as well from .27
20:10.19WisTilt2yeah 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.10emweah right, yeah. i got the 100 as well.
20:11.12bikererwoaah, 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.59bikerertho thankfully less broken then huawis
20:15.51detulerpierce99, what's the verdict
20:15.55*** join/#htc-linux rajkosto (~rajkosto@2001:470:d76b:da7a:d0a6:5870:cab8:4a50)
20:16.10rpierce99oh damn, lol i haven't tested it, i'll do that now
20:16.29arrrghhhbikerer, none of us are working on/with .32...
20:17.38bikererarrrghhh, kk
20:23.58rpierce99detule: still broken for me
20:25.48*** join/#htc-linux helicopter88 (~helicopte@host128-84-dynamic.37-79-r.retail.telecomitalia.it)
20:25.55detulerpierce99, i got one more http://dl.dropbox.com/u/38520332/3.0/30ker_mod_11-29%232.tar.gz
20:30.15detuleit's the first time i've been able to run a full logcat, also push pull works over here as well
20:33.32rpierce99the first one worked for you?
20:33.54detulethe first one worked one worked sporadically
20:34.00rpierce99this one is working
20:34.09rpierce99hasn'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.40detulealright hasn't blow up?
20:40.53rpierce99nope still going strong
20:41.11detulegreat should make swapping kernels an easier affair
20:41.31rpierce99yes, if we can get this patch into all of the other .3x and 3.x trees
20:41.36rpierce99what was wrong?
20:42.34detulewell 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.09detulethe second kernel -> enabled dualspeed for the the gadget driver which apparently adds support for dual-speed controllers
20:44.41rpierce99so the mac is a dualspeed controller and and it wasn't getting enough power
20:45.10rpierce99nice work
20:46.19WisTilt2bzo: 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.05rpierce99attempting my first kexec, wish me luck :)
20:48.29detuleyou'll be in love
20:49.37emwebzo: do we yet support setting EBI1_CLK at all in clock-wince? whonder if that axi frequency playing has an effect.
20:51.12arrrghhhi've had kexec hang a few times
20:51.17arrrghhhbut when it does work, 'tis awesome.
20:51.59rpierce99yeah it looks like it hung and the android_usb gadget high speed config #1
20:52.08rpierce99s/and/at/
20:53.39rpierce99it 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.02detuleWisTilt2, 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.49WisTilt2detule: guess you're talking about my autobuild, i can do that after i get these clock changes integrated:)
21:19.28detulesure thing, thanks for taking care of the autobuild, makes life easy
21:19.48WisTilt2[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.32WisTilt2panel 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.11WisTilt2we 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.37WisTilt2[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.35WisTilt2unless 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.35emwejust wanted to keep for "ideas" :)
21:38.49emweyou tried vreg 11/13 already?
21:38.56emweon your RHOD400 i mean...
21:39.10[acl]on the 400? nope. It doesnt need it as bad as gsm
21:39.10emwei can blank/unblank fine...
21:39.21emwei'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.34emweok, yeah, but power drain wise?
21:39.41emwei am at 40%@7hours
21:39.46emweovernight
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.43emweidle + googlesync + k9 only
21:42.15emweduring the day i am plugged mostly. listening to music at work. but i am only watching overnight "stats" so to say.
21:42.37emwehm, 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.16emweok.
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.39emwels is in there for quite a while
21:46.45[acl]i did not know
21:46.46emwejust updated your value array
21:46.57[acl]well thank you
21:46.58[acl]lol
21:47.21emweand i got a bosch official bma150 driver in :P
21:47.40[acl]ahh i had to back port mine
21:47.42emwehad to adjust userland to support it, though.
21:48.06emweso we can still use the other kernels and be good.
21:48.34emwefound 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.55emweofc it does
21:50.03emwebut yeah, it is 200ms what userland wants. so...
21:50.11emweeven 100ms in gallery3d iirc
21:50.31[acl]hmm cool
21:50.33emwelet's say it's working fine.
21:50.53emwelook at the board power hooks for it. a bit sluggish what i did...
21:51.14emwebma150 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.29emwedidn't compare them. just saw bma150-microp.c was a no-go.
21:55.39emweand 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.30emwesee ^^
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.28emweyap.
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.16emwewe are using our own anyway.
21:58.26[acl]own way ?
21:58.40emweits a AkmSensor fork.
21:58.48emwepuh... already wrote this once today..
21:59.06[acl]interesting
21:59.07emweit's been put together to find the akm or the bma sensor
21:59.15emwenot just one thing.
21:59.18[acl]oo ic
21:59.26emweand i added some differentiation for old or new bma driver
22:00.08emweit'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.55emweregarind nand? yeah.
22:07.12emweit'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.21WisTilt2either 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.02WisTilt2are some not used from that table and setup elsewhere?
22:09.03emweas in not setting all clocks?
22:09.13WisTilt2like adsp_clk for example
22:09.27[acl]WisTilt2: adsp is done by a9 so should be left alone
22:09.41WisTilt2we'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.33WisTilt2k.  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.56WisTilt2so 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.26emwe[acl]: save you the trouble, do make menuconfig and copy .config over to arch/arm/configs/htc_msm_android_defconfig
22:16.40emweand 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.05emwenah, it should be good
22:19.14emwei'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.39emwei 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.05emweit *is* identical.
22:22.15[acl]oo
22:22.44emwei 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.31emwelaters log reader ;)
22:24.39arrrghhhheh
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.10WisTilt2arrrghhh: without any oc'ing whats the best fps you get in neocore when textures are working?
23:38.23arrrghhhthat's a good question
23:38.32arrrghhhi've seen everything from 15-18fps...
23:38.37arrrghhhi don't think i've seen more than 18 w/o OC tho.
23:38.55WisTilt2how much more do you get when oc'd and how much ocing?
23:39.30WisTilt2just a ballpark
23:40.16d3tul3WisTilt2, 3.0 stock scores ~20.5 for me in neocore
23:40.27d3tul3what do you have it up to?
23:40.34arrrghhhmaybe 2-4 FPS more WisTilt2
23:40.34WisTilt2that with textures?
23:40.40arrrghhhi don't think i've seen over 20fps on RHOD tho
23:40.44d3tul3yes with textures
23:40.54WisTilt2you both have 400's
23:41.05WisTilt2i know you do arrrghhh
23:41.08d3tul3yes
23:41.19arrrghhhindeedy
23:41.29d3tul3this with jonpry's patched _qcom blob and the egl blob from that thread
23:42.15WisTilt2well 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.26arrrghhhdamn
23:42.27WisTilt2no one ever changed the divider for it
23:42.42arrrghhhll
23:42.46rpierce99lol
23:42.47arrrghhhs/ll/lol/
23:43.03WisTilt2so you get better fps with oc when pll0 goes up but thats it, not much
23:43.22rpierce99when you put up the test kernel for this can you include d3tul3's patch to usb? :)
23:43.38WisTilt2im 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.53rpierce99you would think
23:44.01WisTilt2usb patch? what'd he fix
23:44.06rpierce99mac adb
23:44.10WisTilt2cool, what was it
23:44.21d3tul3er I can commit it in the .39 tree
23:44.47rpierce99detule: 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.47rpierce99[2:44pm] detule: the second kernel -> enabled dualspeed for the the gadget driver which apparently adds support for dual-speed controllers
23:44.50d3tul3if you give me an hour or two i need to find a better way to say yes to one defconfig
23:45.15WisTilt2ah, good find
23:45.49rpierce99sorry didn't mean to derail
23:45.56rpierce99continue fixing our gpu
23:47.02d3tul3i was under the impression gpu, along with most other things run off of PLL1
23:47.49WisTilt2me 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.56d3tul3yeah but 960/4 (is PLL1 960?) makes for a saner value than 49mhz
23:49.01WisTilt2i 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.46WisTilt2when does pll1 actually get to 960? 480 is the highest since its /2 in that rate
23:50.12WisTilt2gpu runs off the adjusted table pll
23:50.53dr1337hey what's the difference between msm7627 and qsd8k?
23:51.12dr1337according to wiki they are essentially the same
23:51.25*** join/#htc-linux TheXev (user@54.sub-75-214-32.myvzw.com)
23:51.30d3tul3brb
23:52.35*** join/#htc-linux d3tul3 (~oliver@pool-96-234-141-27.bltmmd.east.verizon.net)
23:52.54WisTilt2arrrghhh or rpierce99 can you dl this kernel and grep dmesg for GPU MASK: value
23:53.03d3tul3WisTilt2, i am just looking at the PLL dump at bootup which also lists PLL0 for my CDMA device at 245mhz
23:53.07arrrghhhi can in ~30mins or so
23:53.21rpierce99will be too late
23:54.11*** join/#htc-linux jonpry (~jon@unaffiliated/jonpry)
23:54.48d3tul3this 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.13WisTilt2cdma devices should be on 196mhz i thought
23:57.59d3tul3PLL3 is 196, that might be different on gsm
23:58.30WisTilt2d3tul3 check your adjusted table and see what rates you have that are derived off those pll's
23:58.53d3tul3alright what's a good way to check that adj table
23:59.13WisTilt2its the one either above or below what you pasted
23:59.22*** join/#htc-linux Bry8Star (~Bry8Star@gateway/tor-sasl/bry8star)
23:59.32WisTilt2right above it

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.