IRC log for #htc-linux on 20090116

00:01.14cr2android.git.kernel.org
00:02.41*** join/#htc-linux bashir (n=chatzill@cpc1-blac6-0-0-cust618.manc.cable.ntl.com)
00:03.49*** part/#htc-linux bashir (n=chatzill@cpc1-blac6-0-0-cust618.manc.cable.ntl.com)
00:05.05lupine_85hmm, well <=> gpsd works
00:05.39lupine_85and the LED is glowing
00:05.49lupine_85the lights around the navi circle keyboard
00:05.55lupine_85button*#
00:08.33*** join/#htc-linux exco (n=exco@e181093134.adsl.alicedsl.de)
00:09.08lupine_85?frameworkd-devel? is doing some odd stuff
00:09.29*** join/#htc-linux gh0ul (n=asds@host81-154-247-76.range81-154.btcentralplus.com)
00:11.49*** part/#htc-linux exco (n=exco@e181093134.adsl.alicedsl.de)
00:17.08Untouchab1eGood night all
00:17.10Untouchab1egood luck :D
00:28.11*** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net)
00:29.08lupine_85humm. 'ARM9 has CRASHED'
00:29.24lupine_85smem: DIAG ''
00:29.31lupine_85(very helpful :D)
00:37.27dream_kill:P
00:39.31*** join/#htc-linux reformatt (n=chatzill@71-37-165-208.bois.qwest.net)
00:39.33lupine_85that was caused, I think, by init'ing the GPS then booting into linux
00:39.44lupine_85(I ran google maps then haret)
00:40.39*** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz)
00:44.37lupine_85wonders if he should use phoneme or gpephone
00:48.05maejreplupine_85: the LEDs glowing happens if you're charging it when you boot into linux
00:48.33lupine_85fair enough
00:48.38maejrepthe LED state continues when you boot out of windows, and since the "breathe" effect is controlled by the chip, it keeps doing it
00:48.48lupine_85not sure how it managed to screw up my calibration though
00:49.09maejrepand i think i read somewhere else that NetRipper had the same issue of it crashing when you boot with gps initialized
00:49.44lupine_85I'll try the gpsd further tomorrow, when I'm not surrounded by bricks :D
00:51.10maejreplupine_85: want my kbd module?
00:51.28maejrepor wait for me to clean it up? :p
00:51.50lupine_85I'll let you clean it up :)
00:56.05*** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey)
00:56.25lupine_85builds himself a GPE image too
00:57.52BHSPitLappydraws an image of GPE
00:57.56maejrepyou have raph100 right?
00:59.00maejrepcr2: yeah in SPL, I see "MicroP-Raph (LED) v0C85" and "MicroP-Raph (KEY) v0685"
00:59.08maejrepso looks like the version ids are correct
00:59.28maejrepalso see "PSOC-Raph STAGE_EVT v20" but I don't know what that means :)
01:00.30lupine_85maejrep: yep
01:01.14*** join/#htc-linux TeringTu1y (n=maarten@195-241-125-243.ip.telfort.nl)
01:01.30maejreplupine_85: if you get a chance can you boot into SPL and tell me what those versions show for you ^
01:02.00maejrephold power+vol_dn and soft-reset, holding those 2 keys until you get to the tri-color SPL screen
01:02.35lupine_85MicroP-Raph v5
01:02.47maejrepthat's it?
01:02.48lupine_85erm
01:02.51maejrepdoesn't show LED or KEY ?
01:03.10lupine_85MicroP-Raph(LED) v13 \n MicroP-Raph(KEY) v5
01:03.28maejrepyikes
01:03.37lupine_85and I have a PSOC-Raph STAGE_CVT v0x36
01:03.54maejrepvery different ;x
01:04.07*** part/#htc-linux NexVision (n=nunya@97.66.39.252)
01:04.08maejrepits not even 0005 ?
01:04.10maejrepjust v5 ?
01:04.13lupine_85v5
01:04.16maejrephmm
01:04.30maejrepguess we'll have to see what the id comes back as in the driver
01:04.55lupine_85it's possible the SPL version-reading is bugged too ;)
01:05.07maejrepi guess
01:07.26lupine_85so long as the versions are unique, and both sides agree on which version is which, I guess you can't really call them 'wrong' ;)
01:08.19cr2lupine_85: raph100 ?
01:11.02cr2maejrep: reflashing the psoc and microp may be fun. i think they use master mode.
01:11.11lupine_85cr2: yes
01:11.44cr2lupine_85: the numbers look good for me
01:13.07maejrepso 0685 and 0c85 are just what raph800 has i guess ;o
01:13.18cr2maejrep: destroyed the lcd already?
01:13.21cr2yes
01:13.28maejrepdoh not yet
01:13.34maejrepwas cleaning up kbd
01:13.43cr285 is for 800 , and 5 is for 100
01:14.30cr2i've looked at the tiacx driver
01:14.38maejrepso whats the 06?
01:15.00cr2the ugliness i
01:15.18cr2s unbelievable
01:15.27cr206 is the fw revision
01:16.14cr2but it should be relatively easy to adapt it to raph
01:16.30cr2i think only the wifi irq number is hardcoded
01:16.54lupine_85nice
01:16.56cr2and 3 trout_foobar() function names are needed
01:18.54cr2don't know about the bt
01:19.42cr2h2w looks interesting
01:20.46cr2maejrep: can we move to 2.6.27 ?
01:20.56maejrepthat'd be nice :p
01:21.09tmztcr2: you mean they boot in master and expect firmware to available?
01:22.28tmzt20:20 < lupine_85> humm. 'ARM9 has CRASHED'
01:22.28tmzt20:21 < lupine_85> smem: DIAG ''
01:22.28tmzt20:21 < lupine_85> (very helpful :D)
01:22.32tmztDIAG?
01:23.19tmztcr2: even g1 is not moved to 2.6.27 yet it appears, the cupcake build will try to build it or use existing image
01:23.22tmztbut it doesn't work
01:23.30cr2tmzt: something like that
01:23.42cr2ok
01:23.45tmztthere is a patch for the ril though, not in ril but in telephony, it ignores a command the htc ril won't support
01:23.55tmztnoone wants to try dzo ril on g1/adp1 I can find
01:24.15maejrepwhy not? sounds fun :D
01:24.21tmzthttp://review.source.android.com/7699 #wifi fw loader
01:24.34tmzthttp://review.source.android.com/7674 # ril
01:25.21tmztI'm working on a protocol for testing cupcake on g1 using sd card, but it's theoretical for me
01:25.24cr2tmzt: doesn't work == kernel does no boot ?
01:25.30tmztdon't know
01:26.05tmztdon't think that's it
01:26.17tmztalso, it appears it expects a new amss but no clear information on that
01:26.32cr2ok
01:26.37cr2good night
01:26.38tmztI think it's only at command differences not smd layout
01:26.43*** join/#htc-linux zycho_ (n=zycho@a89-183-78-110.net-htp.de)
01:29.41*** join/#htc-linux reformatt (n=chatzill@71-37-165-208.bois.qwest.net)
01:30.16reformattquick question how does the msmts_calib string work in default.txt. What settings from my calib screen need to be there? Im trying to get the correct settings for DIAM500
01:31.15tmztit should be in dmesg somewhere, otherwise look at the source (sorry)
01:32.37reformattthat is ok. Have maxx-miny and minx-maxy strings and can't figure out what order they go in. :P
01:33.26tmztwhat kernel do you use on diam500?
01:33.45tmztthat is on verizon, right?
01:34.02reformattim using the latest one that Untouchable uploaded
01:34.10reformattno its for the sprint model
01:34.27reformattmsm_ts: maxx=03a3 miny 03ba, msm_ts: maxx=03a3 miny 03ba
01:34.30tmztit says diam500 under battery? what is the cpu in ce settings?
01:34.35tmztsystem info
01:35.03reformatt7501a
01:35.59reformattit does say DIAM500 under battery
01:36.01tmztit has built-in sd card?
01:36.15reformattyes built in sd card back of the phone has a red cover
01:36.27reformattnot sure what version the verizon model is
01:36.40dream_killhi
01:36.50tmztit seems strange they would have raph500 but not diam500
01:36.50dream_killgot a raph100 too
01:36.58tmztanyway, now I need an iDEN one
01:36.58dream_killu need any info from it?
01:37.13tmztdon't think so
01:37.24dream_killk
01:37.42tmztraph100 is pretty well taken care of I think
01:38.03tmztmaejrep: close to a patch? been away a few hours mostly
01:38.21maejrepyup, just cleaning up the code so it doesn't look so bad ;p
01:38.42tmztare you going to commit on the NetRipper stuff from yesterday?
01:39.07maejrepdamn, forgot to pull those changes
01:39.12maejrepbut I don't have commit access anyway
01:39.18tmztthat's what git is for
01:39.27tmztwell ok, I mean patch against those
01:39.54maejrepyes I'll do it from latest head
01:43.33reformatttmzt: yes its crazy that the models would not match up between the touchpro and diamond. Verizon hasn't even released the diamond yet. :P
01:44.04tmztI think they might make it an HD but that's just a guess
01:53.47*** join/#htc-linux xianthax (n=xianthax@c-75-69-145-210.hsd1.ma.comcast.net)
01:54.02*** join/#htc-linux dzo (n=dzo@121.98.128.127)
02:11.37maejreptmzt, NetRipper, cr2, lupine_85: http://www.privatepaste.com/e11uUWKu8G
02:14.06*** join/#htc-linux dzo (n=dzo@121.98.128.127)
02:16.28maejrepworks still :D
02:16.38maejrep(didn't test it after my cleanup ;x until now)
02:17.37tmzt+static struct micropkbd_platform_data raphael_kbd_data
02:17.38tmztraph800?
02:18.19maejrepyes
02:18.33maejrepwhich is not going to work for raph100 or 110
02:18.58maejrep[   44.849734] MicroP Kbd: Clamshell status: 4294967295  <-- that's "-1", but why?  Shouldn't gpio_get_value() return 0 or 1?
02:19.52tmztI think so, what does the android driver do?
02:20.11tmztI mean how does it check that gpio?
02:21.32maejrephmm
02:21.33maejrepstatic struct gpio_event_input_info trout_keypad_switch_info = {
02:21.33maejrep<PROTECTED>
02:21.33maejrep<PROTECTED>
02:21.33maejrep<PROTECTED>
02:21.34maejrep<PROTECTED>
02:21.40maejrepguess it lets gpio_event_input handle it
02:21.46maejrepprobably a good idea to do it that way :)
02:22.18tmztit has to be on the same device for android though?
02:22.31maejrepmeaning what?
02:23.02tmzttry !!gpio_get_value(
02:23.15tmzt/dev/input/event1 I think
02:24.40maejrepI think trout's keypad driver registers 3 individual inputs
02:24.47maejrepstatic struct gpio_event_info *trout_keypad_info[] = {
02:24.47maejrep<PROTECTED>
02:24.47maejrep<PROTECTED>
02:24.47maejrep<PROTECTED>
02:25.06maejrepand the switch is the clamshell slider
02:25.10tmztdoes trout driver send a value with EV_SW, or is that just used as a toggle for surfaceflinger
02:26.14maejrepit doesn't do anything with it here .. my guess is it just catches SW_LID and does something with it in userland (ie, turn off the keyboard when shut)
02:26.35maejrepprobably a good way of handling it ;o
02:28.28maejrepNetRipper: ignore those last 3 changes in board-htcraphael.c :x  those are the gpios I use
02:36.01maejrepcr2:
02:36.03maejrep000f3fc0  00 00 00 00 01 00 00 00  dd 00 dd 00 da 00 da 00  |................|
02:36.03maejrep000f3fd0  00 00 00 00 00 00 00 00  d3 03 d3 03 ec 00 ec 00  |................|
02:37.08maejrepaccording to vogue-smd.c, the AT head & tail are "dd00" and "da00", and the SMD1 head and tail are d303 and ec00
02:37.31maejrepand I don't think there's anything identifying around it that can tell us where to find it
02:38.53tmztwhat do you mean by the last part?
02:40.52*** join/#htc-linux woodyPL (i=woody@gateway/shell/blinkenshell.org/x-c986e936b688ba54)
02:42.59maejrephe mentioned earlier that we should be able to scan some part of smem to find f3fc8 and f3fcc ^ above in order to get information about the rx/tx buffers
02:43.15maejrepbut I don't think that would be an easy task
02:48.14maejrepcr2: haretlog-20090111_183605.log:004267: mem TRACES(0) 9c0fc100=0000001a (0000001a) @~f000fe50
02:48.17maejrepso I did see 0x1a
02:51.45*** join/#htc-linux woodyPL_ (i=woody@gateway/shell/blinkenshell.org/x-375c3ceac7795fbf)
02:58.14maejrepcr2: also, I really don't think the in/out thing is right :x  in my trace, the 0x1a command does set both DATA1 and DATA2
02:59.27maejrepsee: http://www.privatepaste.com/280QKem6zo
03:00.04maejreplooks like it sets 0x400000 level to 0xb22, and 0x4000 level to 0xa28
03:01.27*** join/#htc-linux t3chi3 (n=blarg@ip24-250-216-85.ga.at.cox.net)
03:08.05maejreparch/arm/mach-msm/proc_comm.c:91:4: warning: #warning WinCE compatible AMSS version selected. Default proc_comm implementation is disabled and stubbed to return -EIO. <-- I think -ENOTSUPP would be more appropriate :)
03:12.52maejrephmm, can't remember what I did to get EXPORT_SYMBOL to work ...  cause its certainly not working now :(
03:14.38tmztfrom where to where?
03:17.12maejreptrying to get msm_proc_comm_wince accessible from a test module
03:17.28tmztMODULE_EXPORT_GPL
03:17.56maejrepnot found anywhere :o
03:18.06maejrepits supposed to be EXPORT_SYMBOL
03:21.01*** join/#htc-linux dzo (n=dzo@121.98.128.127)
03:25.12maejrepwhatever
03:25.20maejrepi guess i'll just build it in.. was trying to not do that though
03:27.15tmztand you've declared MODULE_LICENSE gpl on your module?
03:29.31maejrephmm, possibly not
03:30.13maejrepmy only reason for wanting it is so I can know at the exact moment the code executes, instead of building it into the kernel
03:30.21maejrepbut i'll just setup a debugfs entry
03:31.34maejrepMODULE_LICENSE("GPL"); <- yes it was
03:32.05tmztnot sure then, your way could work though
03:32.11*** join/#htc-linux woodyPL_ (i=woody@gateway/shell/blinkenshell.org/x-817e4c83b8fa16db)
03:33.38tmztdzo: maejrep has a keyboard driver for raphael coming
03:34.03tmztdzo: not directly interesting for kais/vogue though
03:40.24maejrepi want to get restart working too :p
03:40.58maejreppisses me off every time I soft reset and forget to exit my ssh session ;p
03:40.58tmztI could be a bit more awake maejrep
03:41.29maejreplol
03:41.39maejrepdrink some coffee? :p
03:41.55tmztno, going to sleep soon
03:43.02*** join/#htc-linux ionstorm (n=ion@ip68-227-226-5.ph.ph.cox.net)
03:44.51*** part/#htc-linux xianthax (n=xianthax@c-75-69-145-210.hsd1.ma.comcast.net)
03:46.22maejrephe's human after all ;)
03:46.37maejrepI was beginning to think you were more insomniac than I am :p
03:47.05tmztirssi is, I'm semi
03:48.38maejrepso, my debugfs hook to make it turn the LCD off and back on...  didn't work :)
03:51.30*** join/#htc-linux woodyPL (n=woody@gateway/shell/blinkenshell.org/x-6a4d95923f0d9fe5)
03:56.35maejrepcan we register two i2c chip drivers for the same id?
03:58.03tmztwith different irq's?
03:58.28tmztah, that's a mfd
03:58.53tmztdrivers/mfd/
03:59.55maejrepi guess the most appropriate way to do this keyboard driver would be to have two chip drivers, for ce and cc, and let the keyboard/input driver interact with the chip drivers as needed?
04:00.20tmztcan you implement read function for the channels?
04:00.32maejrepand the input driver would only use cc for setting notification request (cc,50,x)
04:00.38maejrepbut also use the cc driver for setting LEDs
04:00.46tmztread(dev->client, chanid ..
04:00.58maejrepsure, i'm already partway there
04:01.27maejrepso then the chip drivers wouldn't use irqs, but the input driver would handle the interrupts and read/set data via the chip drivers
04:01.32tmztyou want to make the notification request a proper irq, there is a way to do that but it's complicated
04:01.43tmztthen you register a handler like you would any other
04:01.48maejrepmeaning what?
04:02.41maejrepwhere the chip driver sets up a "soft" irq that the input driver hooks?
04:02.48tmztyeah
04:02.49maejrepI see the IRQ as being separate from the i2c chip drivers
04:03.06tmztnot the i2c chip irq, your own irq and your own irqchip
04:03.28maejrepnot sure I'm following :x
04:04.19tmztok, drivers/mfd/twl4030-irq.c
04:05.44maejrepi don't have that file
04:06.34tmztit's in git.openezx.org ezx/mach at least
04:06.46tmztprobably upstream
04:08.26tmztin this case, isr mean interrupt status register
04:08.46tmztin your case you simple enable/disable the irq on the chip
04:08.54maejrepmy understanding is that the chip driver should just interact with that chip.  so there'd be one microp_klt chip and a microp_ksc chip.  then microp_kbd would depend on both of those, would hook the GPIO27 irq, read scancodes from ksc chip, then tell klt chip to request notifications (to reset the irq)
04:08.56maejrepwould that be wrong?
04:09.38maejrepthen the board would add both the ksc and klt chips to i2c_devices, and would call microp_kbd_init in its init function
04:09.44tmztwell, my understanding is you actually write your own i2c chip driver that only provides services to input/led/etc. drivers
04:10.04tmztyour i2c chip driver handles the 50,x commands transparently
04:10.27maejrepso then the klt chip would be mfd and would be shared between the kbd and led drivers?
04:10.34tmztyeah
04:11.22tmztthe way you propose could work also of course, I think this is the preferred way by arm upstream based on some emails on linux-arm-kernel
04:11.34tmztgetting it working would be good too
04:12.03maejrepthe strangeness with the current driver is that its added in the board file in i2c_devices using chip id 0xce for the ksc chip, but then it writes to chip 0xcc for the irq reset
04:12.46maejrepwhich means 0xcc has to be hard coded in that driver, and i wanted to avoid that
04:13.05tmztok, if you want to pass the others you could probably use resources with custom flags
04:13.27maejrepor pdata potentially
04:13.36tmztyeah
04:14.13tmztor you could code it in probe based on the id read since that cooresponds to firmware version
04:15.47maejrepyeah..  it works currently :p  but i think cr2 has higher standards for a driver ;)
04:19.46*** join/#htc-linux nextime (n=nextime@unaffiliated/nextime) [NETSPLIT VICTIM]
04:19.46*** join/#htc-linux _workkaze (n=kaze@ABordeaux-152-1-74-161.w86-196.abo.wanadoo.fr) [NETSPLIT VICTIM]
04:19.46*** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) [NETSPLIT VICTIM]
04:19.46*** join/#htc-linux ecze (n=ecze@eczema.ecze.com) [NETSPLIT VICTIM]
04:19.46*** join/#htc-linux lama (i=lama@netbsd.pl) [NETSPLIT VICTIM]
04:19.46*** join/#htc-linux defiant (n=add@p0pc0rn.eu) [NETSPLIT VICTIM]
04:19.57maejrep"MicroP-Raph (KEY) v0682."
04:19.57maejreplooks like even raph800 has different revisions
04:20.04*** join/#htc-linux ChanServ (ChanServ@services.)
04:20.04*** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda) [NETSPLIT VICTIM]
04:20.04*** join/#htc-linux Kensan (n=ken@gw.ptr-80-238-180-11.customer.ch.netstream.com)
04:20.04*** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) [NETSPLIT VICTIM]
04:20.04*** join/#htc-linux Skitzo_ (n=DCLXVI@eth582.vic.adsl.internode.on.net) [NETSPLIT VICTIM]
04:20.04*** join/#htc-linux infernix (i=nix@unaffiliated/infernix) [NETSPLIT VICTIM]
04:20.04*** mode/#htc-linux [+o ChanServ] by irc.freenode.net
04:21.48tmztthat's why I said _probe, there is no reason to hardcode something in the board pdata that isn't board dependent, in this case it's dependent on microp fw and therefore on the spl
04:21.53tmztradio.img
04:25.45*** join/#htc-linux nextime (n=nextime@unaffiliated/nextime) [NETSPLIT VICTIM]
04:25.45*** join/#htc-linux _workkaze (n=kaze@ABordeaux-152-1-74-161.w86-196.abo.wanadoo.fr) [NETSPLIT VICTIM]
04:25.46*** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) [NETSPLIT VICTIM]
04:25.46*** join/#htc-linux ecze (n=ecze@eczema.ecze.com) [NETSPLIT VICTIM]
04:25.46*** join/#htc-linux lama (i=lama@netbsd.pl) [NETSPLIT VICTIM]
04:25.46*** join/#htc-linux defiant (n=add@p0pc0rn.eu) [NETSPLIT VICTIM]
04:26.14*** join/#htc-linux ChanServ (ChanServ@services.)
04:26.15*** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda) [NETSPLIT VICTIM]
04:26.15*** join/#htc-linux Kensan (n=ken@gw.ptr-80-238-180-11.customer.ch.netstream.com)
04:26.15*** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) [NETSPLIT VICTIM]
04:26.15*** join/#htc-linux Skitzo_ (n=DCLXVI@eth582.vic.adsl.internode.on.net) [NETSPLIT VICTIM]
04:26.15*** join/#htc-linux infernix (i=nix@unaffiliated/infernix)
04:26.15*** mode/#htc-linux [+o ChanServ] by irc.freenode.net
04:30.48*** join/#htc-linux woodyPL (i=woody@gateway/shell/blinkenshell.org/x-705bf255c65a1d46)
04:39.19*** join/#htc-linux woodyPL_ (n=woody@gateway/shell/blinkenshell.org/x-8369b07878e5dcf2)
04:47.57*** join/#htc-linux nato2k (n=templarn@76.250.180.218)
05:10.54*** join/#htc-linux dzo (n=dzo@121.98.128.127)
05:48.24*** join/#htc-linux kal (n=chatzill@87-194-8-141.bethere.co.uk)
05:51.25*** join/#htc-linux dzo (n=dzo@121.98.128.127)
05:53.30*** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring)
06:20.26*** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz)
06:31.31*** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey)
06:44.53*** join/#htc-linux Balsat (n=kll@87.72.13.87)
06:45.26*** join/#htc-linux Moku (n=John@g227123024.adsl.alicedsl.de)
06:46.00*** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146)
06:46.03Untouchab1eGood morning :D
06:47.31*** join/#htc-linux yoyey (n=yoann@bro69-3-82-237-160-83.fbx.proxad.net)
06:51.51*** join/#htc-linux woodyPL (n=woody@gateway/shell/blinkenshell.org/x-88074a60c24ba5c2)
06:53.42BalsatGood morning
06:55.18*** join/#htc-linux holycow (n=bite@S01060016b6b53675.vf.shawcable.net)
06:57.26maejrepcr2: in case its useful, this is every "cc" data address I've captured in my haret logs, and the frequency of each:  http://www.privatepaste.com/9b1xKD3tuf
07:00.29maejrepand every chip address: http://www.privatepaste.com/271dq0r0VX
07:01.27*** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146)
07:01.49*** join/#htc-linux cr2 (n=cr2@ip-90-187-234-8.web.vodafone.de)
07:12.45*** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo)
07:13.47*** join/#htc-linux woodyPL_ (i=woody@gateway/shell/blinkenshell.org/x-344cc94fe8df2e7a)
07:23.13cr2maejrep: the 118 "id" is something new
07:25.57maejrepyeah i forgot what that was from, but i recall seeing it
07:26.23cr2maejrep: the *in *out is probably just a wince wrapup api. i'll check where the second parameter goes on the stack. if you see the unmodified voltage values in your trace , that's great
07:27.05cr2it seems that we are going with an amazing pace :)
07:27.08*** join/#htc-linux lpotter (n=ljp@58.173.176.153)
07:27.11maejrepi tried running the same pcom commands that I saw in the trace, and it froze my phone :p
07:27.31maejrepwas trying to turn off and on the lcd
07:27.34cr2maejrep: don't hardcode the gpio numeric numbers :)
07:27.39cr2ok
07:27.46maejrepwhich numbers?
07:27.50*** join/#htc-linux Balsat (n=kll@87.72.13.87)
07:27.52cr2in the driver
07:27.57Untouchab1eHow did the lcd-power-project go? :) Ive been sleeping for a few drivers
07:28.03cr2like gpio27, 39, and so on
07:28.07Untouchab1efew hours*
07:28.09Untouchab1e(lol)
07:28.15maejreplol
07:28.37maejrepcr2: right, i thought I didn't, am i not using client->irq ?
07:28.58cr2maejrep: i think it's a good idea to add .suspend and .resume, even if they'll be empty for now
07:29.22Untouchab1eDid anyone figure out the WiFi drivers? Since they are closed source and everything
07:29.24maejrepoh, you mean .irq = MSM_GPIO_TO_INT(27) ?
07:29.31cr2the msm_touchscreen should be a platform_device , imho
07:29.34cr2yes
07:29.56cr2it belongs to the platform_data
07:30.06maejrepnods
07:30.27cr2and 27 needs some good name
07:30.41cr2in board-raphael.h
07:30.54cr2because it does not say me anything :)
07:30.59Untouchab1elol
07:31.02maejrepthink it does something else other than keyboard?  the wiki just says irq wakeup / "Ukey"
07:31.37cr2says wince
07:31.51maejrepah
07:32.04cr2there are also Gkey, and some other *key
07:32.20cr2Qkey is/was the keyboard ?
07:32.31maejrepUkey
07:32.39maejrep1-11 / 27
07:32.46cr2ok, they used Qkey name before
07:33.24cr2hmm. if you've got vreg_level to work
07:33.35cr2i'll loook at the epson mddi
07:33.52cr2then we will have a sane lcd init. finally :)
07:33.53maejrepI was using straight msm_proc_comm_wince() calls to test, when it froze
07:34.01maejrepshould I need any delays between them or anything?
07:34.06cr2no
07:34.27cr2a may be used for something else
07:34.37cr2make wifi work :)
07:34.43maejreplol
07:34.51Untouchab1ethat would be nice :)
07:34.56cr2c and d are not used by other subsystems
07:35.00*** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz)
07:35.05maejrepc and d in proc comm?
07:35.19cr2maejrep: yes, the wince ids
07:35.26Untouchab1eI  have a question regard Haret.. When it boots Linux, does it shut down WinMo, or is WinMo technically idling in the backend? (As of such consuming system resources)
07:35.47maejrepit kills off wince for all intents and purposes
07:35.58Untouchab1eOk, sounds good :)
07:35.58maejrepkinda like how a bootloader dies off after loading an OS
07:36.05Untouchab1eAh, right!
07:36.08cr2i find it cool that androids used 1<<vreg_id as proc_comm mask for us :)
07:36.36maejreplol
07:36.38*** join/#htc-linux dzo (n=dzo@121.98.128.127)
07:37.03*** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com)
07:37.17cr2but it was not intentional i guess
07:37.28cr2ok, must leave now
07:37.31cr2bbl
07:37.32Untouchab1eaww :)
07:37.33Untouchab1esee you
07:37.40Untouchab1ehave a nice one ^^
07:37.53Untouchab1emaejrep, what is the top priority atm?
07:38.09Untouchab1eMic/sound, lcd power.. or? :)
07:38.34maejrepi think cr2 really wants to get the vreg switch and levels working, cause that will enable us to move quicker
07:38.45maejrepand actually write proper init code for some devices
07:39.11Untouchab1eyeah, understandable.. :)
07:39.28Untouchab1eIm amazed on how quickly progress has been made
07:40.05maejrepi think i saw someone say that sound should just be setup via rpc, and the modem takes care of routing audio where it needs to go (at least for phone calls)
07:40.41Untouchab1eSo audio for other purposes would be setup otherwise?
07:41.23maejrepyeah, though I couldn't tell you how :)  i've only run linux on one other phone (vogue) and didn't touch any of the code for it
07:41.31maejrepso this is kind of a learning process for me ;p
07:42.22*** join/#htc-linux pichurri (n=pichurri@users3.ilo.org)
07:42.22Untouchab1ehehe, tell me about it :) Ive been working with software development for quite a while, both asm and high-lvl programming, but I have no experience in Linux-programming
07:43.33maejrepheh I've never touched asm, but have been programming for years, done very little kernel hacking in the past, and currently a php web developer ;p
07:43.58Untouchab1ehehe, php is cool! Im mainly into .NET myself :)
07:44.23Untouchab1ebut Android has taken up alot of my spare time lately.. So I wish I could contribute more in terms of coding here, but for now Im just making sure your hard work is being hosted and supported properly
07:46.59Untouchab1eBesides, I have both the DIAM100, Raph100 and the ADP1 at hand, hehe
07:47.33*** join/#htc-linux Balsat (n=kll@87.72.13.87)
07:47.39Untouchab1egood morning Balsat
07:48.10BalsatGoor morning UT
07:48.14Balsatgood
07:48.15Untouchab1ehows things?
07:48.31Untouchab1e;)
07:49.54BalsatNot good... i got 2 hours of sleep to night, so my head is spinning... you?
07:50.31Untouchab1ehehe, got 3 hours of sleep, so Im slightly better ^^
07:51.29Untouchab1ejust so keen on getting Android working :)
07:51.59Untouchab1eas I have the DIAM100, Raph100 and the ADP1 at hand, and I love Android, dislike the ADP1 hardware, but love teh raph Hardware.. so combining the two would be amazin
07:52.01BalsatThis forum is taking a lot of my time... what to do when Android is 100% working?
07:52.11Untouchab1ehahah
07:52.40Untouchab1eAndroid will be develop constantly, so there will always be things to do
07:52.45Untouchab1eCupcake for example ^^
07:52.56BalsatCan you send SMS from from your diam100?
07:53.03Untouchab1enope
07:53.06BalsatI can't anymore... strange
07:53.19Untouchab1eyeah, with your zImage that I tried yesterday, SMS-sending wasnt possible
07:53.23Untouchab1ehavent tried it on my Raph
07:54.09BalsatI think the programmers is working on the smd0??
07:54.54Untouchab1ereally wants to get the vreg switch and levels working, as that will supposedly enable us to move quicker
07:56.10BalsatThe progress looks very nice... sorry i cant help... i only know delphi, pascal
07:57.11Untouchab1eYeah, Ive been doing a bit of ASM and alot of .NET, but never done any kernel programming
07:58.34BalsatI did som ASM long time ago, back at the Commandore 64 days.... gues thinks have change... or i hope so
07:59.20Untouchab1ehehe, the basics are probably basically the same, with variations from system to system
08:00.01BalsatWell back to work
08:00.08Untouchab1ehehe
08:00.09Untouchab1egood luck
08:00.11Untouchab1ehave a good one
08:00.21Balsatu2
08:00.25Untouchab1ethanks
08:00.36Untouchab1eMy Scandinavian neighbour
08:00.40Untouchab1e;)
08:01.44*** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net)
08:11.49*** join/#htc-linux pichurri (n=pichurri@users3.ilo.org)
08:15.50*** join/#htc-linux dzo (n=dzo@121.98.128.127)
08:34.05*** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net)
08:35.49*** join/#htc-linux woodyPL (n=woody@gateway/shell/blinkenshell.org/x-1f097ac9de48f2cd)
08:40.28*** join/#htc-linux holycow (n=bite@S01060016b6b53675.vf.shawcable.net)
08:42.36*** join/#htc-linux dzo (n=dzo@121.98.128.127)
08:51.22*** join/#htc-linux goxboxlive_ (n=goxboxli@185.84-48-126.nextgentel.com)
09:16.45Untouchab1eAnyone know of any really good or really bad software development projects?
09:37.18*** join/#htc-linux dzo_ (n=dzo@121.98.128.127)
09:45.24*** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz)
10:02.42*** join/#htc-linux amazingdander (i=bite@gateway/tor/x-98e8e4aed282e981)
10:16.06*** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146)
10:18.30*** join/#htc-linux ionstorm (n=ion@ip68-227-226-5.ph.ph.cox.net)
10:19.23*** join/#htc-linux stefan_schmidt (n=stefan@p5B035F20.dip.t-dialin.net)
10:21.26*** part/#htc-linux yoyey (n=yoann@bro69-3-82-237-160-83.fbx.proxad.net)
10:32.07lupine_85did anyone manage to get maejraep's patch to apply?
10:46.47*** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl)
11:10.01Untouchab1eWhich patch was that again? the LCD-power one?
11:12.31*** join/#htc-linux Marajin_ (n=marajin@87-194-102-189.bethere.co.uk)
11:13.13lupine_85no, the keyboard one
11:35.27*** join/#htc-linux drasar (n=maik@lamer.optinet.cz)
11:45.23marexlooks like some patch for htc himalaya landed in HH-kernel ML
11:45.59marexIm generally against merging it yet, it contains some problems (use checkpatch.pl for complete list) and contains changes that affect other devices with is no-go
11:46.17marexs/with/which/
11:48.22*** join/#htc-linux the_sys0p (n=the_sys0@cpe-67-49-210-229.bak.res.rr.com)
11:56.37*** join/#htc-linux timebomb (n=tb@p5B3E56F1.dip.t-dialin.net)
12:18.09*** join/#htc-linux PoohbaLT1 (n=Poohba@c-98-235-66-242.hsd1.nj.comcast.net)
12:34.52*** part/#htc-linux Zinbolic (n=Zy@84.238.80.215)
12:49.22*** join/#htc-linux dream_kill (n=nospam@92.56.48.66)
12:49.55*** join/#htc-linux juliusr (n=5b974d4e@lon92-8-88-165-13-120.fbx.proxad.net)
12:57.25*** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net)
12:57.32*** join/#htc-linux t3chi3 (n=blarg@ip24-250-216-85.ga.at.cox.net)
13:13.28BabelO_marex: what device the htc himalaya patch use ? is it a blueangel ? i ve not the link of the ML and did not receive the patch
13:15.57marexI guess BA, yes
13:16.07marexiirc ML archive is at handhelds.org
13:17.38BabelO_marex: ok, but i m registered on the ML and did not receive any mail :(
13:17.44BabelO_ok i look
13:23.00drasarBabelO_: That himalaya patch is created by me
13:23.48BabelO_drasar: i know yes :)
13:23.56BabelO_but what did you change in blueangel driver ?
13:24.06drasarBabelO_: but I am doing some more code clean-up right now so ignore that patch please ;)
13:24.30BabelO_drasar: ok
13:25.05drasarBabelO_: Just "Himalaya" -> "Blueangel" in some header file
13:25.16BabelO_drasar: ok
13:25.23drasarBabelO_
13:25.25BabelO_drasar: so himalaya is fully working now ?
13:26.15drasarBabelO_: I mean text in a comment in head of that file. Somebody has forgtten to change it
13:27.33BabelO_drasar: ok
13:28.15*** join/#htc-linux PoohbaLT (n=Poohba@c-98-235-66-242.hsd1.nj.comcast.net)
13:28.18drasarBabelO_: Not fully, but some of the components are working now
13:28.55drasarBabelO_: http://www.handhelds.org/hypermail/kernel-bugs/current/0236.html
13:29.32*** join/#htc-linux piusvelte (n=chatzill@nat.philau.edu)
13:29.51drasarBabelO_: Have you got commit access to hh.org CVS?
13:30.45BabelO_drasar: that is very good you update use all standard driver :)
13:31.09BabelO_drasar: no, not me, ask cr2 when you see him in the evening :)
13:32.54drasarBabelO_: yes, cr2 should be here through weekend. I have asked him already ;)
13:36.34drasarIt's a pity that kernel-bugs@handhelds.org ML seems to be dead lately
13:51.57NetRipper04:17:12 < maejrep> trying to get msm_proc_comm_wince accessible from a test module
13:52.38NetRippermaejrep[w], i removed the export_symbol as i added the method to gpio.h instead, where all the other gpio.c functions are defined as well... so you just need to include gpio.h
13:52.49NetRippermaejrep[w], uh, wait, gpio != proc_comm
13:53.15NetRippermaejrep[w], for proc comm you need to include proc_comm_wince.h then it should work already ;)
13:55.03Untouchab1eHi NetRipper!
13:55.05Untouchab1eHows things?
13:55.08NetRipperhi Untouchab1e
13:55.13NetRipperthings are fine
13:55.14NetRipper:)
13:55.32Untouchab1eglad to hear it :)
13:55.51Untouchab1ei dreamt about drivers.. lol
13:56.00NetRipperouch
13:56.02NetRipperwelcome to the horror
13:56.06Untouchab1ehaha
13:57.02NetRipperyou know the feeling, where your alarm clock goes off and you feel like you should change a flag, recompile and run it to turn it off?
13:57.13Untouchab1ehahaha
13:57.28Untouchab1eset the alarm_activate flag to 0
13:57.40NetRipperyea and you're annoyed that you cannot do it runtime
13:57.42NetRipperstupid clock
13:57.45Untouchab1elol
13:58.06maejrepNetRipper: doesn't work like that for a module -- get undefined symbol during modpost
13:58.35NetRippermaejrep, you can't include ../../../arch-arm/mach-msm/proc_comm_wince.h?
13:59.11maejrepthat's not the problem :P  I was including proc_comm_wince.h
13:59.18Untouchab1eI am curious though, are we close to another breakthrough? I know someone talked (cant remember who) about the lcd_power
13:59.35maejrepsame with gpio_set_function patch -- even including gpio.h it would not work in a module
13:59.36NetRipperUntouchab1e, i'd call keyboard a breakthrough
13:59.46maejrepfor a function to work in a module, you have to EXPORT_SYMBOL() that function
13:59.51NetRippermaejrep, ah
14:00.02maejrepbut that wasn't working for me last night for some reason
14:00.06Untouchab1eNetRipper: which keyboarD? :)
14:00.08maejrepdon't know why
14:00.13Untouchab1ekeyboard*
14:00.16NetRipperUntouchab1e, maejrep made a keyboard driver, hardware keyboard
14:00.19Untouchab1eThe Raph qwerty one?
14:00.22NetRipperyes
14:00.26Untouchab1eomg o.O
14:01.09NetRipperstill need to think about how we are going to distinguish all those different kinds of keyboard layouts
14:01.18maejrepheh yes :P
14:01.41NetRippermaejrep, did you both use export and also the include?
14:01.50*** join/#htc-linux exco (n=exco@e181083211.adsl.alicedsl.de)
14:01.59maejrepyes, still didn't work :/
14:02.05NetRipperodd
14:02.06Untouchab1eyeah.. would be awsome if we could have an easy way to configure the keyboard layout. I have the nordic qwerty keyboard version on my Raph100, and I like the keyboard layout
14:02.19maejrepso instead i just compiled into the kernel and added a debugfs hook to test it
14:02.22Untouchab1eguess we could just edit the qwerty.kcm file like I did with the ADP1
14:02.28maejrepanyway, most of our stuff probably won't be modules (?)
14:02.47NetRippermaejrep, did you update to the latest git by any chance?
14:02.51maejrepyes
14:02.59NetRippermaejrep, you must define CONFIG_MSM_AMSS_VERSION_WINCE
14:03.10maejrepyeah I did that :)
14:03.11NetRipperok
14:03.12NetRippergood
14:03.14maejrepgot the warning, etc
14:03.17NetRipperglad
14:03.18NetRipper:)
14:03.46maejrepthat module issue is beyond me :/  dunno why it was happening, but I was only trying to test proc comm without having it in an init method
14:04.17Untouchab1ebut maejrep, you said the keyboard wasnt working last night?
14:04.22NetRipperi cant think of a solution from the top of my mind either
14:04.45NetRippermaejrep, btw.. shouldnt the keymap be done in userspace instead of kernelspace?
14:04.56NetRipperi.e. that the keyboard driver only reports scancodes
14:05.06NetRipperand that userspace should convert it to the proper keys
14:07.08NetRipperor am i saying something stupid here
14:07.09NetRipper:P
14:10.26maejrepwell, the kernel has to know what keys to report (think of no X)
14:10.31maejrepkernel keycodes != X keycodes
14:10.59NetRipperalright
14:11.07NetRipperso keyboard mapping is still possible in userspace
14:11.10maejrepI don't know if I can give the input subsystem raw scancodes and let it sort it out
14:11.12NetRipperyou just define a 'default' in the kerenl
14:11.13maejrepof course
14:11.14NetRipperkernel*
14:11.25maejrepsetkeycodes <...>
14:11.32maejrepor maybe setkeycode <.. >
14:11.33NetRipperso the qwerty.kcm method is probably still usable Untouchab1e
14:11.49maejrepyeah don't know what qwerty.kcm is ;x
14:11.54NetRipperhttp://forum.xda-developers.com/showthread.php?t=458473
14:12.02NetRipperi think it's android-specific
14:12.12NetRipperUntouchab1e, do you know?
14:12.52maejrepi may be wrong about that, but was basing the code off htc-spi-kbd mostly
14:13.27NetRippermaejrep, regarding the module issue, i think the prototype may need to be specified with 'extern'
14:13.36maejrepI tried that as well ;x
14:13.51NetRipperarf
14:14.10maejrepit worked in my other module
14:14.18NetRipperso you made it extern AND export symbol? :P
14:14.22maejrepwhen I was using gpio_set_function
14:14.31maejrepyes, also tried without extern :p
14:14.35NetRipper;)
14:14.40NetRipperbut you cant use gpio either?
14:15.05maejrepi can use the generic gpio functions (which get mapped back to msm_gpio_* via the kernel gpio code)
14:15.18maejrepbut those are exported with EXPORT_SYMBOL :)
14:15.41NetRipperah
14:15.49NetRipperbut you cant call msm_*
14:15.55maejrepright
14:16.40NetRipperso i guess you're not allowed to call anything arch-specific from a module
14:16.40NetRipper;)
14:16.50NetRipperwhich seems pretty fair to me
14:17.12NetRipperbut annoying nonetheless
14:17.15maejrepwell, i was calling msm_gpio_set_function() in my test
14:17.19maejrepbecause I exported it :p
14:17.33NetRipperso export worked for that one?
14:17.36maejrepright
14:17.40maejrepthat's what baffles me :P
14:17.42NetRipperjust not for proc comm
14:18.21Untouchab1eI know a bit about the qwerty.kcm file..
14:18.35Untouchab1eh/o
14:19.00Untouchab1ehttp://forum.xda-developers.com/showthread.php?t=468703
14:19.07Untouchab1ebasically a step-by step guide on how to do it
14:19.52NetRipperok
14:20.22NetRipperbut its android-specific
14:20.28NetRipperwhich is a pain
14:20.28NetRipper:)
14:20.29maejrepanyway, it wasn't a big deal but is useful to be able to unload/load a module to test something without having to reboot, recompile, copy, start haret, etc
14:20.50NetRippermaejrep, you use scp to transfer the files?
14:20.54maejrepyeah
14:21.03NetRipperit's nice indead
14:21.08NetRipperindeed*
14:21.18Untouchab1e(sorry, packing here)... but yeah, its Android specific
14:21.22Untouchab1eunfortunately
14:21.31Untouchab1e:)
14:21.32maejrepok off to work
14:21.36Untouchab1ehehe
14:21.39NetRipperthere are linux-specific solutions but not sure if it'll work in android then ;)
14:21.43NetRipperone or the other ;)
14:21.44Untouchab1ehmm..
14:21.51NetRipperhf maejrep  ;)
14:22.06Untouchab1ehave a niec one Maejrep
14:22.34Untouchab1eIf we get the qwerty keyboard with a standard layout, thats still awesome though, considering the qwerty keyboard on the G1 doesnt haven anything else either
14:25.50lupine_85maejrep: the patch you posted last night failed to apply against head to me
14:25.53lupine_85for me*
14:29.55NetRipperUntouchab1e, there are some annoying differences among devices though.. ;) check out http://wiki.xda-developers.com/index.php?pagename=RaphaelKeyboard
14:30.59Untouchab1eaah
14:31.35Untouchab1eI guess nothing is ever easy :P
14:32.30NetRipper;)
14:33.44NetRipperwe can see the difference between CDMA and GSM but we can't detect the RAPH110 (from raph100)  and RAPH500 (from raph800) yet
14:34.04Untouchab1eahh...
14:34.34Untouchab1eNever found out about any difference between the the R100 and the R110?
14:34.36lupine_85did anyone else get it to apply? can we has it in git?
14:46.46Untouchab1eIm off for the weekend :)
14:46.53Untouchab1eHave a great weekend people :)
14:49.47NetRipperlupine_85, i'll put it in git later
14:50.00*** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring)
14:51.37NetRipperlupine_85, you can apply it using the --rejects flag, and then merge the rejects yourself
14:51.55NetRipperflag = param... git apply --rejects <file>
14:52.09lupine_85I'd rather have a clean patch ;)
14:52.19lupine_85it looks like it was truncated at the end or something?
14:52.45NetRipperoh, it probably misses an empty line
14:52.53NetRipperadd an empty line at the end of the downloaded file
14:52.55NetRippersee if it applies then
14:52.59lupine_85haha
14:53.03AstainHellbringmorning
14:53.14NetRipperi had it a while back as wel
14:53.25NetRipperpastebin trim()s it i guess
14:53.37NetRippermorning astain
14:54.08AstainHellbringwhats new NetRipper?
14:54.58lupine_85NetRipper: nah, it complains about trailing whitespace in places too
14:55.02lupine_85fatal: git-apply: bad git-diff - expected /dev/null on line 106
14:55.40NetRipperlol, that git-apply is a bit sucky
14:55.50NetRipperdo a patch -p1 < file.patch
14:55.56NetRipperwhile in the root of your kernel tree
14:56.02NetRipperthat'll complain less
14:56.44NetRippergit-apply doesn't do new files i guess.. it also doesn't include new files in diffs
14:59.25NetRipperworked for me.. wget -O microp.patch http://www.privatepaste.com/e11uUWKu8G/download && echo "" >> microp.patch && patch -p1 < microp.patch
15:00.34NetRipperi should get back to work
15:00.35NetRipperbbl
15:00.51NetRipperAstainHellbring, oh btw, keyboard is new ;) check the logs of before you joined for some info
15:01.45*** join/#htc-linux PoohbaLT (n=Poohba@c-98-235-66-242.hsd1.nj.comcast.net)
15:01.47*** join/#htc-linux addman333 (n=azachars@nat/sun/x-2d773521a22f66db)
15:01.58AstainHellbringlooks like the logs don't have anything for today yet
15:02.36lupine_85aha, got it top apply :)
15:02.45lupine_85to*
15:05.33lupine_85I have to change the scancode data for the raph100...
15:05.39lupine_85humm, how best to do it
15:06.17NetRipperi have the raph100 as well
15:06.38NetRipperi'm still thinking on what the best way is
15:06.44NetRipperperhaps we should do it in userspace
15:06.57NetRipperleave only one layout in kernel
15:07.08NetRipperastainhellbring, use http://irclog.iclem.net/?chan=htc-linux for logs, it's realtime
15:07.15NetRipperif i could only find someone to add that link to topic..
15:07.31AstainHellbringthat would be nice
15:09.15lupine_85NetRipper: well, we could assume that keycodes change depending on the MicroP version
15:09.15lupine_85(rather than model)
15:09.18lupine_85then have maps in the kernel for different microp versions
15:09.33lupine_85(well, different groups of microp versions)
15:10.10lupine_85that's how I'd do it in kernelspace. Dunno how one would do it in userpace
15:11.20NetRipperhow sure are we that each different keyboard layout can be identified with the microp version
15:12.38lupine_85raph800 has a different microp kbd version to raph100
15:12.46NetRipperok
15:12.50lupine_85but
15:12.56NetRipperwhich operator do you have lupine?
15:13.02lupine_85I'd imagine the versions might change between operators, roms, etch
15:13.05lupine_85voda UK
15:13.07NetRipperexactly
15:13.19NetRipperuk layout may differ from dutch
15:13.22lupine_85hence why you'd have keycode maps for sets of versions
15:13.49lupine_85you might get the same version of microP with different keycodes, if unlucky
15:13.52NetRipperif your raph100 reports a different version than my raph100, would be nice
15:14.00lupine_85what version does yours say?
15:14.01exco~seen pH5
15:14.01aptph5 <n=ph5@p5485D104.dip.t-dialin.net> was last seen on IRC in channel #openezx, 4d 21h 21m 40s ago, saying: 'I don't even see pxafb come up, so I guess it's time for some gpio led debugging.'.
15:14.09NetRipperi dont know, havent booted yet
15:14.17NetRipperstill at wrk
15:14.19lupine_85(I pulled my version from the SPL)
15:14.28NetRipperoh
15:15.32AstainHellbringhow can one check microp version other than spl?
15:15.37lupine_85i2c reads
15:15.49lupine_85presumably, that's what the spl does too
15:16.09AstainHellbringinteresting ok how can one check it via spl?
15:16.26lupine_85you just soft reset with VolDown held
15:16.37AstainHellbringso just jump into bootloader?
15:17.05AstainHellbringic cool
15:17.28AstainHellbringMicroP-Raph (LED) v13 MicroP-Raph (KEY) v5
15:18.17lupine_85AstainHellbring: what model/operator/country/key layout is your phone?
15:18.36lupine_85(and what's the version for the raph100?)
15:18.36AstainHellbringits euro TP with front cam raph 100
15:18.58lupine_85I'm v5 also
15:19.03AstainHellbringbought it from a importer
15:19.11AstainHellbringthe 800 coming in a sec
15:19.14lupine_85AstainHellbring: do you have weird non-UK-english characters on the keyboard?
15:19.53AstainHellbringwierd characters?
15:20.13lupine_85łe¶ŧ←↓→øþæßðđŋħklklll
15:20.19lupine_85whoops
15:20.37AstainHellbringthe raph 800 reports MicroP-Hermann (LED) v0C85 MicroP-Herman (KEY) v0685
15:21.10lupine_85<PROTECTED>
15:21.11NetRipperi have a UK version of the raph as well
15:21.16NetRipperso cant tell
15:21.18lupine_85(just the last one)
15:22.19NetRipperv13/v5 here as well, but i have uk raph100..
15:23.28lupine_85I think the choice is using the version numbers or mtypes if we do it in kernel
15:23.41*** join/#htc-linux MethoS (n=lem@host-091-096-215-140.ewe-ip-backbone.de)
15:24.29AstainHellbringwill have fuze microp in a sec
15:25.10AstainHellbringlooks like fuze is v5 too
15:26.17lupine_85balls
15:26.21lupine_85that's the end of that then :p
15:29.54*** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net)
15:30.34toerøæå
15:31.36toerisnt the special characters fn + key on the keyboards anyway
15:34.50lupine_85UK one, certainly
15:35.14lupine_85OOTB versions can't distinguish between raph100 and raph1100
15:35.18lupine_85(anyway)
15:35.36XDmicrop?
15:36.36AstainHellbring<PROTECTED>
15:36.40AstainHellbringmicrop same
15:37.28lupine_85doesn't really like the idea of that many mtypes
15:38.22NetRipperme neither
15:38.50NetRipperwhich is why i think we should solve it in userspace ;)
15:38.54lupine_85yeah
15:38.57XDAstainHellbring,
15:39.02AstainHellbringyes?
15:39.03lupine_85userspace input driver?
15:39.05XDno wth is a microp
15:39.07XDlol
15:39.11XDmicro operating sys?
15:39.22lupine_85XD: it's an API
15:39.36lupine_85we talk to it via i2c to get keyboard data
15:39.48XDi see
15:42.27NetRipperraph100 | raph110 | raph500 | raph800 | diam100 | diam300 | diam500 | diam800
15:42.33NetRipperam i missing any known types?
15:42.40NetRipperraph300 perhaps? diam110?
15:42.45NetRipperor do i have types there that dont exist
15:43.02AstainHellbringno diam110 yet or raph 300 that I have heard of
15:43.10NetRipperok
15:43.25lupine_85someone mentioned a raph400 but I dunno if thast was just a typo
15:43.59NetRipperanyone know the msmsdcc_id for raph110,500 and diam300,500?
15:44.04AstainHellbringlupine_85 was typo
15:44.17AstainHellbringNetRipper how one check those?
15:44.32NetRipperthe msmsdcc_id passed to the kernel to get mmc working
15:44.45NetRipperyou check it by experimenting (easiest way)
15:44.54AstainHellbringlol
15:45.07NetRipperi.e. when a diam500 user has android 1.0 working, which msmsdcc_id is he using ;)
15:45.13NetRipperin his default.txt
15:45.23NetRipperi know a few, but not those
15:45.28XDlupine
15:45.34XDthat raph400 was me
15:45.37XDand it was a typo
15:45.41XDit's a 500
15:46.22NetRipperXD
15:46.27NetRipperdid you get android 1.0 working on your phone?
15:46.33XDnope
15:46.39NetRipperoh
15:46.44NetRipperor didnt you try?
15:46.48XDany updates in the last few days?
15:46.51XDI did
15:46.55NetRipperwhat happened?
15:47.02XDcolors were off
15:47.08NetRipperbesides that
15:47.11lupine_85hmm. newest kernel doesn't pick up the sd card here
15:47.24NetRipperlupine_85 restart and try again
15:47.36XDscreen didn't seem to work, it didn't look like the andriod I was used to
15:48.00NetRipperXD but did you get to the android screen? even though it was not proper
15:48.04lupine_85(this is with the keyboard driver compiled in)
15:48.06NetRipperpassed the loading screen
15:48.18XDya
15:48.26XDafter I went to a previous version
15:48.28NetRipperXD ok, which msmsdcc_id kernel parameter are you using in default.txt?
15:48.35XDthat worked for raph500
15:48.51XDnewest vers a few days ago had kb issues
15:49.09NetRipperok
15:49.14NetRippercheck your default.txt pls
15:49.16NetRipper:)
15:49.48XDI'm trying to get my phone replaced by verizon, so I have flashed it to stock rom and cleaned it all out
15:49.51XDhehe
15:50.10NetRipperah
15:50.17NetRipperit was on your sd card, you didnt need toc lean that ;)
15:50.29XDit wasn't
15:50.32XDit was on internal
15:50.37XDI don't have a sd yet
15:50.38NetRipperer, ok.. how could it mount then
15:50.43NetRipperaha
15:50.45XDlol
15:50.50AstainHellbringbrb
15:50.52XDidk but it did
15:50.54XDo_O;
15:50.54NetRipperit's not possible that you booted android 1.0 then ;)
15:51.05XDlol
15:51.08XDI booted something
15:51.20NetRipperandroid 0.8 perhaps
15:51.25NetRipperold one
15:51.27XDya
15:51.33lupine_85right, just tried the previous zImage again and that works. time for newest again...
15:51.36XDthe new one wouln't let me type
15:51.37NetRipperok
15:52.10NetRipperlupine_85 may be caused by differences between raph800 and raph100
15:52.19NetRipperlupine_85 oh, btw, lol
15:52.29NetRipperlupine_85 you need to ignore some changes in board-raphael.c
15:52.42maejrep[w]<PROTECTED>
15:52.48NetRipperlupine_85, it changes gpio's
15:52.51lupine_85yeah, that'd do the trick
15:52.59maejrep[w]lupine_85: it should definitely apply against git head, cause I did a pull just before creating the diff
15:53.06NetRipperthus it probably thinks sd card is not in
15:53.27lupine_85maejrep[w]: it wasn't a git-apply patch and/or it got a bit mangled in privatepaste
15:53.28maejrep[w]although, i accidentally included the GPIOs for raph800 in the diff ;x  so you'll want to revert those last 3 changes in the board-raph file
15:53.31lupine_85it's applied now
15:53.38lupine_85I've updated the .keys to be raph100
15:53.47lupine_85it's only really the top row that differs
15:54.12*** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de)
15:54.55maejrep[w]<PROTECTED>
15:55.05NetRippercr2, http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO (at bottom) i'll enter more when i know them.. may look through forum to find them out
15:55.31maejrep[w]but I guess a "major" version could be considered (ie, raph800 so far I've seen 0685 and 0682, so 0680 is at least common)
15:55.37NetRippermaejrep, we already found the raph110 returns same as raph100 ;)
15:56.37maejrep[w]oh that sucks
15:56.39maejrep[w]0685?
15:57.00maejrep[w]if model id were actually where the research page says it should be in smem, we could use that :)
15:57.00NetRipperat least spl returns the same.. i suspect your version thingy to return the same as what spl does
15:57.08maejrep[w]yup
15:57.39NetRipperdump smem and search for it? :p
15:57.48maejrep[w]I think I have ...
15:57.56maejrep[w]I'll have to see if I can get to my home machine yet
15:58.08maejrep[w]I think my roommate changed the port forwarding ;x
15:58.16NetRipperlol
15:58.20NetRipperroommates--
15:58.33NetRipperi gtg, talk to you later
15:58.44maejrep[w]:|
15:59.00lupine_85reverts those three changes, recompiles
15:59.13*** join/#htc-linux maejrep[w] (n=madCoder@smtp-n.myyearbook.com)
16:02.09cr2NetRipper: does the phone work on raph ?
16:03.45cr2there are only versions 5, 85 and 82. everything else will not be served
16:05.16*** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring)
16:05.53lupine_85it booted!
16:05.57lupine_85but I forgot about the VDH
16:05.59AstainHellbringwhat did lupine_85?
16:06.29lupine_85kernel with keyboard driver in
16:06.31cr2lupine_85: can you compile the tiacx driver ?
16:06.42AstainHellbringnice
16:06.58lupine_85cr2: haven't tried, am at work right now
16:07.07lupine_85I've just got a spare 20 minutes or so
16:07.16cr2ok
16:07.34cr2we will soon need it :)
16:08.02AstainHellbringcr2 whats the tiacx driver do?
16:08.08lupine_85wifi
16:08.34cr2AstainHellbring: does the phone/ gps work ?
16:08.51*** join/#htc-linux ltxda (n=anon@unaffiliated/ltxda)
16:08.59maejrep[w]i don't know where the gps buffer is on raph800
16:09.26cr2maejrep[w]: do you use the vogue or the g1 driver ?
16:09.33maejrep[w]eh?
16:09.41cr2smd
16:09.43maejrep[w]i'm talking about smem -- gps buffer doesn't appear anywhere in my smem dump
16:09.59maejrep[w]i'm not using smd at all yet, still need to do the vogue hack for AT buffer
16:10.03AstainHellbringcr2 I dont think it does not tried any of the latest kernels on either raphs yet
16:10.33cr2maejrep[w]: the diam/raph layout is g1-like
16:10.48maejrep[w]cr2: I don't know where gps data is..  even when using the htc gps test tool (and can see/log active gps commands), and dumping all of smem, it does not show up anywhere
16:11.26cr2ok
16:11.58cr2maejrep[w]: the kaiser wiki has 2k+24 header for each channel
16:12.16maejrep[w]right
16:12.19cr2maejrep[w]: and raph/diam the 0x14+8k
16:12.27cr28k+20
16:12.51cr2g1 is 20byte header too
16:12.52maejrep[w]the AT buffer at least does not have an adjacent head like the other smd channels (even on raph800)
16:13.04cr2all the channels are an array of that soize
16:13.17maejrep[w]yes, but only the auto-detected channels :)
16:13.23maejrep[w]and the AT buffer is not in that list
16:13.32cr2it hason my raph100 , i've check my 1f
16:13.45maejrep[w]yes, raph100 is auto-detected
16:13.49cr2DS ?
16:13.53maejrep[w]but raph800 is not, the buffer lives elsewhere
16:13.59maejrep[w]right, raph800 does *not* find a DS channel
16:14.03maejrep[w]it starts at "DATA2"
16:14.05cr2weird
16:14.12cr2ok
16:14.15maejrep[w]also finds DATA5, etc
16:14.24maejrep[w]trying to get into my home box, and I can find that for sure
16:14.43cr2i'll try with umts
16:14.55lupine_85hmm, keyboard doesn't appear to be working here
16:15.01lupine_85but I can't do much debug
16:15.02maejrep[w]:o
16:15.14maejrep[w]is it the wrong gpio/irq?
16:15.25cr2i still don't understand how to determine the array offset
16:15.42cr2maejrep[w]: don't hardcode the gpios/irqs :)
16:15.46maejrep[w]try in haret: joinlist traces gpios, then wirq (ibit gpios as needed)
16:16.04maejrep[w]cr2: its hard coded in pdata, which as i understand it is the only/best way (?)
16:16.07lupine_85maejrep[w]: I@m at work
16:16.08lupine_85:p
16:16.11cr2maejrep[w]: all the raph100 dtaa is in the wiki
16:16.11maejrep[w]oh
16:16.13cr2?
16:16.28maejrep[w]cr2: but it doesn't say "this is the keyboard irq lol"
16:16.39*** join/#htc-linux mib_fqbppw (i=4d14b78a@gateway/web/ajax/mibbit.com/x-eba3ab96c3055280)
16:16.57maejrep[w]so gpio 27 may not be the same one on raph100 :|
16:17.12lupine_85and which /win 2
16:17.33cr2ok
16:17.49maejrep[w]it doesn't show up in "show gpios" either, so you have to do it in traces & wirq
16:18.00lupine_85I can't even get a terminal on the machine right now to play properly
16:18.04lupine_85it might just be X
16:18.08cr283   0x53      3   15   I   irq (key poweron?) arm9dex related, Gkey
16:18.13maejrep[w]oh could be
16:18.24maejrep[w]i am still running the angstrom initrd
16:18.27cr2this is the power button afaik
16:18.34maejrep[w]yeah I think that's right
16:18.50maejrep[w]I use gpio 27 though, 1-11
16:18.52maejrep[w]labeled Ukey
16:19.21cr227   0x1b         11      irq (Y) wakeup, Ukey
16:20.26cr2ok, i don't see any other
16:23.50cr2maejrep[w]: i don't see the bt driver for g1 ?
16:24.08cr2btw, where can i download the closed source g1 parts?
16:24.25lupine_85maejrep[w]: so change the .clamshell gpio to 83 ?
16:26.00cr2NetRipper: i think that your entried are not correct
16:27.17cr2s/entried/entries/
16:28.25cr2NetRipper: you have only 2 muxed SD ports, 7201A has 4
16:28.53maejrep[w]lupine_85: no, if there's a problem it would be the .irq in board-raph's pdata
16:28.57cr2and (i think) g1 sdcc driver does not support multiplexing
16:29.25*** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com)
16:29.43cr2maejrep[w]: set the pdata depending on the mtype
16:30.05cr2don't staticlally compile it into the kernel
16:30.10lupine_85ho hum, yay fun
16:30.22cr2the g1 code hardcodes too much imho ;)
16:31.54cr2btw, why doesn't NetRipper configuring the ts irq as rising edge ?
16:32.19maejrep[w]cr2: sure, but what happens if there's a difference between raph100 and raph110, etc
16:32.28maejrep[w]where we don't have mtypes
16:32.48cr2use kernel command line parameter
16:32.55maejrep[w]:X
16:33.05maejrep[w]i'd like to make it module related
16:33.24cr2agreed
16:33.37cr2as modular as possible will be nice
16:33.43maejrep[w]that is, compiled as a module with module parameters
16:33.55maejrep[w]but i guess that may not be a good idea :P
16:34.03cr2it forces good coding style :)
16:34.14maejrep[w]did you see my discussion with tmzt last night, about my thoughts on how to refactor it?
16:34.26cr2mfd ?
16:34.34maejrep[w]that was his idea yeah
16:34.46cr2we will get leds and bkl too
16:35.06cr2so the microP will be close to asic3 in complexity
16:35.23maejrep[w]my thought was having 2 chip drivers for interacting with 0xce, and for 0xcc.  and an input driver that a) requests the gpio27 irq, b) reads scancodes from the KSC chip driver, c) requests a notification reset from the KLT driver
16:35.52cr2ok
16:35.59cr2it's o the i2c side
16:36.09cr2but you also need the subdrivers
16:36.20maejrep[w]yeah, the idea being the keyboard driver would not interact with i2c directly, but with the chip drivers
16:36.23cr2for led(s)/backlight(s)
16:36.25maejrep[w]is that a bad way of doing it?
16:36.50cr2why ?
16:36.59maejrep[w]why what :o
16:37.23cr2why is it a bad way ?
16:37.30maejrep[w]I was asking if its a bad way :)
16:38.09cr2no
16:38.22drasarHi cr2. Have you got CVS access already?
16:38.35maejrep[w]so we'd end up with a microp_kbd driver, and two i2c chip drivers: microp_klt and microp_ksc (and others for accelerometer and so on)
16:39.00cr2drasar: no, but i have got a different idea how i can do it.
16:39.41cr2maejrep: and the led driver and backlight driver
16:40.08drasarcr2: Great. You can find the latest patch at http://www.handhelds.org/hypermail/kernel-bugs/current/0238.html
16:40.11cr2maejrep[w]: you only need to sort out the module dependencies right
16:40.20cr2drasar: ok
16:40.48maejrep[w]cr2: as in, led and backlight drivers that are also not interacting with the i2c-msm bus directly, but with the microp-led i2c chip driver, yes?
16:41.14cr2drasar: i don't see why you can't match ba in capabilities. the only dark area is the backpack, and bt. but bt may be done too.
16:41.52cr2maejrep[w]: yes, they need the 0xcc/2 channel
16:43.23cr2maejrep[w]: does the haret-w.exe from j820 work on raph800 ?
16:43.34maejrep[w]cr2: but you agree that the i2c chip drivers should only expose functions for performing specific actions, not implement driver functionality (like keyboard and led behavior)
16:43.40maejrep[w]I don't know what haret-w is
16:44.00cr2maejrep[w]: yes
16:44.11cr2maejrep[w]: it's what mfd is about
16:44.16maejrep[w]ok, then I'll work on splitting that out then
16:44.29maejrep[w]well, if it's mfd, where would the drivers go? :P
16:44.36maejrep[w]i2c/chips/*  or linux/mfd/* ?
16:45.54cr2mfd should load the i2c/chips/
16:46.18cr2hmm, sf.net has broken something
16:47.01cr2http://jornada820.sourceforge.net/files/haret/haret-w.exe
16:47.30maejrep[w]what does it do differently
16:48.15cr2it has more commands
16:48.26cr2to control the bt and bkl remotely
16:48.56cr2pwrctl, btctl, irctl and wifi
16:48.59maejrep[w]downloading it now
16:49.07cr2but wifi is not portable enought
16:49.09maejrep[w]not sure if I can get RNDIS support on os x though
16:49.18cr2you need to know the wifi device name in wince
16:49.24maejrep[w]cr2: it doesn't find Raphael
16:49.31maejrep[w]says "Generic ARM v6"
16:49.36cr2to switch off the wifi using this way
16:49.38maejrep[w]for raph, we needed to patch haret to find it
16:50.09cr2maejrep[w]: hmm, but does the command itself work ?
16:50.21maejrep[w]will try, just a sec
16:50.34maejrep[w]gonna need to try wifi since rndis isn't setup here
16:50.38cr2it's a portable part, no msm-specific things there
16:50.49cr2ok
16:51.25cr2i didint have time/mmod to merge it into mainline haret
16:51.45*** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be)
16:51.48cr2because of some strange headers
16:52.59*** part/#htc-linux mib_fqbppw (i=4d14b78a@gateway/web/ajax/mibbit.com/x-eba3ab96c3055280)
16:53.08*** join/#htc-linux mib_fqbppw (i=4d14b78a@gateway/web/ajax/mibbit.com/x-eba3ab96c3055280)
16:57.15cr2maejrep: do you think that an uart may be used for ATCMD ??? not impossible, but still very strange
16:57.59dream_killhi
16:58.04maejrep[w]I don't know anything about uart, what it is, what it does, or how it does it :)
16:58.23dream_killwhat's the updates on the raph100 progress?
16:58.25cr2ok
16:58.51dream_killis the nand driver working for it?
16:58.56cr2dream_kill: does the phone/gps work for you ?
16:58.58*** join/#htc-linux chab7 (n=kvirc@212.92.4.114)
16:59.04maejrep[w]i don't think anyone has worked on nand yet
16:59.15cr2dream_kill: nand can be checked in dmesg output
16:59.30dream_killdid u tested the g1 nand driver?
16:59.34dream_killit should work fine
16:59.37dream_killas is same cpu
16:59.43cr2maejrep[w]: the partitions, but the driver may id the chip itself
16:59.44dream_killand same chip
17:00.17dream_killi managed to full dump the g1 nand chip :D
17:00.21cr2dream_kill: it's mainly about the partitions, not the chip driver itself.
17:00.33dream_killthe partitions is done BY the SPL
17:00.39dream_killin G1 same
17:00.46dream_killthe partition table is done by the spl
17:00.54dream_killit pass to kernel the partition table
17:01.01cr2spl is irrelevant
17:01.01maejrep[w]that's odd
17:01.08dream_killi tested it
17:01.13cr2you need to know the byte offsets
17:01.21dream_killgot few bootloaders for g1
17:01.24cr2to add into the linux driver
17:01.26dream_killand 1 is a mfg one
17:01.42dream_killso when mfg spl i have a extra partition
17:01.45dream_killmfg
17:01.54dream_killwhen normal bootloader the mfg dissapear
17:01.59drasarcr2: What do you mean with it?
17:02.00dream_killi found it then in the spl
17:02.13dream_killu can manual define the partition table in the driver
17:02.17dream_killi done it too
17:02.31cr2maejrep[w]: do the commands work for you ?
17:02.31dream_killall u need is the offsets, size, name
17:02.44cr2dream_kill: yes.
17:02.56dream_killwhy i asked about raphael, is that for g1 i managed to patch the oemsbl and removed the MPU protection :D
17:03.21dream_killso i'm going to patch the raphael now to remove the MPU protection
17:03.40dream_killthen we can write the full image from g1 into it :D
17:03.59AstainHellbringdream_kill there is already a spl for that
17:04.10cr2dream_kill: full image does not make sense
17:04.16dream_killfor writing FULL image?
17:04.30dream_killis for writing ONLY partitons allowed :D
17:04.43cr2dream_kill: but if the g1 amss may be installed on raph (and will work), that will be fun
17:04.50dream_killyes
17:04.55dream_killthis is THE idea
17:05.07cr2ok
17:05.07dream_killanyone with a raphael in waranty still ?
17:05.17lupine_85moi...
17:05.20dream_killi can send him to test a radio from dream
17:05.35dream_killi made the .nbh file already
17:05.40dream_killso we can test to flash it
17:05.46dream_killjust the radio
17:05.49AstainHellbringyou will need a sec unlocked device to flash radio
17:05.55dream_killsince we seems all msm7201a are interchangeble
17:05.59dream_killyes
17:06.10cr2dream_kill: but i guess that the radio must be signed
17:06.27AstainHellbringwhat will dream radio give that other radios wouldn't?
17:06.29dream_killIS singed
17:06.38cr2ok
17:06.51dream_killit should map correctly the GPIO's for linux :D
17:06.54AstainHellbringdream_kill send me radio
17:07.12dream_killurs is security unlocked?
17:07.15cr2AstainHellbring: we will get rid of the vreg/clk pita
17:07.27cr2dream_kill: map the gpios ???
17:07.56cr2dream_kill: but are you sure that the arm9 gpios are the same on both ?
17:07.57dream_killdid u checked the oemsbl as i told u ?
17:08.03dream_killyes 100%
17:08.59cr2i eman the arm9 gpio usage. i have no idea about the purpose of the arm9 gpios
17:11.06dream_killok uploading radio to rapidshare
17:11.41dream_killinside still have references to raphael, diamond, nike....
17:12.48dream_killhttp://rapidshare.com/files/184399875/flash_to_g1.rar.html
17:12.55dream_killflash this ONLY if security unlock
17:13.01dream_killand ONLY if u still have warranty
17:13.12dream_killas it might send your device to sleep :D
17:14.00dream_killanyone brave?
17:23.22dream_kill?
17:24.12XDo-o
17:29.37*** join/#htc-linux AstainZZZZZZ (n=AstainHe@unaffiliated/astainhellbring)
17:34.19dream_killno one :P ?
17:35.52AstainHellbringhuh dream_kill?
17:36.17dream_killhttp://rapidshare.com/files/184399875/flash_to_g1.rar.html
17:36.21dream_killflash this ONLY if security unlock
17:36.26dream_killand ONLY if u still have warranty
17:36.29dream_killas it might send your device to sleep :D
17:36.33dream_killanyone brave?
17:36.35dream_kill:P
17:36.52AstainHellbringI brave enough to give it to cmonex and see if she says it should be safe to flash
17:43.31*** join/#htc-linux zycho (n=zycho@a89-183-78-110.net-htp.de)
17:45.53*** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes)
17:48.34dcordesyo
17:49.23lupine_85hi dcordes
17:49.50dcordesman I just looked at the raph
17:50.01dcordesdidn't see it before. the keyboard is awesome
17:50.13lupine_85not working for me on raph100 yet
17:50.43*** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com)
17:51.10dcordeslupine_85: do you need to change tslib configuration or code to use raph ts in angstrom?
17:51.23lupine_85dcordes: only slightly
17:51.29dcordeswhat do you change?
17:51.30lupine_85it expects /dev/input/touchscreen0
17:51.36lupine_85(it should be /dev/input/event0)
17:51.48lupine_85that's set in /etc/profile.d/ts.conf IIRC
17:51.56dcordesdoesn't OE do a symlink?
17:51.58lupine_85or you can symlink fix
17:52.02lupine_85not by default AFAIK
17:52.07lupine_85I added one
17:52.28dcordesmight be the better way. let's add this to the image install
17:52.41dcordesso you get a fully working image when building for raph
17:52.51dcordeswe can also add the frameworkd config
17:53.05dcordesdid you do further tests with franeworkd-devel?
17:53.50lupine_85mm, it screwed up the screen calibration somehow
17:53.59lupine_85not sure how that worked
17:57.36dcordesit is the driver-side calibration?
17:57.53*** join/#htc-linux TheOther (n=nahh@108.84-49-166.nextgentel.com)
17:58.24lupine_85I think frameworkd changed the X server to read from the wrong device
17:58.52lupine_85since the lack of calibration problem was similar to when it was reading from the device as ps/2
17:58.56lupine_85anyway, must go to salsa
18:00.41*** join/#htc-linux TheOther (n=nahh@108.84-49-166.nextgentel.com)
18:05.59dcordeslupine_85: have fun
18:06.27AstainHellbringanyone know if linux support for HID devices has gotten any better in the past little while?
18:07.56maejrep[w]I haven't had any problems with HID
18:08.19AstainHellbringdo you have to reconnect the device upon reboot or?
18:08.32AstainHellbringbeen a while since I used BT and a mouse/keyboard on linux
18:10.50*** join/#htc-linux exco (n=exco@e181083211.adsl.alicedsl.de)
18:12.21maejrep[w]no, I don't
18:12.51maejrep[w]if I switch my HID device to HCI mode (done during bootup automatically), it just works
18:13.54AstainHellbringhci?
18:14.05maejrep[w]bluetooth
18:14.23maejrep[w]there's a bluez util called hid2hci
18:14.28AstainHellbringhmm cool maybe I will try kubuntu again
18:14.48maejrep[w]for devices that provide both modes (like my logitech bluetooth combo dongle)
18:15.04maejrep[w]if I don't want to mess with bluetooth, I can leave it in HID mode, and not worry about pairing, etc
18:15.07AstainHellbringahh nice which logitech set you have?
18:15.18maejrep[w]MX5000 I think
18:15.20maejrep[w]something like that
18:15.44AstainHellbringnice I has mx5500
18:15.53maejrep[w]maybe that's what it is..?
18:16.07maejrep[w]does it have the LCD at the top that has like temperature, calculator, etc?
18:16.21maejrep[w]and notify about new emails (if you have the software installed)
18:16.26AstainHellbringyes but both have that
18:16.31maejrep[w]oh
18:16.52AstainHellbring5500 doesnt have the page up/down button but has scroll wheel on thumb
18:16.54maejrep[w]i know my mouse at home doesn't work with revoco to set the scroll wheel mode
18:17.20maejrep[w]yeah mine has the side wheel plus back/forward, wheel tilt, free spin wheel mode, etc
18:17.37maejrep[w]i have the same mouse at work, minus bluetooth, and revoco works with it
18:17.52maejrep[w]so I can set the wheel into free spin mode, and get access to my middle click again
18:18.09maejrep[w]but at home clicking the wheel just changes the wheel spin mode
18:18.44*** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com)
18:18.51AstainHellbringif you connect it to a windows box and set the mode with set point it should keep the mode after change back
18:23.27maejrep[w]yeah it does, but it eventually loses it
18:23.36maejrep[w]it works from virtualbox or vmware as well
18:23.41AstainHellbringwierd
18:24.07maejrep[w]like when i put it on the charger or something like that
18:24.32AstainHellbringhmm I having issues with mine where I can't get windows 7 to connect to it via the onboard bluetooth in my lappy
18:25.13*** join/#htc-linux diogene31 (n=rj@mur31-2-82-243-122-54.fbx.proxad.net)
18:26.13*** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com)
18:31.40*** join/#htc-linux frysee (i=4d14b78a@gateway/web/ajax/mibbit.com/x-fcdcae8a7ecb6d0c)
18:33.03*** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com)
18:35.38*** join/#htc-linux skodde (n=skodde@unaffiliated/skodde)
18:39.18AstainHellbringdream_kill get anyone to flash that radio yet?
18:42.15*** join/#htc-linux Tinyboom (n=nahh@108.84-49-166.nextgentel.com)
18:44.06*** join/#htc-linux kiozen (n=oeichler@rgnb-5d87dfb5.pool.einsundeins.de)
18:44.23*** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net)
18:54.22*** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl)
18:55.12*** join/#htc-linux TheOther (n=nahh@108.84-49-166.nextgentel.com)
18:57.16*** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl)
19:02.41*** join/#htc-linux RZK333 (n=rzk@daemonet.ru)
19:09.25*** join/#htc-linux DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk)
19:10.31NetRipperAstainHellbring, you contacted cmonex yet? :)
19:12.31*** join/#htc-linux Tintammare (n=Administ@set25-1-88-166-169-49.fbx.proxad.net)
19:13.19*** join/#htc-linux Mgaveve (n=king@41.208.50.180)
19:14.15*** join/#htc-linux hollo (n=hollo@3e6b025d.rev.stofanet.dk)
19:26.14*** join/#htc-linux Guimli (n=guimli@ecu69-1-82-231-127-213.fbx.proxad.net)
19:27.13Tintammarehi
19:30.41*** part/#htc-linux Tintammare (n=Administ@set25-1-88-166-169-49.fbx.proxad.net)
19:37.23*** join/#htc-linux NeoS20074 (n=neos2007@85.149.240.24)
19:38.00NeoS20074hey guys
19:40.57*** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey)
19:41.15*** join/#htc-linux BHSPitLappy_ (n=BHSPitLa@ppp-70-243-200-223.dsl.rcsntx.swbell.net)
19:47.01*** join/#htc-linux exco (n=exco@e181126244.adsl.alicedsl.de)
19:48.51NeoS20074anyone got android booting on HD?
19:50.04*** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be)
19:51.50AstainHellbringNetRipper tried nothing back yet
19:53.39*** part/#htc-linux exco (n=exco@e181126244.adsl.alicedsl.de)
19:57.32*** join/#htc-linux pichurri (n=pichurri@194.230.146.86)
20:00.48*** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl)
20:04.32NeoS20074Haret shows the loading bar but after that's full it hangs my device. i guess that's what everyone's having?
20:11.19*** join/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net)
20:19.20*** join/#htc-linux Mullins (n=bw@89.204.245.91)
20:20.17*** join/#htc-linux cr2 (n=cr2@ip-90-187-3-82.web.vodafone.de)
20:22.33cr2NetRipper: have you seen my comment about MSM_SDIO ?
20:22.41cr2kiozen: already sleeping ?
20:25.36cr2maejrep[w]: raph800 has "mpp"
20:26.07maejrep[w]what is mpp
20:26.07cr2and 6 lcd configs
20:26.08cr2no idea
20:26.13maejrep[w]:D
20:26.20cr2some power IC like pmic
20:26.26*** join/#htc-linux Othello (i=Othello@gateway/tor/x-baa2757073099e5f)
20:26.58cr2i have found my old dumped wince dmesg
20:27.47cr2raph500 is raph800 ?
20:28.21AstainHellbringno cr2
20:28.28AstainHellbringraph500 is verizon raphael
20:28.35AstainHellbringraph 800 is other carriers rapherl
20:28.52cr2are there any hardware differences  ?
20:28.57AstainHellbringyes
20:29.00rolkHi. Noticed several commits in the htc-vogue branch of ltg-git. It seems that there has been some additional progress on the SD card for Kaiser. I'm a bit confused: it seems vogue_defconfig is now actually a default kaiser config?
20:29.01AstainHellbringproc and mem
20:29.09cr2i see raph500000 id for raph800 spl
20:29.46cr2rolk: the sd setup should be the same
20:29.49maejrep[w]what?
20:29.56maejrep[w]in my spl dump it's "RAPH80000"
20:30.07maejrep[w](4 0's, but its an 8, not a 5)
20:30.30cr2rolk: even on 7201A it will be the same
20:30.31*** join/#htc-linux NeoS20070 (n=neos2007@82-136-223-208.ip.telfort.nl)
20:30.42cr2maejrep[w]: somebody dumped me this spl
20:30.55cr2maejrep[w]: it also calls itself Raphael_C
20:31.03cr2C is for CDMA probably
20:31.30cr2smi size 32 or 64
20:31.37cr2hmm
20:31.46AstainHellbring64 is the verizon TP 32 is sprint TP
20:31.46rolkcr2: I noticed the vogue_defconfig now both has CONFIG_MACH_HTCVOGUE and CONFIG_MACH_HTCKAISER set. That's odd, so when I build for kaiser, do I need to manually disable CONFIG_MACH_HTCVOGUE?
20:32.19Mullinsrolk: no, leave as is for kaiser
20:32.37Mullinsrolk: will add a kaiser_defconfig in a short while
20:32.56cr2rolk: it's probably an unfortunate Kconfig
20:33.05maejrep[w]yes I have Raphael_C as well
20:33.13maejrep[w]cr2: I was the one who dumped raph800 spl for you
20:33.23cr2hmm
20:33.26maejrep[w]so I don't know why you would see "raph50000"
20:33.28rolkOk. What about polaris (I have a polaris actually). Does the current build with vogue_defconfig boot on Polaris?
20:33.33maejrep[w]I know for sure that I saw "raph80000"
20:33.44maejrep[w]it stood out because of the 2 extra 0's
20:33.46cr2maejrep[w]: i'll check the 500 too
20:33.58maejrep[w]i think raph500 does show raph50000
20:34.08maejrep[w]I don't know why 800 would show 50000 though :x
20:34.23cr2hmm.
20:34.32rolkcr2: well, there are things that are probably now using CONFIG_MACH_HTCVOGUE that will be needed as well for a Kaiser/Polaris.
20:34.44cr2raph100 uses c4,0,9 for psoc id
20:35.07rolkBut also stuff that is really vogue specific, and not usable for kaiser/polaris and such.
20:35.13cr2and this raph500000 has c4,f,3,x
20:35.29maejrep[w]00001000  0a 00 00 ea 30 2e 33 37  2e 30 30 30 30 00 00 00  |....0.37.0000...|
20:35.30maejrep[w]00001010  52 61 70 68 61 65 6c 5f  43 00 00 00 00 00 00 00  |Raphael_C.......|
20:35.30maejrep[w]00001020  53 68 69 70 70 65 64 00  00 00 00 00 00 00 00 00  |Shipped.........|
20:35.48cr2rolk: it's not the cleanest kernel tree ;)
20:36.02cr2maejrep[w]: yes
20:36.03rolkYou'd expect a Kconfig flag that represents the common denominator for Kaiser/Polaris/Vogue (probably all msm7200). Is that an idea to add?
20:36.09maejrep[w]00081050  ff ff ff ff ff ff ff ff  00 00 00 00 54 53 45 52  |............TSER|
20:36.09maejrep[w]00081060  55 aa aa 55 85 98 89 58  52 00 41 00 50 00 48 00  |U..U...XR.A.P.H.|
20:36.09maejrep[w]00081070  38 00 30 00 30 00 30 00  30 00 00 00 ff ff ff ff  |8.0.0.0.0.......|
20:36.26maejrep[w]rolk: I agree with that
20:36.31cr2rolk: it's better to do the machines mutually exclusive
20:37.04maejrep[w]cr2: but something like "MSM_750x_SMD" for example, which implements smd the vogue-smd way
20:37.33Mullinsrolk: at the moment, Dzo is still finding out what is common to both Kaiser and Vogue and also plans to include Polaris, so eventually it will be tidy
20:38.03cr2maejrep[w]: it knows about PSOC-Diam
20:38.22maejrep[w]<PROTECTED>
20:38.22maejrep[w]PSOC-Diam STAGE_EVT v%x
20:38.22maejrep[w]PSOC-Diam STAGE_DVT v%x
20:38.22maejrep[w]PSOC-Diam STAGE_CVT v%x
20:38.22maejrep[w]PSOC-Diam STAGE_PVT v%x
20:39.12cr2yes
20:39.48rolkMullins: I know. Good stuff is happening. I'm just trying to find out how you all feel this should be set up. In any case, I think there will be plenty of shared stuff for all msm7200 based machines (irq handling, ...) which is different from the msm7201 stuff. And also specific stuff.
20:39.48maejrep[w]00011560  25 78 0a 00 42 4f 4f 54  20 6d 6f 64 65 20 3d 20  |%x..BOOT mode = |
20:39.48maejrep[w]00011570  25 64 0a 00 52 00 41 00  50 00 48 00 35 00 30 00  |%d..R.A.P.H.5.0.|
20:39.48maejrep[w]00011580  30 00 30 00 30 00 00 00  49 6e 69 74 20 54 6f 70  |0.0.0...Init Top|
20:39.48maejrep[w]:O
20:39.48maejrep[w]there's a 50000
20:40.00cr2maejrep[w]: i guess they are very close
20:40.18maejrep[w]except 500 has much less ram, which means the smem map would probably be very different, right?
20:40.26cr2maejrep[w]: but cdma vs. umts is rather different
20:40.33cr2no.
20:40.41rolkIf it ever is to get integrated with the other branches, to get a unified HTC branch in ltg-git, it would be good to think about how this is to be setup properly.
20:40.50cr2smem is always the 31th SMI megabyte
20:41.03cr2on all msm phones
20:41.39cr2rolk: then it's necessary to write clean, portable drivers
20:41.57cr2rolk: and not hardcoding random gpios and irqs :)
20:42.06cr2like g1 ;)
20:43.08rolkcr2: I know, first get everything up  and running, then make it beautiful. But I might be able to help out a bit in restructuring the code base, if there is a consensus on how to move forward in that area.
20:44.45*** join/#htc-linux timebomb (n=tb@e176100046.adsl.alicedsl.de)
20:45.17NetRippermaejrep[w], people using the security unlock and having i.e. a blackstone radio in their raphael's will show up as blackstone, right? :)
20:46.08cr2rolk: the clean htc-egpio driver implemented for an msm phone will be very helpful for everybody.
20:46.24cr2rolk: even for g1 ;)
20:46.35maejrep[w]NetRipper: I would guess that to be correct ?  :x
20:46.43cr2NetRipper: no
20:46.51maejrep[w]are you saying I've flashed a raph500 radio onto my raph800? :)
20:47.02cr2NetRipper: haret is a wince program, which picks this data from the wince kernel
20:47.46cr2maejrep[w]: my "500" and "800" spls are different
20:47.58cr2at least by the compilation date
20:49.01NetRippercr2, but how does wince know it's a raphael.. it uses the radio to determine that, doesn't it?
20:49.33NetRipperand radio = arm9 part, so that controls what is written in smem
20:49.42cr2maejrep[w]: strings -el shows 1 RAPH500000 and 2 RAPH800000 strings
20:49.49rolkOK. A clean build of ltg-git (htc-vogue branch), latest state, does not boot on polaris. I get a kernel panic.
20:49.52cr2maejrep[w]: cut'n' paste again ?
20:50.15cr2rolk: you have a different cpld address ?
20:50.48cr2NetRipper: i also see another problem
20:51.23cr2NetRipper: some gpios belong to arm9, and we don't know their function. i'm not 100% sure that these are the same everywhere, and have the same function
20:51.41NetRipperhm
20:51.52cr2NetRipper: you see how big are the differences for the arm11 gpios
20:52.08NetRipperamong the raph/diam/blackstone/xperia series the arm9 gpios are probably the same, as the radio's are interexchangeable
20:52.38cr2ok
20:52.48rolkcr2: cpld?
20:53.22cr2but it should not be the same for g1
20:53.42cr2rolk: the gpio extender
20:54.09maejrep[w]cr2: lol that'd be funny
20:54.22maejrep[w]and yes I saw the 50000 and the two 80000's as well
20:54.30NetRippercr2, regarding the SDIO.. i thought there were 2 sdio's.. SDIO1 and SDIO2 (as written in wiki)... and each SDIO has 2 "slots".. thus the SDC1_0, SDC1_1 and SDC2_0, SDC2_1
20:54.35*** join/#htc-linux Xime (n=xime@bankize.net)
20:54.43cr2NetRipper: on 7200
20:55.04cr2NetRipper: 7201A has SDC3_x and SDC4_x
20:55.16cr2NetRipper: check Raphael_IRQ page
20:55.25NetRippercr2, i see
20:55.40NetRipperi could swear it wasn't on memorymap wiki page a month ago
20:55.41NetRipper:P
20:55.47cr2and the _1 are not supported
20:55.47maejrep[w]it was :P
20:56.03cr2let swetland correct me if i'm wrong
20:56.06maejrep[w]its just not adjacent to the sdc1 and sdc2 areas, so its easy to lose them
20:56.08rolkcr2: The topmost line of the kernel log that I still can see is 'vogue_sdcc_slot_status'. Its being called in the context of 'msmsdcc_init'. This is in the kernel-panic trace.
20:56.51NetRipper0xa04/5/6/7 seem adjacent to me
20:57.17cr2rolk: well, that should not happen
20:57.34cr2NetRipper: 7200 uses a03 and a04
20:57.49NetRippercr2, ok
20:57.49cr2so it's a bit confusing
20:58.05cr2because 7200 has only one uartDM, afair
20:58.36NetRipperok so in that case
20:58.40NetRipperjust my naming scheme is wrong
20:59.09cr2NetRipper: i think that sdcc1 is SDC1_0 , sdcc2 is SDC2_0, ...
20:59.17cr2but it's my guess :)
20:59.48cr2you can verify it with 0xa0X area and the a0/a4, a8/ac, b0/b4 and b8/bc clocks
21:00.12cr2and the ARM11_CLK_CTL(0) register
21:00.19cr2bitmasks
21:00.20NetRippercr2, well i can see it in the msm_iomap.h... SDC1/2/3/4 are mapped on the addresses are specified in wiki
21:00.25NetRipperand we're using SDC2 currently for raph
21:00.27NetRipper100
21:00.31NetRipperand SDC3 for cdma
21:00.44rolkcr2: The vogue_defconfig is setting both CONFIG_MACH_HTCVOGUE and CONFIG_MACH_HTCKAISER, the makefile then includes both board-htcvogue.c AND board-htckaiser.c !?
21:00.45cr2NetRipper: what about g1 ?
21:00.51NetRippercr2, g1 uses SDC1
21:00.58NetRipperer
21:01.00NetRipperactually
21:01.02NetRipperlet me verify that
21:01.09cr2rolk: i have not written that code :)
21:01.22rolkI have no idea why this passes the link stage; you would bet that there are some duplicated symbols?
21:01.27cr2NetRipper: don't forget the wifi
21:01.50NetRippercr2, g1 uses SDC2 as well
21:01.50cr2rolk: it seems that is not the case
21:02.04NetRippersame as raph100
21:02.04cr2NetRipper: add g1 to the list
21:02.17cr2NetRipper: and wifi on SDC1 ?
21:02.33NetRipperneed to check
21:03.01cr2NetRipper: i want to document g1 in the wiki
21:03.10cr2in the same way as other phones
21:03.10NetRipperhm
21:03.19NetRipperah yes, wifi on 1
21:03.22cr2imho, it's very useful for fixing bugs
21:03.24AstainHellbringhehe I should have an eee to play with come tuesdayish
21:04.01NetRippermsm_add_sdcc(1, &trout_wifi_data);
21:04.04NetRipper<PROTECTED>
21:04.14*** join/#htc-linux mrincredible (n=mincredi@70-0-118-17.pools.spcsdns.net)
21:04.20cr2NetRipper: ok.
21:04.27NetRipperupdated wiki
21:04.35cr2NetRipper: and the 0xa4/a8 is the SDC1 ?
21:04.49NetRipperhow do i verify that?
21:05.02NetRipperim not familiar with the clocks
21:05.15cr2ok, doesn't matter now.
21:05.26cr2g1 gpios...
21:05.30cr2first.
21:05.37cr2and raph800 gpios
21:06.09cr2lupine_85: does the kbd driver work for you ?
21:06.50cr2NetRipper: back to TSSC. why don't you declare the irq with raising edge ?
21:07.23NetRipperi think i tried MASK.. which is all
21:07.24cr2NetRipper: there are 4 irq config options in wince, but i don't know yet which one is what.
21:07.35NetRipperon/off/rising/falling
21:07.44drasarcr2: did you try to apply my hima patch?
21:08.03cr2NetRipper: which IRQF_ flags are available
21:08.09NetRippercr2, sec
21:08.25cr2drasar: no, i need to checkout the hh tree to some external machine first.
21:08.37NetRippercr2, http://netripper.pastebin.com/m25c80267
21:09.02drasarcr2: ok
21:09.24cr2NetRipper: strange
21:09.26NetRippercr2, i think i tried IRQF_TRIGGER_MASK before
21:10.24*** part/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net)
21:10.41cr2NetRipper: try IRQF_TRIGGER_RISING
21:10.44NetRipperWhen requesting an interrupt without specifying a IRQF_TRIGGER, the setting should be assumed to be "as already configured", which may be as per machine or firmware initialisation.
21:11.00NetRipperok will try
21:11.03NetRipperbut a little bit later
21:11.06cr2ok
21:12.02cr2NetRipper: and i think it should be a platform_device, because it's a builtin msm function
21:13.23NetRipperok
21:14.13NetRipperi'll try doing that as well
21:15.37cr2blackstone has 2 lcds
21:15.45cr2toppoly and sharp
21:17.36cr2microp-blackstone (LED)
21:18.18cr2any bstone people around ?
21:20.15pichurricr2, yes?
21:21.13cr2pichurri: can you start the blackstone_gpio page, like we have raphael_gpio ?
21:21.46cr2remove the descriptions, and the alt values, but keep the numbers,banks, and such
21:22.14cr2then i'll just fill the missing data.
21:22.25pichurricr2, ok, but can't do it now, sorry...
21:22.43cr2gpio 0x62 and 0x63 are lcd power for example
21:22.43pichurricr2, tomorrow or sunday I will, :)
21:23.07cr2and 0x1f
21:23.10cr2ok
21:23.25pichurricr2, I think its pretty much the same thing as raph, but different panel/screen...
21:23.46pichurricr2, mmc its the same, android 1.0 boots but with bad output...
21:23.47cr2vreg(a,1,a28) and (4,1,b22)
21:24.04cr2same as what ? rapahel ?
21:24.25cr2raph100 ?
21:24.32pichurricr2, I mean in from hw point of view...
21:24.36pichurriyes raph100
21:24.37pichurrino?
21:24.40cr2ok
21:24.51cr2yes, looks very similar
21:25.27pichurricr2, :),
21:25.33pichurrinight! cya
21:26.29cr2gpio 0x59 is microP reset
21:30.50cr2bt-> x13,2,10,0 ; x14,1,10,0 ; x15,1,10,0 ; x6c,2,8,1
21:31.08cr2uart2
21:31.52cr2x67 is bt power
21:31.57cr2x65 bt reset
21:32.07cr20x32 msleep
21:36.02cr2NetRipper: what about kaiser/vogue/titan/polaris in SDIO ?
21:39.45NetRippererr i dont know, you want to add all of them?
21:40.05*** join/#htc-linux ali1234 (n=al@robotfuzz.co.uk)
21:40.25NetRipperguess i should flip the table ;)
21:40.39cr2yes. just put - for SDC3 and SDC4
21:40.40cr2ok
21:40.48NetRipperanyway i dont know about kaiser and the others
21:40.58cr2dcordes: ?
21:41.08NetRipperdo all of them have models like raph* as well? :)
21:41.08cr2haha
21:41.15NetRipperlol, he saw it coming
21:41.18NetRipperand ran
21:41.34cr2hey, any 7x00 people around ?
21:41.40cr2NetRipper: check the haret source
21:43.19NetRipperthere's something about CKEN
21:43.22NetRipperno idea what it is
21:43.36NetRipperbut it lists SDC1-4
21:43.48NetRippercken = clock enable?
21:44.08cr2yes
21:44.20cr2but i think it's wrong
21:44.30cr2to call it clock enable
21:44.36NetRipperwell
21:44.51NetRipperit should be clk :P makes it easier ;)
21:44.53cr2because i2c and mddi do not have such bits
21:45.14cr2so it can't be "enable"
21:46.03maejrep[w]cr2: the CKEN patch came from your suggestion to look at pxa ;)
21:46.18cr2NetRipper: the machtypes.cpp or something like that
21:46.47cr2NetRipper: in wince/ dir
21:46.54NetRippernothing special in machlist
21:47.00cr2maejrep[w]: yes, i'm making mistakes too :)
21:47.10*** join/#htc-linux AstainHellbring (n=AstainHe@c-67-164-195-234.hsd1.ut.comcast.net)
21:47.15AstainHellbringhi again
21:47.26imfloflohey guys i have polaris if i can help
21:47.27cr2AstainHellbring: do you have a 7x00 device ?
21:47.40AstainHellbringyes
21:47.44cr2imfloflo: what is your dev name ?
21:47.47imfloflohave you see this video  http://www.youtube.com/watch?v=jl0LSHbUbzE debian and android on the same
21:47.52imflofloPOLA100
21:48.04cr2NetRipper: i have kaiser spl, i can check
21:48.32cr2KAIS100 i think
21:48.32NetRipperimfloflo, do you know which other POLA there are?
21:48.33AstainHellbringcr2 I have kaiser titan raph800 and raph100
21:48.41*** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl)
21:48.46cr2AstainHellbring: KAIS100 ? what about titan ?
21:49.28imflofloI though there is a list on  xda wiki
21:49.30*** join/#htc-linux Balsat (n=kll@87.72.13.87)
21:50.03imfloflo100 & 200
21:50.05NetRipperimfloflo, ok
21:50.16rolkHmm...I goofed. It seems the latest build from ltg-git, branch htc-vogue does boot on Polaris, but I need to change the machine type in haret. Keys do not work as I would expect in Android.
21:51.34AstainHellbringcr2:  kaiser is the att tilt modEL KAIS110 i think and titan is the sprint versioffffn
21:51.55cr2ok
21:52.10cr2btw, what is the blackstone id ?
21:52.53AstainHellbringI also access to a DIAM800 and soon a vogue too
21:53.17cr2BLAC100
21:53.50NeoS20070me 2
21:54.35AstainHellbringwhy you ask cr2?
21:55.34cr2to use in wiki
21:55.54NetRipperhttp://wiki.xda-developers.com/index.php?pagename=MSM_SDIO
21:56.47maejrep[w]cr2: are you sure its not cken though?  haret does show it being enabled/disabled when expected
21:56.50maejrep[w]what else would it be
21:57.51NetRipperits cken for a few devices, but not general to all devices
21:58.21NetRipperi think that's what cr2 means at least;)
21:58.25cr2NetRipper: updated
21:58.43cr2NetRipper: yes.
21:58.45NetRipperok
21:58.57cr2maejrep[w]: i2c does not have such bit, for example
21:59.36cr2NetRipper: it's cken related for some subsystems, but not the cken itself
21:59.44maejrep[w]but i2c has its own clk_ctl register
22:00.03cr2it's the divisor setting
22:00.10cr2i2c has a divisor setting too
22:00.15maejrep[w]hmm
22:00.25cr2and they are even similar to some extent
22:00.26maejrep[w]would i2c's clock be the SCL line?
22:00.40cr2not really
22:00.56cr2it's the clock generatror frequency behind it.
22:01.55cr2maejrep[w]: where is wifi on raph800 ?
22:02.07cr2SDC port ?
22:02.35maejrep[w]yes
22:02.45maejrep[w]i think sdc2, but don't quote me on that
22:02.56*** join/#htc-linux Xime (n=xime@bankize.net)
22:03.05cr2ok
22:03.24cr2i'll look at it after blac100
22:15.33*** join/#htc-linux techie (n=blarg@ip24-250-216-85.ga.at.cox.net)
22:17.12*** join/#htc-linux kaze_ (n=kaze@ABordeaux-158-1-27-51.w90-55.abo.wanadoo.fr)
22:27.31rolkInteresting. I'm booting the 'kaiser+vogue' defconfig, with minor changes to the Makefile in arch/arm/mach-msm and in board-htckaiser.c. I got rid of the interrupts caused by the kaiser keypad implementation (that is out of place in a polaris), and it boots fine. Keys seem to work ok now but the touchscreen is erratic and the phone switches to a black screen after a few minutes and does not wake up.
22:30.21AstainHellbringmaejrep[w] can you tell me how to setup BT on kubuntu I can't seem to get it to do it right?
22:32.11Mullinsrolk: Do you use tsc2003.c with Polaris too?
22:36.09rolkMullins: I was just checking the differences in board-htcpolaris.c and board-htckaiser.c...
22:36.24rolkConcerning touchscreen interface....
22:36.55rolkThe one that previously worked for me has '.type = "voguets"'
22:37.02Mullinsrolk: ah ok
22:37.26rolkWhile the board-htckaiser.c has '.type = "vtsc2003-ts"'
22:37.35rolkIs wrong, no?
22:38.14Mullinsrolk: Kaiser doesn't use that anyway. it uses tsc2003.c although I noticed that device, it doesn't use it
22:38.16rolkActually, I have no clue whether this .type field actually matters at all.
22:38.29Mullinsrolk: I think you are right. It doesn't matter
22:38.48cr2rolk: can you compile the tiacx ?
22:39.00Mullinsdzo: Are you there?
22:40.09cr2maejrep[w]: seems like SDC1 to me
22:40.22rolkcr2: Hum. I can, if you tell me what it is... :)
22:40.42cr2maejrep[w]: returns controller=0
22:40.47rolkMullins: I'll check the kernel config.
22:40.58cr2maejrep[w]: and controller=2 for sd
22:41.27cr2rolk: the wifi driver from source.android git
22:41.52cr2it's a shame that we still don't have wifi running :)
22:42.34rolkcr2: is that in the android-git kernel?
22:43.44NetRippercr2, you made me cry
22:43.54NetRippercr2, the touchscreen irq is firing
22:44.06cr2rolk: http://android.git.kernel.org/?p=platform/system/wlan/ti.git
22:44.15cr2NetRipper: lol
22:44.34NetRipperboth 30 (press) and 31 (release)
22:44.47cr2NetRipper: now you owe me remiving the weird calibration stuff from the driver.
22:45.02cr2s/miv/mov/
22:45.47NetRippercr2, we'll lose the current virtual keyboard if we start using the minimal ts driver
22:46.07cr2NetRipper: and before reading the data register , you'd check the 0x800 bit set. at least wince does it so.
22:47.08cr2NetRipper: we have the real keybaord now ? anyway, you can make it an option. it's maybe important for the diam/blac people
22:47.39NetRipperyes especially for diam/blac people using shell and the sort
22:48.01cr2ok
22:48.16NetRipperbut i agree we should have a cleaner implementation
22:48.27cr2yes.
22:48.47NetRipperi.e. vkeyb may be a hack.. but ts driver should not depend on msmfb nor should msmfb refer to ts driver
22:48.50cr2NetRipper: what>'s next ? tiacx ? :)
22:50.13NetRipperdont know how hard it is to try
22:50.52NetRipperwhere do i find tiacx?
22:52.27*** join/#htc-linux frysee (i=4d14b78a@gateway/web/ajax/mibbit.com/x-f0777cfcb626e86b)
22:52.46cr2<PROTECTED>
22:53.06cr2it's not easy to compile afaik
22:53.28cr2but then we will only need some minor xhanges
22:53.46cr2it seems that tiacx is on SDC1 everywhere
22:55.29rolkcr2: I'm making a first attempt to compile the module.
22:55.39cr2good
22:56.00*** join/#htc-linux hollo (n=hollo@3e6b025d.rev.stofanet.dk)
22:56.15rolkerror: implicit declaration of function 'sdio_readb_ext'.
22:56.28maejrep[w]missing an include?
22:58.25cr2diam210000
22:59.22*** join/#htc-linux ionstorm (n=ion@ip68-227-226-5.ph.ph.cox.net)
22:59.32Mullinswho can give access to push to git.linuxtogo.org?
23:01.02NetRipperregister at projects.linuxtogo.org and check the mobile linux project
23:01.25NetRipperwhen you're logged in there's a link somewhere in that project on the right-hand side to request participation
23:02.24cr2maejrep[w]: this MPP is gpio -related
23:04.04NetRipperwhich kernel will you build against rolk ?
23:04.47*** join/#htc-linux kaze_ (n=kaze@ABordeaux-158-1-27-51.w90-55.abo.wanadoo.fr)
23:04.56rolkWell, obviously ltg-git. The missing function is from drivers/mcc/core in the android kernel.
23:06.41Mullinsnetripper: I've done that. Can you accept my request to join the project?
23:06.58NetRipperMullins, ph5 or Kevin2 need to do that, one of them receives the e-mail
23:07.06Mullinsnetripper, np, ty
23:07.24cr2rolk: sdio is .25+
23:08.12cr2maejrep[w]: your sd alt confirmed
23:09.19cr2maejrep[w]: where should i put the lcd init docs ?
23:10.24rolkcr2: What do you mean by .25+?
23:10.35cr2raph800 -> 9,1,a5a ; 3,1,708 ; 6,1,b22 ; i2c(cc,20,29,0)
23:10.51cr2rolk: 2.6.25+
23:12.17cr2raph800 -> and then 8,1,b22 ; a,1,a28
23:12.32cr2maejrep[w]: 5 voltages for lcd
23:14.43j0b0evening
23:14.53rolkcr2: its in the latest ltg / htc-vogue branch. But it lacks this function. I've added it, but all the include files where missing too. Tryingt to fix that.
23:15.17cr2rolk: which kernel version is that ?
23:16.19maejrep[w]cr2: sd alt?
23:16.52j0b0sdio_readb_ext is in linux/mmc/sdio_func.h
23:16.55cr2maejrep[w]:sdc3 pins on gpio
23:17.07maejrep[w]oh, how it differs from raph100?
23:17.36cr2maejrep[w]: MSM_SDIO wiki
23:17.44cr2hmm
23:17.55cr2raphael_gpio for that
23:18.49cr2do we have the code to query the toshiba gpio pins over mddi ?
23:19.08maejrep[w]no idea what that means ;o
23:19.23cr2ok :)
23:19.57cr2maejrep[w]: see above. you need 5 (!) pmic_level calls for your lcd
23:20.03j0b0cr2: would board-trout-panel.c have that
23:20.07rolkcr2: Its 2.6.25
23:20.24j0b0it has tables with registers and values to init mddi and panel
23:20.27cr2j0b0: it's probably somewhere in the drivers/video
23:20.32maejrep[w]cr2: all that just to turn on?  or off?  or both
23:20.41cr2maejrep[w]: both
23:20.46maejrep[w]odd that I didn't see all that in my traces :x
23:21.03j0b0trout-panel is like mddi_client_bleh but has more init code
23:21.04maejrep[w]do you have to change vreg level when turning off?
23:21.11cr2maejrep[w]: how many did you see ?
23:21.35cr2maejrep[w]: maybe they are set by oemsbl already
23:21.45maejrep[w]i saw 2 vreg_switch's when turning off.  then when turning on, I saw 2 vreg_level's and 2 vreg_switch's
23:21.52cr2j0b0: mddi_remote_read ?
23:22.35cr2maejrep[w]: ok. then maybe your spl is just overzealous
23:22.53j0b0i would think so. it has registers named GPIODATA GPIODIR GPIOSEL
23:23.50cr2j0b0: ok, i have the raph100 version already in wiki. on raph800/blac100 it's a bit more involved
23:24.10cr2but blac100 has only 2 lcds, while raph800 -> 6
23:24.41j0b0ive been putting some of that init code from trout into mddi-client-toshiba to see if it has any effect
23:25.18j0b0the mddi init code does nothing, the panel init code makes thepanel fade to black. device keeps running
23:28.22cr2j0b0: but getting the gpio state and calculating the panel ID is certainly non-destructive
23:28.52cr2maejrep[w]: so the vreg_level works now too ?
23:29.58j0b0cr2: i put the code in that processes the mddi init table and panel init table. the latter made it go black
23:30.51cr2ok
23:30.53j0b0but to get rig of the messed up colors on the raph800, would that take proper mddi init
23:34.27cr2j0b0: i see a lot of toshiba code too. maybe it's identical with the raph100 init, but one should check it
23:35.04j0b0how would one go at that
23:35.23j0b0i guess this code gets run at device init, a time when you can not run any tracing tools
23:37.14j0b0the mddi init table doing nothing might mean that it works as in configures what was already configured, otoh goios are generally different
23:37.37j0b0*gpios
23:41.51maejrep[w]cr2: it froze my phone when I tried it
23:44.27*** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo)
23:44.44tmzt17:23 < cr2> x67 is bt power
23:44.44tmzt17:23 < cr2> x65 bt reset
23:44.54tmztdoes this mean bt power is on microp?
23:46.01cr2maejrep[w]: ok
23:46.32cr2tmzt: no, these are the gpios. the same as on raph100. i've already added this data into raphael_gpio
23:48.27cr2tmzt: i'm looking for the g1 bt driver. where is it located ?
23:55.37cr2hmm. it seems that dzo has added the _fixup function to enable discontiguous memory
23:56.14cr2NetRipper: do oyu want to add the missing 128MB SDRAM ?
23:59.00j0b0how dangerous is that ;)

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