00:03.54 | *** join/#htc-linux WizRd (n=WizRd@ppp122-249-220.static.internode.on.net) |
00:09.33 | *** join/#htc-linux gh0ul (n=asds@host81-154-247-76.range81-154.btcentralplus.com) |
00:32.33 | maejrep | so any progress on getting a way to distinguish raph800 from raph100? will be necessary for things like the smd driver in order for raph800 to use channel 0 |
00:33.53 | *** join/#htc-linux WizRd (n=WizRd@ppp122-249-220.static.internode.on.net) |
00:33.56 | NetRipper | i think we'll need to compile seperate kernels |
00:34.23 | NetRipper | as in, do it with ifdefs |
00:34.52 | dcordes | there's the RAPHAEL-CDMA and DIAMOND-CDMA mach types |
00:34.55 | NetRipper | if someone makes itw ork for raph800, we can see what the impact of the change it.. we can then decide what to do |
00:35.08 | NetRipper | dcordes, they're already made? |
00:35.19 | dcordes | yea |
00:35.21 | NetRipper | ok |
00:35.56 | dcordes | hmm pand won't pair with my kaiser |
00:36.11 | *** part/#htc-linux n3tim (n=netim@201.82.18.39) |
00:39.37 | *** join/#htc-linux Zinbolic (n=zinbolic@0x57344a18.vgnxx3.dynamic.dsl.tele.dk) |
00:40.15 | maejrep | where are those machine types requested from? |
00:40.44 | dcordes | http://www.arm.linux.org.uk/developer/machines/ |
00:41.38 | maejrep | whats the "msm7201a" machine type? |
00:42.18 | *** join/#htc-linux cr2_ (n=cr2@ip-77-24-13-79.web.vodafone.de) |
00:43.45 | dcordes | there are also msm7200 msm7600 and htc_kaiser (duplicate) |
00:44.34 | NetRipper | they shouldnt exist |
00:45.02 | NetRipper | lol there are also corrections |
00:45.13 | NetRipper | corrections that break a kernel build |
00:45.17 | NetRipper | not ours |
00:45.18 | NetRipper | but still |
00:45.23 | NetRipper | -davinci_dm355_evm MACH_DAVINCI_DM350_EVM DAVINCI_DM350_EVM 1381 |
00:45.23 | NetRipper | +davinci_dm355_evm MACH_DAVINCI_DM355_EVM DAVINCI_DM355_EVM 1381 |
00:45.25 | NetRipper | like that |
00:45.28 | NetRipper | would break a kernel build |
00:49.41 | *** join/#htc-linux holycow (n=bite@S01060016b6b53675.vf.shawcable.net) |
00:56.26 | *** join/#htc-linux piusvelte (n=irchon@71.175.8.29) |
01:07.14 | *** join/#htc-linux divinebovine (n=bite@S01060016b6b53675.vf.shawcable.net) |
01:07.14 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
01:07.15 | *** join/#htc-linux maejrep (n=madcoder@c-71-225-238-170.hsd1.pa.comcast.net) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux exco (n=exco@e181117142.adsl.alicedsl.de) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux vizo (n=vizo@c-71-58-216-245.hsd1.nj.comcast.net) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux mustangsal66 (n=MustangS@pool-72-82-245-90.cmdnnj.fios.verizon.net) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux maejrep[w] (n=madCoder@smtp-n.myyearbook.com) [NETSPLIT VICTIM] |
01:07.16 | *** join/#htc-linux lupine_85 (n=lupine_8@work.lupine.me.uk) [NETSPLIT VICTIM] |
01:07.23 | maejrep | heh |
01:27.07 | *** join/#htc-linux zycho_ (n=zycho@a89-183-82-91.net-htp.de) |
01:28.43 | tmzt | msm7600? |
01:32.14 | maejrep | heh |
01:32.47 | maejrep | hmm, xda-devs down :/ |
01:33.16 | maejrep | <PROTECTED> |
01:33.18 | tmzt | NetRipper: why ifdef, won't if is_mach_ work? |
01:33.20 | maejrep | what does the 2= mean? |
01:34.59 | *** part/#htc-linux exco (n=exco@e181117142.adsl.alicedsl.de) |
01:40.33 | maejrep | cr2: there's already: struct smem_proc_comm |
01:51.28 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
01:59.27 | maejrep | Should we make the PCOM defines the same names? |
01:59.38 | maejrep | so that, e.g., vreg.c doesn't need to change |
02:00.43 | WizRd | join #linux |
02:00.46 | WizRd | shit |
02:04.36 | maejrep | actually, nevermind i guess they're different enough that it will need to change anyway |
02:07.28 | maejrep | but like PCOM_RESET_ARM9 (_wince) vs PCOM_RESET_MODEM (google) |
02:29.17 | *** join/#htc-linux br1ck_ (n=br1ck@xdslcy209.osnanet.de) |
02:30.50 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
03:18.32 | *** join/#htc-linux Moku (n=John@e179105249.adsl.alicedsl.de) |
03:26.35 | *** join/#htc-linux t3chi32 (n=blarg@ip24-250-216-85.ga.at.cox.net) |
03:52.03 | *** join/#htc-linux Mullins07 (n=bw@89.204.242.153) |
03:53.56 | *** join/#htc-linux Magicblaze007 (n=sony@fl-67-233-194-200.dhcp.embarqhsd.net) |
04:01.05 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
04:09.29 | Magicblaze007 | what linux does one run on htc phones? |
04:10.44 | tmzt | what phone? |
04:11.42 | Magicblaze007 | 8525 |
04:12.09 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
04:12.43 | Magicblaze007 | can one run android on 8525? |
04:13.45 | tmzt | not sure, linux runs on hermes but I don't know what the state of that is |
04:14.05 | tmzt | there is also some work on android for openmoko phones which use a similar cpu |
04:17.43 | Kevin2 | tmzt: Not sure what you mean by haret gpio mux. |
04:18.59 | tmzt | Kevin2: we only get one irq per bank of gpios, apparently the code in regsmsm.py to decode that is commented out |
04:19.34 | tmzt | enabling helps but cr2 said it's still broken and that's why it's commented out |
04:20.01 | tmzt | s/enabling/enabling it/ |
04:24.53 | Kevin2 | Hrmm. If I recall correctly, the irqs on msm require checking both that the gpio is setup as an irq and that the irq flag is pending. There isn't currently a way to do that in haret. |
04:26.39 | *** part/#htc-linux Magicblaze007 (n=sony@fl-67-233-194-200.dhcp.embarqhsd.net) |
04:26.40 | *** join/#htc-linux Zinbolic (n=zinbolic@0x57344a18.vgnxx3.dynamic.dsl.tele.dk) |
04:33.25 | parmaster | hrmm |
04:39.10 | *** join/#htc-linux woodson (n=CDP@c-76-101-90-149.hsd1.fl.comcast.net) |
04:41.09 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
05:08.51 | maejrep | Kevin2, that's right. what I did was setup stat0-stat5 with intr_en0-5, and just watch for both |
05:09.14 | maejrep | also added clr0-5 |
05:52.05 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
06:03.32 | *** join/#htc-linux imfloflo_ (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
06:04.00 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
06:09.20 | *** join/#htc-linux br1ck (n=br1ck@xdslcy209.osnanet.de) |
06:11.04 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87ee96.pool.einsundeins.de) |
06:16.21 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
06:21.27 | *** join/#htc-linux lpotter (n=ljp@58.173.176.153) |
06:29.34 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
06:33.41 | *** join/#htc-linux goxboxlive (n=goxboxli@mail2.hjellnesconsult.no) |
06:38.19 | *** join/#htc-linux _workkaze (n=kaze@ABordeaux-152-1-59-3.w82-125.abo.wanadoo.fr) |
06:40.54 | *** join/#htc-linux cr2 (n=cr2@ip-77-24-17-0.web.vodafone.de) |
06:41.12 | cr2 | maejrep: hi |
06:41.40 | cr2 | maejrep: have you found the gpio_func in vogue tree ? |
06:43.14 | maejrep | no |
06:43.37 | maejrep | is it in htc-epgio.c or something to that effect? |
06:43.44 | cr2 | no |
06:44.00 | cr2 | it's a gpio alt config |
06:44.03 | maejrep | was just looking at vogue's smd code trying to incorporate it in, and that's becoming difficult :) |
06:44.16 | cr2 | i'm looking myself |
06:44.19 | maejrep | any ideas where I might start? |
06:44.31 | maejrep | (looking for gpio alt func) |
06:44.36 | cr2 | not everything at once :) |
06:44.41 | cr2 | hmm. |
06:45.04 | cr2 | the raphael_gpio page has "alt" column |
06:45.40 | cr2 | there are 4 known alt states |
06:46.19 | cr2 | 1 is input, 2 is output, 3 is irq and 4 is ... |
06:46.59 | cr2 | linuxtogo git is slow |
06:49.03 | maejrep | I don't know that :x it'd be nice to know what everything on the wiki means :P |
06:49.53 | cr2 | yes, i'll try :) |
06:50.31 | cr2 | the gpio_func code in vogue tree needs a better name too |
06:59.04 | maejrep | can't seem to find it :/ |
07:01.19 | cr2 | like msm_gpio_alt_conf(gpionum,alt,level... |
07:01.40 | cr2 | strange, maybe it's renamed now ?? |
07:02.34 | maejrep | it has egpio code, but not sure if i've seen anything with alt func |
07:03.04 | cr2 | we don't need egpio |
07:03.51 | cr2 | it's about configuring the gpio itself for a certain function |
07:04.12 | maejrep | do we know what other functions are supported for each gpio? |
07:04.20 | cr2 | the g1 code does it through PCOM* macro |
07:04.28 | maejrep | ah |
07:04.36 | cr2 | yes, they are partly documented in the wiki |
07:05.01 | cr2 | SD, i2c, bt audio, CAM |
07:06.45 | maejrep | so (pardon my ignorance:) are the alt functions the same, just for each different gpio, or does one alt function on one gpio mean something different from that on another gpio? |
07:07.31 | cr2 | a gpio can have certain alternative functions |
07:07.44 | cr2 | not just input or output |
07:07.51 | cr2 | but being the SCL or SDA I2C lines, for example |
07:08.30 | cr2 | but you need a way to tell that the gpio 0x3d is a "normal" output gpio from now on |
07:09.16 | *** join/#htc-linux pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be) |
07:09.24 | cr2 | but if you need the SCL, you should tell msm that gpio 0x3d should use alt function 4 |
07:09.41 | maejrep | I see, and that would of course be implemented on the chip |
07:09.46 | cr2 | the pxa manual has a table for alt settings |
07:09.53 | cr2 | msm must have something similar |
07:10.00 | cr2 | yes |
07:10.13 | maejrep | yeah I ran across that earlier, but I wasn't sure if it was something standard, or something arbitrary that the chip would implement |
07:10.31 | cr2 | and a certain gpio may have only certain alt functions |
07:11.36 | maejrep | got it :) thanks! |
07:11.41 | maejrep | I'm kind of learning as I go here ;) |
07:12.02 | *** join/#htc-linux lavender-t (n=jerrey@c-24-17-204-47.hsd1.wa.comcast.net) |
07:12.03 | cr2 | an irq should be always alt=3, see the wiki |
07:12.29 | lavender-t | hello cr2 |
07:13.02 | maejrep | so you're looking for the way vogue sets that? |
07:13.17 | lavender-t | hi maejrep |
07:13.18 | maejrep | is it not the same thing as setting the output_enable or interrupt_enable bits? |
07:13.22 | maejrep | hi |
07:13.59 | cr2 | lavender-t: there was a gpio_func() in the vogue tree implementing the wince code |
07:14.07 | cr2 | but for the 5 banks only |
07:14.29 | lavender-t | i have a friend visiting this few days so wasnt tracking this for a while |
07:14.32 | cr2 | on A cpu it needs the sixth bank (and 3 more gpio in bank 5) |
07:14.41 | lavender-t | looks like the proc_comm is working now ? |
07:14.48 | maejrep | yes |
07:15.01 | cr2 | it needs some fixes though |
07:15.30 | lavender-t | i tried to get rid of the clock-7x00-alt code just now |
07:15.39 | lavender-t | my diamond went dark |
07:15.53 | maejrep | yeah, would be nice to make it not rely on both files like it does now |
07:16.49 | cr2 | arch-msm/gpio.c |
07:16.51 | lavender-t | so it was just the wince init issue, or still something wrong ? |
07:17.51 | cr2 | void gpio_func(int gpionum, int altfunc, int io, int level) |
07:17.53 | maejrep | proc_comm_wince works currently, I think it just needs some cleaning up, trying to match up macro/enum names, etc |
07:18.08 | maejrep | ah. i'm still waiting for the page to load ;/ |
07:18.24 | lavender-t | whew ... scared me a bit ... on the first reboot wince says no SIM card :( |
07:18.33 | cr2 | vogue branch, don't forget |
07:18.50 | lavender-t | reinserted SIM and battery ... ok now ... :) |
07:20.03 | maejrep | yeah |
07:20.18 | maejrep | if it didn't take minutes to load one page, it would be easier :P |
07:21.13 | lavender-t | great job, maejrep, btw |
07:22.43 | cr2 | androids use PCOM_GPIO_CFG instead |
07:22.53 | cr2 | which is not an option for us |
07:23.18 | maejrep | we're sure we can't use proc comm for that cr2? |
07:23.20 | cr2 | we are controlling the gpio directly without any proc_comm |
07:23.32 | cr2 | no, we can't |
07:23.47 | cr2 | there is no such function in our amss |
07:23.56 | maejrep | i see |
07:24.00 | cr2 | the same is for the clock control |
07:24.06 | maejrep | have a google cache link for that file or something? :| |
07:24.16 | cr2 | for the vregs we have proc_comm_wince :) |
07:25.11 | cr2 | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=tree;f=arch/arm/mach-msm;h=7f872bad935d592997cb0b88e8fe4d91336ccf36;hb=4115034fba750853375b0af1d1ef29470adbf831 |
07:25.52 | cr2 | the direct link |
07:26.12 | cr2 | http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=blob;f=arch/arm/mach-msm/gpio.c;h=9bf6972688c38f94a936187b81c8dd0c59301245;hb=4115034fba750853375b0af1d1ef29470adbf831 |
07:26.13 | maejrep | cool that'll save me about 5 minutes :D |
07:26.48 | lavender-t | i'm still loading the direct link :) |
07:26.51 | cr2 | so you need 4 params for each gpio |
07:27.19 | cr2 | androids have 5 for PCOM_GPIO_CFG |
07:27.30 | cr2 | i hate such obfuscation |
07:27.51 | cr2 | because the mapping between the both is non-obvious ;) |
07:28.09 | maejrep | PCOM_GPIO_CFG(gpio, func, dir, pull, drvstr) |
07:28.10 | lavender-t | cr2, last time you gave the MSM_CLK_CTL parameters |
07:28.25 | lavender-t | i still couldnt get them |
07:28.27 | maejrep | lavender-t, those parameters are documented now on the wiki |
07:28.33 | lavender-t | oh ok |
07:28.36 | cr2 | gpio and func are ok |
07:28.40 | maejrep | http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
07:28.46 | lavender-t | thanks. havent tracked for a while. |
07:28.54 | cr2 | but the rest is pita witout the cpu manual |
07:29.18 | maejrep | well, 'dir' is just setting output_enable, right? which can be done with gpio_configure |
07:29.32 | maejrep | gpio_direction_output() |
07:29.42 | cr2 | lavender-t: the formula is the same for all msm devices i've see |
07:30.04 | cr2 | lavender-t: you only need to check the "MMC" vreg |
07:31.02 | cr2 | maejrep: yes, it's included in gpio_func |
07:31.02 | *** join/#htc-linux Moku (n=John@f054170043.adsl.alicedsl.de) |
07:31.17 | cr2 | maejrep: and sometimes you need to control the arm9 gpiod |
07:31.35 | cr2 | which is also possible |
07:31.51 | cr2 | on our devices :) |
07:32.17 | cr2 | ok, i need to leave now |
07:34.41 | lavender-t | maejrep, did you calculated the values from those values ? |
07:35.00 | maejrep | not yet |
07:35.22 | lavender-t | then you got the raph800 mmc working ? |
07:35.27 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
07:36.04 | maejrep | all I did was reset to git head and it worked, so that means somewhere along the way while I was trying to fix it, I broke it |
07:36.15 | maejrep | works now though |
07:36.26 | maejrep | msm_sdccid is 3 for sure |
07:36.28 | lavender-t | last time i tried cr2's formula i didnt get the correct A4 value |
07:36.49 | maejrep | well it "just works" with what you converted from vogue |
07:36.58 | lavender-t | that's why i'm still confused. this wiki still shows the old numbers |
07:37.15 | maejrep | though i guess the goal is to allow it to support whatever clock speed it needs |
07:38.19 | lavender-t | yeah ... i hope so :) but anyways great job tracking all those registers, maejrep. |
07:38.35 | maejrep | what registers? :o |
07:39.01 | maejrep | I only converted the code from what I saw in haret during proc comm. the documentation was all cr2 :p |
07:39.03 | lavender-t | the proc_comm ones ? i saw a new file in git today and thought you added it |
07:39.27 | lavender-t | oh ok :) |
07:40.06 | lavender-t | still need a couple of days to stick with my friend ... |
07:40.27 | lavender-t | then i'll have some catch up work to do. things are progressing really fast after new year :) |
07:41.44 | maejrep | still having a hard time with the i2c keyboard driver :/ |
07:43.10 | lavender-t | yeah i thought that'd be painful. also the power stuff needs to be fixed. |
07:44.16 | lavender-t | alright gotta quit now. have fun maejrep. :) |
07:44.22 | maejrep | see ya |
07:45.08 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
07:47.00 | NetRipper | tmzt, which ifdef are you referring to? |
07:53.19 | maejrep | cr2: I added GPIOCFG1 and GPIOCFG2 to iomap.h and io.c |
07:53.38 | maejrep | will see if I can get vogue's func changes ported to work with that |
08:06.11 | *** join/#htc-linux pichurri (n=pichurri@users3.ilo.org) |
08:10.40 | maejrep | cr2, NetRipper: http://privatepaste.com/56EZPzICay |
08:11.06 | maejrep | adds gpio config to iomap, and adds gpio_set_function |
08:11.25 | maejrep | hmm, forgot the prototype in the header file though :p |
08:14.30 | maejrep | the extern needs to be added to include/asm-arm/arch-msm/gpio.h |
08:14.55 | maejrep | compiles, but haven't tested it yet (not sure how to test it heh :) |
08:16.03 | *** join/#htc-linux kilian_ (n=kilian@92.66.94.81) |
08:35.53 | *** join/#htc-linux daspsycho (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
08:43.34 | NetRipper | maejrep, test it with your keyboard gpio irq that is refusing? |
08:43.38 | NetRipper | or is that something else |
08:44.43 | NetRipper | maejrep, what does the alt function do? |
08:46.02 | NetRipper | and, wouldnt a second call for any other gpio clear the function for the first gpio? or is it read by some hardware and stored internally |
09:01.58 | *** join/#htc-linux OozZ (n=sbskalra@122.168.68.5) |
09:02.20 | lupine_85 | ho de hum, so the X calibration tools don't seem to work |
09:02.42 | lupine_85 | (but the vkeyb does actually work, it turns out) |
09:03.59 | lupine_85 | sometimes the X pointer shows up, sometimes not |
09:10.53 | *** join/#htc-linux anarsoul (n=anarsoul@212.98.167.157) |
09:12.23 | *** join/#htc-linux _7lima_ (n=7lima@88-134-28-199-dynip.superkabel.de) |
09:53.17 | *** join/#htc-linux Mullins (n=bw@89.204.228.129) |
10:00.47 | *** join/#htc-linux buster`- (n=buster@lostmind.org) |
10:02.40 | *** join/#htc-linux RZK333 (n=rzk@daemonet.ru) |
10:04.17 | *** join/#htc-linux daspsycho (n=Tim@HSI-KBW-082-212-005-059.hsi.kabelbw.de) |
10:20.03 | *** join/#htc-linux OozZ (n=sbskalra@122.168.68.5) |
10:41.08 | *** join/#htc-linux metter (n=metter@86-81.0-85.cust.bluewin.ch) |
10:45.11 | *** part/#htc-linux OozZ (n=sbskalra@122.168.68.5) |
10:47.10 | *** join/#htc-linux DJWillis (n=djwillis@82-46-19-72.cable.ubr02.bath.blueyonder.co.uk) |
10:57.47 | *** join/#htc-linux _4nakin (n=Tuan@115.76.129.133) |
11:00.06 | *** part/#htc-linux _4nakin (n=Tuan@115.76.129.133) |
11:27.52 | *** join/#htc-linux tsdogs (n=tsdogs@net70-17.metalit.net) |
11:34.42 | *** join/#htc-linux stefan_schmidt (n=stefan@c120.apm.etc.tu-bs.de) |
11:43.56 | *** join/#htc-linux stamppot (i=d4cb1b12@gateway/web/ajax/mibbit.com/x-0b2a972d183b0515) |
11:44.50 | *** join/#htc-linux kiozen_ (n=oeichler@rgnb-5d87ee96.pool.einsundeins.de) |
11:58.35 | *** join/#htc-linux yoyey (n=yoann@bro69-3-82-237-160-83.fbx.proxad.net) |
12:10.32 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
12:11.13 | cr2 | kiozen: answering to the bug report: osm-style :) |
12:11.19 | cr2 | kiozen: http://lists.openstreetmap.org/pipermail/talk/2009-January/033057.html |
12:20.45 | kiozen | cr2: journalist should write software... |
12:20.55 | kiozen | s/should/shouldn't/ |
12:30.33 | parmaster | cr2: do you pull data out of planet.osm and build waypoint information and tiles with it? |
12:34.42 | parmaster | i honestly was going to build the entire planet-osm to have locally |
12:44.18 | *** join/#htc-linux buster__ (n=buster@lostmind.org) |
12:45.47 | *** join/#htc-linux Shadowmite (n=zule@shadowmite.com) |
12:49.37 | *** join/#htc-linux parmaster (i=par@dipole.idlepattern.com) |
13:11.56 | *** join/#htc-linux piusvelte (n=chatzill@nat.philau.edu) |
13:28.14 | *** join/#htc-linux KeePette (n=chatzill@vit94-1-87-90-37-127.dsl.club-internet.fr) |
13:32.52 | *** join/#htc-linux StarLiteMobile (n=pocketir@91.141.186.110) |
13:33.57 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
13:49.55 | *** join/#htc-linux kimhoon (n=kimhoon@s559116c1.adsl.wanadoo.nl) |
14:06.42 | *** join/#htc-linux piusvelte (n=chatzill@nat.philau.edu) |
14:08.09 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
14:11.58 | *** join/#htc-linux addman3333 (n=skool@cpe-67-9-134-92.austin.res.rr.com) |
14:15.42 | *** join/#htc-linux Kensan_ (n=ken@gw.ptr-80-238-180-11.customer.ch.netstream.com) |
14:25.34 | maejrep | NetRipper, according to the vogue code, its an API. you store gpio first, then function in the next byte, and the chip automagically does stuff |
14:30.47 | lupine_85 | ooh, ruby |
14:30.50 | maejrep | but to answer your question, I'm not entirely sure what it does to be honest, nor how I would use it to test my stubborn irq :p |
14:34.03 | *** join/#htc-linux Guimli (n=guimli@ecu69-1-82-231-127-213.fbx.proxad.net) |
14:36.20 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
14:37.41 | *** join/#htc-linux nato2k (n=templarn@76.250.180.218) |
14:38.18 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87ee96.pool.einsundeins.de) |
14:44.21 | lama | anyone is working on android/linux for samsung i780? |
14:47.53 | *** join/#htc-linux RZK333 (n=rzk@daemonet.ru) |
15:00.39 | *** join/#htc-linux MethoS (n=clemens@host-091-097-243-084.ewe-ip-backbone.de) |
15:08.23 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
15:10.19 | *** join/#htc-linux radem205 (n=aaa@92-108-47-154.dynamic.upc.nl) |
15:21.49 | *** join/#htc-linux addman3333 (n=azachars@nat/sun/x-e1109da4cc3c583c) |
15:31.55 | NetRipper | maejrep couldn't you set your keyboard gpio and pass a function that is called? much like an irq |
15:32.40 | AstainHellbring | morning |
15:38.46 | NetRipper | it's weird how that api would work.. what thread would it originate from? how do you sync it with kernel code? |
15:40.50 | NetRipper | im gonna try out of curiousity |
15:40.57 | NetRipper | crash my machine |
15:41.00 | NetRipper | love to |
16:03.37 | *** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com) |
16:21.11 | maejrep[w] | it crashed? @_@ |
16:32.52 | NetRipper | no |
16:32.53 | NetRipper | dunno |
16:32.57 | NetRipper | im still at work |
16:32.58 | NetRipper | cant test |
16:36.07 | *** join/#htc-linux _4nakin (n=Tuan@115.76.135.239) |
16:37.41 | maejrep[w] | ah |
16:40.00 | maejrep[w] | not even fully sure how to test it ;x |
16:51.57 | *** join/#htc-linux imfloflo (n=imfloflo@cap31-6-88-180-73-121.fbx.proxad.net) |
16:55.23 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbf9217.pool.einsundeins.de) |
17:00.39 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
17:05.46 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
17:07.55 | *** join/#htc-linux Moku (n=John@f054170043.adsl.alicedsl.de) |
17:16.11 | *** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) |
17:17.00 | *** part/#htc-linux _4nakin (n=Tuan@115.76.135.239) |
17:19.03 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
17:19.10 | NetRipper | maejrep[w], isn't there any use of it in the vogue tree? |
17:20.00 | NetRipper | and |
17:20.03 | NetRipper | can any gpio be set as alt? |
17:20.20 | NetRipper | dinner, bbl |
17:20.23 | *** join/#htc-linux Rogro82 (n=rogro82@s5591104d.adsl.wanadoo.nl) |
17:24.46 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
17:33.47 | *** join/#htc-linux exco (n=exco@e181067115.adsl.alicedsl.de) |
17:36.06 | *** join/#htc-linux _7lima_ (n=7lima@88-134-28-199-dynip.superkabel.de) |
17:42.41 | *** join/#htc-linux ali1234 (n=al@robotfuzz.co.uk) |
17:42.56 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B03747C.dip.t-dialin.net) |
17:47.07 | maejrep[w] | as I understand it, each chip and each gpio on that chip can behave differently |
17:47.42 | maejrep[w] | so it wasn't that I don't know how to call the function - that's easy enough |
17:47.42 | maejrep[w] | it's that I don't know what to set a given gpio to, and how to verify the functionality |
17:50.01 | *** join/#htc-linux goxboxlive (n=goxboxli@24.84-48-212.nextgentel.com) |
17:50.54 | *** join/#htc-linux zule (n=zule@shadowmite.com) |
17:54.25 | *** join/#htc-linux dcordes (n=zsirc@ip-90-187-152-204.web.vodafone.de) |
17:54.54 | dcordes | hi |
17:55.26 | AstainHellbring | hi |
17:59.46 | *** join/#htc-linux Descention (n=munsco95@acm.pct.edu) [NETSPLIT VICTIM] |
17:59.46 | *** join/#htc-linux Dinde (n=kayser@81-65-176-209.rev.numericable.fr) [NETSPLIT VICTIM] |
17:59.46 | *** join/#htc-linux Funklord (n=cow@c-ecd572d5.014-46-73746f28.cust.bredbandsbolaget.se) [NETSPLIT VICTIM] |
17:59.46 | *** join/#htc-linux swetland (n=swetland@nat/google/x-ac2328226c12fbc1) [NETSPLIT VICTIM] |
18:00.43 | *** join/#htc-linux swetland_ (n=swetland@nat/google/x-b29ee9e9507c4ee8) |
18:00.46 | *** join/#htc-linux Funklord (n=cow@c-ecd572d5.014-46-73746f28.cust.bredbandsbolaget.se) [NETSPLIT VICTIM] |
18:00.46 | *** join/#htc-linux Descention (n=munsco95@72.20.218.20) [NETSPLIT VICTIM] |
18:00.46 | *** join/#htc-linux Dinde (i=kayser@sur-internet.net) [NETSPLIT VICTIM] |
18:01.03 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
18:05.33 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
18:17.38 | *** join/#htc-linux goxboxlive_ (n=goxboxli@24.84-48-212.nextgentel.com) |
18:22.24 | *** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) |
18:27.25 | Zoolooc | hi |
18:30.37 | NetRipper | maejrep[w], do you already have CDMA-specific material? |
18:48.13 | *** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) |
18:57.12 | radem205 | hey |
18:59.28 | maejrep[w] | NetRipper: yes |
19:01.42 | maejrep[w] | e.g., I set the default sdcc id based on if _CDMA is set. I set the sd card slot based on _CDMA |
19:01.49 | maejrep[w] | (sd card detect gpio) |
19:02.21 | maejrep[w] | and I'm planning to gut smd.c to do the same ;) |
19:04.39 | *** join/#htc-linux ali1234 (n=al@robotfuzz.co.uk) |
19:06.07 | tmzt | NetRipper: no #ifdef, but a runtime check of is_mach_raphael_cdma() |
19:06.43 | tmzt | NetRipper: you don't want to use #ifdef because that will only allow you to build the kernel for one device (you can use #ifdef to disable code that is not going to be used though) |
19:07.47 | tmzt | maejrep[w]: there is a new documentation file the kernel you should read or you can read it on the linux-arm-kernel list |
19:08.20 | maejrep[w] | which file? |
19:08.32 | maejrep[w] | also, i had a strange issue using machine_is_htcraphael_cdma() |
19:08.46 | maejrep[w] | was getting an error that the function is undefined, but the macro was being defined |
19:08.52 | tmzt | the new headers document, probably Documentation/arm/ something but it might not be in there yet (maybe 2.6.29-rc1) |
19:08.53 | maejrep[w] | what should I need to do to use that at runtime? |
19:08.56 | NetRipper | you need to include a file |
19:09.03 | maejrep[w] | oh :/ |
19:09.06 | NetRipper | sec |
19:09.08 | tmzt | it says what to put in those files and what not to put |
19:09.09 | maejrep[w] | mach-types.h ? |
19:09.16 | maejrep[w] | in what files tmzt ? |
19:09.54 | cr2 | hi |
19:10.18 | cr2 | i have many new notes, but need to go home |
19:10.18 | cr2 | bbl |
19:11.24 | *** join/#htc-linux Czarnas (n=czarnas@imik.wip.pw.edu.pl) |
19:12.35 | tmzt | http://thread.gmane.org/gmane.linux.ports.arm.kernel/50723 |
19:26.12 | *** join/#htc-linux nebi (n=nebi@170.ftth2.cust.fyrobs1.upps.se.borderlight.net) |
19:30.08 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
19:41.26 | *** join/#htc-linux _7lima (n=7lima@88-134-28-199-dynip.superkabel.de) |
19:42.41 | *** join/#htc-linux stefan_schmidt (n=stefan@p5B037F14.dip.t-dialin.net) |
19:44.11 | NetRipper | tmzt, im aware of that machine_is advantage |
19:44.42 | NetRipper | maejrep[w], yes include/mach-list.h i believe, check the board-htcraphael-keypad.c, it alerady works with machine_is_htcraphael() |
19:45.26 | *** join/#htc-linux Sleep_Walker (n=Sleep@nat/suse/x-56e0eb285f80cd62) |
19:46.18 | NetRipper | maejrep[w], about all those proc_comm #ifdef's.. where you #ifdef for TROUT.. perhaps we should add a Kconfig option that allows you to enable "proc_comm for wince" with a CONFIG_PROC_COMM_WINCE option or something.. i think that'll be nicer.. what do you think? |
19:46.41 | NetRipper | anyway i gtg to training, bbl |
19:47.19 | Sleep_Walker | BabelO: hi, I've heard that you've got somewhere compiled Qtopia rootfs for XScale PXA27x |
19:47.40 | Sleep_Walker | could you give me a link, please? |
19:48.51 | BabelO | Sleep_Walker: look here http://www.linuxtogo.org/~htcpxa/htcblueangel/Qtopia/ but it is 4.3 |
19:50.32 | Sleep_Walker | BabelO: thanks, I'll have a look |
19:50.59 | BabelO | Sleep_Walker: i ve a 4.4 version somewhere .. but not functionnal |
19:51.15 | Sleep_Walker | I preffer working versions :) |
19:51.47 | BabelO | Sleep_Walker: else you can try http://www.linuxtogo.org/~htcpxa/htcartemis/qtopia/ |
19:52.10 | BabelO | it is the same with some tips for non gsm modem use and some new software are in |
19:52.26 | BabelO | i use it on omap850 and pxa263 works well on both |
19:52.52 | BabelO | Sleep_Walker: on the second you have qlandkarte M :) |
19:53.18 | Sleep_Walker | I'm looking mainly for phone application |
19:53.40 | BabelO | Sleep_Walker: ok the took the htcblueangel version, it works with the ti calypso tips |
19:54.35 | Sleep_Walker | is this channel somehow related to xda-developers.com? |
19:55.01 | BabelO | yes |
19:55.18 | Sleep_Walker | I'm proud user of Treo680 and I'd like to solve suspend/resume support for that |
19:55.52 | Sleep_Walker | I heard that it has similar bootloader as HTC |
19:56.01 | Sleep_Walker | (or I read it on xda-developers?) |
19:56.25 | BabelO | ok, what happen with your suspend / resume ? not wokrking at all ? |
19:57.06 | Sleep_Walker | I'm not sure exactly |
19:57.18 | Sleep_Walker | I think I don't push return address in correct way |
19:57.28 | Sleep_Walker | (or to right address) |
19:57.33 | BabelO | ok |
19:57.44 | Sleep_Walker | I tried it similarly to Treo650, but that was bad way |
19:57.47 | BabelO | you have sample code in htcblueangel_suspend if you want to look |
19:58.10 | Sleep_Walker | great, that is well probably that what I want... thank you again |
20:04.06 | *** join/#htc-linux t3chi3 (n=blarg@ip24-250-216-85.ga.at.cox.net) |
20:04.23 | *** join/#htc-linux tsdogs (n=tsdogs@net203-187-146.mclink.it) |
20:37.03 | *** join/#htc-linux cr2 (n=cr2@ip-77-25-180-219.web.vodafone.de) |
20:37.30 | BabelO | oh oh look like new cr2 connection :) |
20:38.52 | cr2 | hi BabelO |
20:38.59 | BabelO | hi cr2 |
20:39.12 | cr2 | BabelO: nc10, but not yet with linux |
20:39.49 | BabelO | cr2 ok :), don't tell me you have installed cygwin on it too |
20:39.55 | cr2 | NetRipper: i've found an error in my SD formula |
20:40.22 | cr2 | BabelO: hehe. after 3 failed downloads i gave up ;) |
20:40.30 | cr2 | 500MB in 2 hours |
20:40.45 | cr2 | BabelO: but ssh works :) |
20:41.00 | BabelO | :) |
20:41.09 | cr2 | kiozen has installed GT on it |
20:41.17 | cr2 | the big master himself :) |
20:41.41 | BabelO | cr2: yes i t works well on notebook, i have it on mine, but under linux |
20:41.46 | BabelO | just some window are wrong |
20:42.08 | cr2 | the umts modem on nc10 is not bad. 300KB/s is not a problem |
20:43.16 | BabelO | i have tried tv on the eeepc with a 3G+ connection |
20:43.25 | cr2 | iptv ? |
20:43.34 | BabelO | 7.2Mb/s it display |
20:43.44 | cr2 | yes |
20:43.46 | BabelO | yes orange tv on ip |
20:44.13 | BabelO | do you see all new feature in GT ? |
20:44.32 | cr2 | kiozen has shown me |
20:44.51 | cr2 | well, we need route planning now :) |
20:45.30 | cr2 | maejrep[w] : w or not w ? |
20:45.37 | BabelO | cr2: yes but need decoding before |
20:46.03 | cr2 | BabelO: if they can encode, we can decode |
20:46.19 | maejrep[w] | I'm at w |
20:46.25 | BabelO | cr2: do you know where to look for kernel page error ? i try to access a memory adress on the omap, close to the omap_100k |
20:46.40 | BabelO | cr2: yes but it is java, i already spent time to read perl , lol |
20:46.50 | cr2 | maejrep[w]: i've gathered a lot of useful data about vreg |
20:47.06 | cr2 | BabelO: lol |
20:47.15 | maejrep[w] | <PROTECTED> |
20:47.32 | cr2 | maejrep[w]: and fixed the clock formula |
20:47.33 | maejrep[w] | nice |
20:47.37 | maejrep[w] | does it work now? :P |
20:48.05 | maejrep[w] | lavender said last time he tried it, he wasn't able to get to the correct A4 value using the formula |
20:48.08 | cr2 | don't know, the mmc/sd vreg is needed too |
20:48.13 | maejrep[w] | ah |
20:48.32 | maejrep[w] | that changes with the clock? |
20:48.46 | cr2 | yes, i've added a wrong bitshift in the text i put into the channel |
20:48.55 | cr2 | now the formula looks much better |
20:49.01 | maejrep[w] | ah ok |
20:49.04 | maejrep[w] | cool |
20:49.22 | cr2 | no, it poweres up the sd controller internally |
20:49.29 | maejrep[w] | and re the alt function patch - what's a good way to test that (what gpio, what func number, and how to confirm)? |
20:49.41 | maejrep[w] | did you see my patch? |
20:49.44 | cr2 | and many vregs have not only 0/1 switch but the voltage too |
20:50.05 | cr2 | and raph500&800 have a different vreg set from raph100/bstone |
20:50.17 | maejrep[w] | interesting |
20:50.31 | cr2 | maejrep[w]: yes. i suggest to use 4 param call as in wince |
20:50.32 | maejrep[w] | not really.. its kind of a pain in the ass :) |
20:50.45 | maejrep[w] | wince does 4 params? |
20:50.55 | cr2 | and to wrap the ops in disable irq/ enable irq |
20:51.06 | cr2 | yes. oe+level |
20:51.17 | cr2 | like it's in the vogue kernel |
20:51.20 | maejrep[w] | why wouldn't you use gpio_direction_output() for that? |
20:51.33 | cr2 | which is just an implementation of what wnce does |
20:51.36 | maejrep[w] | that was the only reason I left those 2 out, because they could already be done using existing functions |
20:51.59 | cr2 | you can, but it's bbetter to avoid potential race conditions |
20:52.13 | maejrep[w] | ok |
20:52.15 | cr2 | i think wince does it for a reason |
20:52.35 | maejrep[w] | so I'll fix that when I get home |
20:52.35 | maejrep[w] | how about testing it? |
20:52.50 | cr2 | it should be used by the drivers |
20:53.18 | cr2 | and we may want to ov erride the PCOM_GPIO_CFG for amss_wince |
20:53.49 | maejrep[w] | that makes sense.. but we don't know how we can implement the 5th parameter, right? |
20:53.52 | cr2 | all in one, you'd be careful with 500/800 vs 100 |
20:54.02 | cr2 | we may fry some things :) |
20:54.06 | maejrep[w] | @_@ |
20:54.31 | cr2 | i see 26 vregs in the microkernel |
20:54.52 | cr2 | bstone implements 15 |
20:55.05 | cr2 | raph100 - > 14 |
20:55.37 | cr2 | 500/800 -> 9 |
20:55.44 | cr2 | but they have 1 extra |
20:55.50 | cr2 | SYNT |
20:56.02 | cr2 | which raph100/bstone does not use |
20:56.16 | cr2 | titan has even 2 less |
20:56.35 | cr2 | then there is a cut'npaste firmnware bug :) |
20:56.46 | cr2 | which always confused me |
20:57.05 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
20:57.27 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
20:57.46 | cr2 | so the main problem for me now is to match the proc-comm-wince masks with the names |
20:57.58 | cr2 | g1 has 32 vregs, btw |
20:58.10 | cr2 | don't know how much do they really use |
20:58.42 | cr2 | and i have also found the full msm clk list in an older android kernel version |
20:59.03 | cr2 | the namelist |
20:59.21 | cr2 | so it's also necessary to match the bits and regs with names |
20:59.26 | cr2 | for the clocks |
20:59.37 | cr2 | but we already know many of them |
21:01.04 | maejrep[w] | they had a cut/paste bug in their firmware? |
21:01.16 | cr2 | in the debug messages |
21:01.21 | maejrep[w] | ah |
21:01.43 | maejrep[w] | sounds complicated :) |
21:01.51 | cr2 | they added a vibra control, but it still has the name 'wlan' :) |
21:02.30 | *** join/#htc-linux rolk (n=rolk@ip5457417f.direct-adsl.nl) |
21:02.39 | maejrep[w] | ah |
21:02.54 | cr2 | looks like a copy of the previous table entry, only with the id number changed |
21:03.04 | cr2 | but preserving the description |
21:03.23 | cr2 | so it works as expected |
21:03.42 | cr2 | but will produce weird debug messages if something goes wrong |
21:03.56 | cr2 | as if wlan failed ;) |
21:04.06 | cr2 | when it's only the vibra control |
21:04.32 | cr2 | ok, i'll try to edit the wiki |
21:06.44 | *** join/#htc-linux _7lima_ (n=7lima@88-134-28-199-dynip.superkabel.de) |
21:09.49 | kiozen | <cr2> the big master himself :) |
21:09.50 | kiozen | lol |
21:10.04 | kiozen | that was win32 install, not even work |
21:14.25 | *** join/#htc-linux tekkdrone (n=none@72.183.115.231) |
21:15.00 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
21:15.35 | *** join/#htc-linux tekkdrone (n=none@72.183.115.231) |
21:18.33 | *** join/#htc-linux lupine_85 (n=lupine@forest.lupine.me.uk) |
21:20.22 | lupine_85 | curses, I have a lack of backscroll |
21:23.01 | lupine_85 | at least logs work *now* |
21:24.28 | cr2 | maejrep[w]: does it look ok ? http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
21:25.44 | maejrep[w] | (x=slot) is good info ;D |
21:26.39 | maejrep[w] | yeah that's uber helpful :) |
21:26.41 | maejrep[w] | thanks cr2 |
21:27.15 | maejrep[w] | so we would replace the clk_setrate function to use that formula, instead of looping over the existing array of values? |
21:27.19 | cr2 | maejrep[w]: the irq page uses sd1_0 and sd1_1 ? |
21:27.33 | maejrep[w] | sdc1_0 |
21:27.41 | maejrep[w] | (1-based, not 0-based, which sd# implies) |
21:28.14 | cr2 | maejrep[w]: ok then we need to sync other pages to use unified naming schema |
21:28.25 | maejrep[w] | ok |
21:28.33 | cr2 | the sdio should start at 144kHz |
21:28.37 | maejrep[w] | I've just been using SD0 & SDC1 to mean the same thing :p |
21:28.58 | maejrep[w] | but I can switch that to SDC1-4 wherever I used SDx |
21:29.04 | cr2 | detect the card type and capabilities and then switch to a higher frequency (if possible/available) |
21:29.16 | cr2 | but imho it's the mmc/sdio subsystem job |
21:29.27 | maejrep[w] | so just keep going higher until its at its highest, or card reports it can't handle it? |
21:29.34 | cr2 | sdc1_0 is from g1 source |
21:30.03 | maejrep[w] | using the SDC numbers is easier imho |
21:30.04 | cr2 | does the sdcc driver support 48 MHz for SD 2.0 ? |
21:30.13 | maejrep[w] | I think so |
21:30.25 | cr2 | i think it's all spec'd, we have no playing ground here |
21:30.42 | cr2 | the SD protocol |
21:31.02 | cr2 | or it should be in theory ;) |
21:31.16 | cr2 | an mmc card should be capable of up to 19MHz |
21:31.21 | cr2 | sorry |
21:31.25 | cr2 | 20 MHz |
21:31.38 | cr2 | the SD -> 25MHz afair |
21:31.55 | cr2 | 50MHz must be some SD2.0 spec |
21:32.01 | cr2 | which i've not read :) |
21:32.20 | maejrep[w] | I saw a comment in trout code about their phone not being able to handle the max for their wifi chip |
21:32.49 | maejrep[w] | but i think that was 20MHz vs 24MHz (or so) |
21:33.00 | cr2 | hmm, maybe i'd check the wince sd driver later |
21:33.12 | cr2 | how they treat SD 2.0 and 48MHz clock |
21:33.37 | cr2 | 19=20 and 24=25 and 48=50 |
21:33.56 | cr2 | but i think wince uses 12MHz for mmc csar |
21:34.10 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
21:34.19 | cr2 | while 19 should not be a problem |
21:34.53 | cr2 | but i've never seen microMMC cards anyway ;-) |
21:36.49 | maejrep[w] | I don't even know the difference :) |
21:37.14 | maejrep[w] | mmc, sd, sdio, sdhc, :p |
21:39.16 | cr2 | ok, it's not important for now |
21:39.35 | cr2 | even the androids can't get it right ;-) |
21:40.51 | maejrep[w] | lol |
21:42.36 | maejrep[w] | so would there be any use in the gpio_func stuff to reset my rogue irq? :x the line is high coming out of windows, when I press a key it's pulled low to trigger the interrupt, but doesn't go high again. In windows, it goes high at the same time the status bit is reset to 0, but not in linux |
21:42.54 | maejrep[w] | or something else silly that I'm doing wrong? |
21:43.29 | maejrep[w] | it's almost like returning IRQ_HANDLED is making it pull the line low, even though the irq is supposed to be active low, so resetting should bring it high |
21:47.24 | lupine_85 | feels git break his head of |
21:47.25 | lupine_85 | ...f |
21:47.27 | lupine_85 | <PROTECTED> |
21:47.32 | lupine_85 | (goes fine) |
21:47.43 | lupine_85 | autobuilder@forest:~/builds/kernel$ git checkout -b htc-msm-2.6.25 origin/htc-msm-2.6.25 |
21:47.46 | lupine_85 | git checkout: branch htc-msm-2.6.25 already exists |
21:49.04 | maejrep[w] | did you already check it out from that git repo? |
21:49.26 | lupine_85 | on a different PC, yes |
21:49.29 | lupine_85 | this is a clean tree |
21:50.11 | lupine_85 | but git checkout htc-msm-2.6.25 seems to have worked |
21:50.11 | maejrep[w] | omg, the raphaellinux page on the wiki has really changed :x |
21:50.42 | lupine_85 | I quite like the Android 1.0 status table |
21:50.51 | *** join/#htc-linux camden (n=camden@ancnat2.apto.aptalaska.net) |
21:51.44 | StarLite | url? :) |
21:53.28 | lupine_85 | on the RaphaelLinux page.... |
21:53.41 | lupine_85 | maejrep[w]: is your IRQ problem keyboard-related, or...? |
21:54.19 | StarLite | ah :D |
21:54.21 | StarLite | just found that |
21:54.34 | StarLite | the raphael linux also count for the X1? |
21:54.41 | cr2 | maejrep[w]: its a good idea to configure the irq gpio as alt=3 as in wiki |
21:54.43 | StarLite | and all phones based on the same chipset/cpu? |
21:55.17 | cr2 | maejrep[w]: then there is some config option about broken MSM irqs |
21:55.54 | cr2 | #if MSM_GPIO_BROKEN_INT_CLEAR |
21:56.45 | lupine_85 | the two phones have a lot of similarities IIRC? |
21:56.56 | lupine_85 | every little helps, anyway ;) |
21:58.43 | *** join/#htc-linux Xime (n=xime@bankize.net) |
22:00.12 | cr2 | maejrep[w]: some more good news |
22:00.50 | cr2 | maejrep[w]: wifi vreg does not use voltage adjust in wince |
22:01.09 | cr2 | wifi related vregs |
22:05.27 | *** join/#htc-linux Mullins07 (n=bw@89.204.224.66) |
22:13.50 | lupine_85 | woo :) - http://forest.lupine.me.uk/gitweb/ |
22:13.55 | lupine_85 | (OK, so not such an accomplishment |
22:21.33 | maejrep[w] | cr2: which means what? all we have to do is turn on the switch and that's it? |
22:22.19 | maejrep[w] | cr2: and re the irq, you're saying a normal gpio that i configured with MSM_GPIOF_ENABLE_INTERRUPT could be behaving differently from a gpio that is configured for alt func 3? |
22:23.36 | maejrep[w] | lupine_85: yes, it is the keyboard irq |
22:24.15 | maejrep[w] | in windows, the irq is "active low", which means its normally high (1), and when you press a key, it goes to 0, the driver reads from i2c, then the line goes high again |
22:24.37 | maejrep[w] | in linux, it goes from 1 to 0 the first time I press a key after booting linux, then never goes high again, so it never triggers the irq again |
22:25.27 | lupine_85 | maejrep[w]: do we have the init code for ksc in linux? |
22:25.51 | lupine_85 | (i've not been keeping track) |
22:26.09 | cr2 | maejrep[w]: you may hope that wince configured it, but the driver should do it too (alt=3) |
22:26.22 | cr2 | maejrep[w]: http://wiki.xda-developers.com/index.php?pagename=MSM_VREG |
22:27.08 | cr2 | maejrep[w] |
22:27.52 | cr2 | maejrep[w]: i don't know how g1 manages that, but wince configures all irq gpios as alt=3 in advance, check the wiki |
22:28.32 | cr2 | maejrep[w]: the MSM_VREG page has 15 (actually 14) vregs |
22:28.46 | maejrep[w] | oh I didn't know that |
22:28.51 | cr2 | maejrep[w]: the microkernel can handle 26 |
22:28.58 | maejrep[w] | is there a way to query current alt func config for a gpio? |
22:29.00 | cr2 | and g1 lists 32 |
22:29.15 | cr2 | it's not known to me :) |
22:29.22 | cr2 | i think no |
22:29.48 | cr2 | because wince alsways calls this 4 param gpio_cfg function |
22:29.51 | maejrep[w] | so the implementation is kind of odd, as NetRipper noted |
22:30.13 | cr2 | well, tell that to qcom |
22:30.17 | maejrep[w] | haha |
22:30.32 | cr2 | :) |
22:30.43 | maejrep[w] | seems the modem listens for setting the gpio number, then listens for the next byte setting the alt func |
22:30.58 | maejrep[w] | rather than using an A2M interrupt like proc comm |
22:31.03 | maejrep[w] | seems inefficient |
22:31.22 | cr2 | maejrep[w]: we need to find a way to correlate the MSM_VREG entries with your dex masks... and g1 names too |
22:31.27 | maejrep[w] | but be that as it may, it seems we might be able to query for current func by just writing gpio number to the first reg, and then checking value of the 2nd? |
22:31.59 | maejrep[w] | well, they're functionally different |
22:32.06 | cr2 | wince never does such things |
22:32.24 | maejrep[w] | was just curious if it would work that way .. would have to test it |
22:32.42 | maejrep[w] | but re vreg: g1 has a "VREG_SWITCH" that takes a data enable/disable parameter |
22:32.50 | cr2 | hmm, but we only have proc_comm_wince aka dex for vreg |
22:33.12 | cr2 | not available in wnce amss |
22:33.12 | maejrep[w] | where our proc comm uses VREG_ON, plus a vreg mask, and a separate VREG_OFF |
22:33.21 | maejrep[w] | so it's not really that easy to correlate them |
22:33.42 | cr2 | there is no other way to implement it |
22:34.00 | maejrep[w] | other than what? |
22:34.06 | maejrep[w] | ifdef's in proc_comm? |
22:34.11 | cr2 | so it'll be necessaery to disassemble the microkernel |
22:34.16 | maejrep[w] | D: |
22:34.22 | maejrep[w] | I'll let you do that =) |
22:34.54 | cr2 | which is a big task, because it's so huge and has 14 ELF sections or so |
22:34.55 | maejrep[w] | the extent of my asm knowledge is "register", "mov", "add"... that's about it :) |
22:35.06 | cr2 | :) |
22:35.21 | cr2 | the oemsbl may be easier |
22:35.45 | cr2 | but i don't know how to relocate it properly on load |
22:36.07 | cr2 | my knowledge of qcom internals is limited too |
22:36.13 | maejrep[w] | i dont think i was able to enter the oemsbl |
22:36.34 | cr2 | and our blackhat friends are not that verbose ;) |
22:36.51 | cr2 | entering is not necessary |
22:36.57 | maejrep[w] | I entered the main bootloader, and was able to get to the radio bootloader with rtask a, but afaik I'm supposed to get more commands, like "get gpio", etc, to dump the gpio config |
22:37.12 | cr2 | i only need the segment relocation info |
22:37.15 | maejrep[w] | but I can't use any of those gpio commands, even though I can see the dump strings in the spl |
22:37.36 | cr2 | spl=appsbl in qcom-speak |
22:37.37 | maejrep[w] | why do you need to disassemble it again? |
22:38.02 | cr2 | the oemsbl sets the arm9 & initial stuff |
22:38.26 | cr2 | to see the arm9 side of proc_comm/dex |
22:38.57 | maejrep[w] | ah |
22:39.02 | cr2 | how it decodes your proc_comm commands and what hw ops it performs |
22:39.23 | cr2 | actually i'd like to have the g1 oemsbl too :) |
22:39.41 | cr2 | but nobody has the brains to provide it, it seems ;) |
22:40.16 | cr2 | then it will be possible to compare the proc_comm implementations directly |
22:42.08 | cr2 | we know where the oemsbl located in sram |
22:42.39 | cr2 | becasuse on titan it was not shadowed away, and it was possible to dump it with haret directly |
22:43.35 | maejrep[w] | can we just dump the address from the bootloader? or is that already too far into it? |
22:44.15 | cr2 | never tried it |
22:45.02 | cr2 | the spl is not more capable than haret, i think |
22:45.18 | maejrep[w] | but if it's shadowed, it could matter where that happens |
22:47.07 | cr2 | i have used some 'reasonable' relocation, and could disassemble 80% |
22:47.28 | cr2 | but a lot of references are still broken |
22:47.42 | cr2 | and a lot of junk thumb dumps are created |
22:59.12 | *** join/#htc-linux t3chi3 (n=blarg@ip24-250-216-85.ga.at.cox.net) |
23:00.11 | maejrep[w] | cr2: in http://wiki.xda-developers.com/index.php?pagename=RaphaelDEX what does "2=0x22" mean, under cmd? |
23:01.14 | cr2 | 2= means that there are 2 params |
23:01.42 | cr2 | so it uses a different struct to transfer them |
23:02.23 | cr2 | hmm, probably i should look and describe the parameter layout and structs |
23:03.39 | cr2 | it's interesting that g1 does not slow down the SDRAM in sleep through SDRAM_CTL |
23:03.47 | cr2 | while wince can do it |
23:04.59 | cr2 | and there is one big black area we never talk about : rpc |
23:05.12 | cr2 | afair it's needed for sound |
23:05.23 | tmzt | cr2: ONRPC.dll ? |
23:07.11 | cr2 | maybe |
23:07.48 | maejrep[w] | bbiab, setting up new workstation |
23:10.17 | tmzt | I need to go to class and haven't got a chance to read the history here, but I'll be back later |
23:15.12 | camden | hi guys. do you think that installing hardSPL and flashing a new ROM will block me from installing android to the bare metal in the future? |
23:23.14 | *** join/#htc-linux Loki657 (n=Loki657@82.147.51.146) |
23:23.41 | Untouchab1e | Jobo, you there? |
23:24.54 | j0b0 | only just .. |
23:25.05 | Untouchab1e | ah, cool |
23:25.13 | Untouchab1e | thanks loads for the package you sent |
23:48.56 | *** join/#htc-linux silven (n=zmc@64.209.10.12) |
23:49.31 | silven | Anyone have any experience with the processor ID detection code for arm-linux? |
23:56.23 | *** join/#htc-linux aaaaacccccc (n=acsvilup@151.67.31.27) |