| 00:01.09 | dcordes_ | tmzt: do you know how the camera works in android? |
| 00:01.45 | tmzt | only that it renders directly through some dsp |
| 00:02.12 | tmzt | using a closed library from htc, and is implemented as a CameraView in android |
| 00:03.30 | dcordes_ | do you think we can reproduce this for use with normal distros? |
| 00:04.27 | cr2 | tmzt: is it possible to get these binaries ? |
| 00:04.53 | tmzt | only from a g1, google can't distribute them themselves |
| 00:05.32 | tmzt | why can't we use a v4l driver for this? |
| 00:05.42 | cr2 | tmzt: ok. where does android git pick them ? |
| 00:06.01 | tmzt | from a g1 copied with adb |
| 00:06.18 | cr2 | ok |
| 00:08.19 | cr2 | haha |
| 00:08.32 | cr2 | it seems that the epson chip does not have spi |
| 00:08.53 | cr2 | so it uses the microP to send spi data to LCD |
| 00:09.08 | cr2 | probably the toshiba was too expensive |
| 00:09.46 | cr2 | always buy the zero day hw from htc :) |
| 00:10.18 | tmzt | who was going to look at the microp fw? |
| 00:10.37 | cr2 | atmel has spi |
| 00:11.10 | cr2 | but the way how they do it is strange |
| 00:11.45 | cr2 | send i2c command to microP, so microP resends it over spi. |
| 00:11.52 | cr2 | at least it's my impresssion |
| 00:11.55 | dcordes_ | cr2: "you should do some i2c tracing. the cc,12,* looks different" <- how can I do that? |
| 00:12.16 | cr2 | mmutrace on the i2c read and write regs |
| 00:12.36 | *** join/#htc-linux gundam (n=gundam@slackware.it/staff/gundam) |
| 00:13.35 | dcordes_ | the oney from raphael memory map? or determine where kosvsky i2c regs are first? |
| 00:14.39 | cr2 | it's the same cpu |
| 00:16.21 | dcordes_ | ok |
| 00:17.25 | dcordes_ | http://wiki.xda-developers.com/index.php?pagename=RaphaelMemoryMapPg3 3 pages? |
| 00:18.03 | NetRipper | dcordes_, if one page gets too large, errors occur and the page will be blank... limit is 65k or something |
| 00:18.09 | NetRipper | dunno exactly |
| 00:18.44 | dcordes_ | oh |
| 00:20.12 | dcordes_ | wow kovsky keyboard looks awesome in the dark |
| 00:20.32 | cr2 | maejrep disapperared |
| 00:20.53 | dcordes_ | addlist mmutrace 0xa9900000 ... ? |
| 00:21.05 | cr2 | 4 at the end |
| 00:21.23 | cr2 | addlist mmutrace 0xa9900000 4 |
| 00:21.35 | dcordes_ | ok. shows nothing on wirq and keypress |
| 00:21.56 | cr2 | virtual |
| 00:22.01 | cr2 | p2v() |
| 00:22.23 | NetRipper | man im on the verge of cancelling this rebase, and just do a proper merge manually ;) |
| 00:23.02 | NetRipper | about every automatic merge fails |
| 00:26.18 | dcordes_ | cr2: http://rafb.net/p/Zf1U1h41.html |
| 00:29.26 | *** join/#htc-linux cr2_ (n=cr2@ip-77-24-14-122.web.vodafone.de) |
| 00:29.49 | NetRipper | didnt mmutrace need physical addresses? |
| 00:30.29 | dcordes_ | cr2_: http://rafb.net/p/Zf1U1h41.html |
| 00:31.07 | NetRipper | night guys |
| 00:31.12 | dcordes_ | night |
| 00:32.56 | lupine_85 | hmm, I guess it's no surprise that I get screen tearing? |
| 00:34.12 | dcordes_ | where? |
| 00:38.55 | maejrep | cr2_: i'm here |
| 00:39.39 | maejrep | NetRipper: i see you got the new branch squared away? ;o |
| 00:39.58 | maejrep | want me to tar up my modified/copied files for comparison? |
| 00:40.51 | cr2_ | maejrep: the vreg level values are in mV |
| 00:40.58 | cr2_ | i've edited the wiki |
| 00:41.24 | cr2_ | you can compare them with the proc_comm table values |
| 00:41.57 | cr2_ | maejrep: the vreg usage is very strong dependent on the phone model. like gpio |
| 00:42.35 | cr2_ | the raph800 spl has epson and toshiba mddi support, but epson is hardcoded. |
| 00:43.14 | cr2_ | i began to document the registers used by epson in rapahelMDDI wiki page. at the bottom |
| 00:43.23 | dcordes_ | cr2_: does my spl mention kovsky100 or 200..? |
| 00:46.16 | cr2_ | dcordes_: kovsky only |
| 00:46.53 | cr2_ | maejrep: it is possible to read the gpio ALT_CFG register |
| 00:47.12 | dcordes_ | cr2_: should we just use kovsky100 ? maybe cdma versions will be released in future |
| 00:47.30 | cr2_ | as you like |
| 00:47.56 | dcordes_ | did you see the pastebin? |
| 00:48.29 | cr2_ | maejrep: if you will recompile the .27 kernel, add the bt (hs serial) driver |
| 00:49.39 | cr2_ | maejrep: for epson, the product id is returned by mddi_read of the registers 0x0 and 0x4 |
| 00:49.47 | maejrep | maejrep: how do you read it? write the gpio number to the first byte, and read the second byte? |
| 00:50.38 | cr2_ | maejrep: i think so, but can recheck |
| 00:50.40 | maejrep | wtf |
| 00:50.51 | maejrep | that was supposed to be cr2, not maejrep :( |
| 00:51.05 | cr2_ | lol |
| 00:52.57 | lupine_85 | dcordes_: in enlightenment |
| 00:53.08 | maejrep | cr2_: so the epson mddi is probably not already supported by google? |
| 00:53.17 | lupine_85 | just anything that's a big screen update - like switching workspaces |
| 00:53.32 | cr2_ | maejrep: i guess you'd write the mddi_client_epson.c |
| 00:53.43 | maejrep | ok |
| 00:53.55 | dcordes_ | lupine_85: if it's not msm_fb related you can try the openmoko mailing list |
| 00:54.37 | maejrep | cr2_: those wiki changes are helpful, i'll compare to -panel.c |
| 00:54.48 | cr2_ | ok |
| 00:55.29 | cr2_ | it seems that even for toshiba, g1 code changes different registers from raph. |
| 00:55.52 | cr2_ | is the lcd panel id included there ? |
| 00:56.05 | cr2_ | =gpio_read 150000x |
| 00:56.28 | maejrep | hmm, i can't get .27 to boot anymore for some reason... |
| 00:56.47 | cr2_ | hehe |
| 00:57.07 | cr2_ | _fixup ? mem= ? |
| 00:57.44 | maejrep | never did get that to work, but that's what made me start on .27 |
| 00:57.50 | maejrep | cause .27 is supposed to have sparsemem support |
| 00:58.09 | maejrep | oh it did boot, it just took a while |
| 00:58.33 | cr2_ | ok |
| 00:58.44 | maejrep | [ 5.823850] clk_set_rate 23:50000000 |
| 00:58.44 | maejrep | [ 5.829678] Error setting clock rate (-22) |
| 00:58.51 | maejrep | guess it can't support 50MHz heh |
| 00:58.54 | cr2_ | why 50MHz ? |
| 00:58.58 | cr2_ | yes |
| 00:59.03 | maejrep | no idea |
| 00:59.07 | cr2_ | who requests 50MHz ?? |
| 00:59.22 | maejrep | probably because i haven't changed msm_mmc to use sdcc_set_host_clock |
| 00:59.29 | maejrep | so it uses the built in clock |
| 00:59.37 | cr2_ | it can, but we don't know the formual |
| 00:59.39 | maejrep | but it does work |
| 00:59.41 | cr2_ | ok |
| 00:59.47 | cr2_ | strange. |
| 00:59.48 | maejrep | it mounts |
| 00:59.48 | maejrep | etc |
| 00:59.56 | maejrep | [ 5.474454] mmc0: MMC clock 144000 -> 50000000 Hz, PCLK 66000000 Hz |
| 00:59.59 | cr2_ | i've found the MD/NS for BT. |
| 01:00.06 | maejrep | [ 5.120725] unknown panel id (0x00000003) at mddi_enable |
| 01:00.11 | maejrep | so that's my panel id |
| 01:00.14 | cr2_ | yes, i was surprised too |
| 01:00.23 | cr2_ | how is it calculated ? |
| 01:00.31 | maejrep | how is what calculated? |
| 01:00.39 | cr2_ | panel id |
| 01:00.49 | maejrep | mddi_read at 0 :p |
| 01:00.59 | cr2_ | 0 and 4 |
| 01:01.07 | cr2_ | i'll check :) |
| 01:01.13 | maejrep | <PROTECTED> |
| 01:01.13 | maejrep | <PROTECTED> |
| 01:01.13 | maejrep | <PROTECTED> |
| 01:01.13 | maejrep | <PROTECTED> |
| 01:01.13 | maejrep | <PROTECTED> |
| 01:01.23 | maejrep | maybe not |
| 01:01.37 | maejrep | #define GPIODATA (GPIO_BLOCK_BASE|0x00) |
| 01:01.44 | maejrep | #define GPIO_BLOCK_BASE 0x150000 |
| 01:01.54 | cr2_ | it's for toshiba |
| 01:01.59 | maejrep | oh right |
| 01:02.09 | maejrep | so i'll need to modify -panel.c as well then |
| 01:02.17 | cr2_ | i need to check it with my formula for raph100 |
| 01:02.44 | maejrep | #define MDDI_CLIENT_CORE_BASE 0x108000 |
| 01:02.47 | maejrep | is that right for epson? |
| 01:03.05 | cr2_ | i think no. |
| 01:03.19 | cr2_ | check raphaelMDDI |
| 01:03.40 | maejrep | I see it, but I only see 0's, so I wasn't sure if this was an offset from another base |
| 01:04.06 | tmzt | maejrep: on the new tree? |
| 01:04.10 | cr2_ | ok |
| 01:04.20 | maejrep | no, this is still my local android checkout |
| 01:04.32 | tmzt | cr2_: it appears the defines changed to be offsets from the mddi base in 2.6.27 |
| 01:04.55 | maejrep | yes |
| 01:05.04 | cr2_ | tmzt: i think they are |
| 01:05.08 | maejrep | everything reads from mddi->base + x |
| 01:05.27 | maejrep | i think the base is the same though |
| 01:05.31 | cr2_ | which is ? |
| 01:05.33 | maejrep | so its just the offsets that need fixing |
| 01:05.37 | maejrep | aa700000 ? |
| 01:05.40 | maejrep | and aa600000 |
| 01:05.52 | maejrep | same as on raph100 |
| 01:06.01 | maejrep | (its an MSM iomap define) |
| 01:07.07 | maejrep | [ 4.827756] mddi cmd send rtd: int 23a000, stat 808063, rtd val 11 |
| 01:11.04 | dcordes_ | good night |
| 01:12.03 | cr2_ | maejrep: hm. the Cfg= is saved by wince kernel of dcordes, which i don't have |
| 01:12.19 | maejrep | ? |
| 01:12.20 | cr2_ | maejrep: but i think you need to write the gpio number, and then read the cfg |
| 01:12.24 | *** join/#htc-linux exco (n=exco@e181083128.adsl.alicedsl.de) |
| 01:12.28 | maejrep | yeah that's what I thought |
| 01:12.41 | maejrep | since it keeps the gpio number in 1st reg, after writing the new config |
| 01:12.42 | cr2_ | <PROTECTED> |
| 01:12.50 | cr2_ | and it does not print the cfg= |
| 01:12.54 | exco | someone from the Polars front still around? |
| 01:13.49 | cr2_ | maejrep: the pmdh clock (8c) is different for raph800 |
| 01:13.57 | cr2_ | maejrep: a41 vs a19 |
| 01:13.59 | maejrep | joy :p |
| 01:14.11 | cr2_ | i see 2 kinds of clocks |
| 01:14.20 | cr2_ | a-clock and b-clock |
| 01:14.29 | cr2_ | for b-clock you need both MD and NS |
| 01:14.38 | cr2_ | for a-clock only NS is used |
| 01:15.23 | cr2_ | NetRipper: sleeping ? |
| 01:15.57 | cr2_ | <PROTECTED> |
| 01:15.57 | cr2_ | <PROTECTED> |
| 01:16.15 | cr2_ | the 5c clock can be 0xa06 |
| 01:16.24 | cr2_ | for the lcd on most msm phones |
| 01:16.36 | cr2_ | or the full MD/NS |
| 01:16.44 | cr2_ | for the backlight on g1 |
| 01:17.59 | cr2_ | gp_clk is enabled before manipulating the MD/NS |
| 01:19.50 | cr2_ | 23:25:01 [D:BT] [BTU]MD NS ADDR b32000d8 b32000dc |
| 01:19.51 | cr2_ | 23:25:01 [D:BT] [BTU]MD NS 3ff9b ff9e0044 |
| 01:19.51 | cr2_ | 23:25:01 [D:BT] [BTU]Uart_DM_Clock(2, 0x1) |
| 01:20.25 | cr2_ | i guess we can calculate the 7 params here too |
| 01:20.34 | maejrep | looks like it |
| 01:20.54 | cr2_ | uartdm_clk |
| 01:21.21 | cr2_ | ok. looking at the raph800 lcd types |
| 01:23.27 | maejrep | so .27 gets vreg gp2 and gp4, but doesn't do anything with them. then sets gp_clk to 19200000 |
| 01:24.02 | cr2_ | 19.2MHz its the TCX0 clock |
| 01:24.10 | cr2_ | the r1=3 for bt |
| 01:24.29 | cr2_ | it's the same only for 144kHz SD clock |
| 01:24.44 | maejrep | do we know where gp_clk's offset is? |
| 01:24.45 | tmzt | do you know what a-clock and b-clock? |
| 01:24.51 | tmzt | are |
| 01:25.08 | cr2_ | it may be somewhere else |
| 01:25.25 | cr2_ | wince does not control it ? |
| 01:25.44 | maejrep | was that to tmzt or me? |
| 01:26.09 | cr2_ | maejrep: to you |
| 01:26.21 | maejrep | hmm |
| 01:27.11 | *** join/#htc-linux zycho_ (n=zycho@a89-182-8-231.net-htp.de) |
| 01:30.02 | cr2_ | 1 is hitachi |
| 01:30.10 | maejrep | panel id? |
| 01:30.10 | cr2_ | 2 is toppoly |
| 01:30.16 | maejrep | they call 1 toshiba |
| 01:30.23 | cr2_ | 3 is seid_rgb |
| 01:30.33 | maejrep | or is this only for raph800? |
| 01:30.39 | cr2_ | 4 is seid_mddi |
| 01:30.48 | cr2_ | it't only for raph800 |
| 01:30.55 | cr2_ | raph100 is in wiki |
| 01:30.55 | maejrep | seid == epson, right? |
| 01:30.59 | maejrep | k |
| 01:31.00 | cr2_ | raphaelLCD |
| 01:31.02 | *** part/#htc-linux exco (n=exco@e181083128.adsl.alicedsl.de) |
| 01:31.34 | cr2_ | maybe you can create 2 columns there. the second for raph800, or just after raph100 |
| 01:32.24 | cr2_ | 5 is samsung_mddi |
| 01:32.39 | maejrep | xda-devs is down :/ |
| 01:35.43 | maejrep | looks like this will need a separate -panel driver for raph100 and raph800 :x |
| 01:36.21 | cr2_ | 300 and 30c regs are documented ? |
| 01:36.28 | maejrep | whata? |
| 01:36.33 | maejrep | -a |
| 01:36.39 | maejrep | i mean, which regs? |
| 01:36.59 | cr2_ | GPIOP_CONFIG 0x0300 |
| 01:37.00 | cr2_ | ok |
| 01:37.03 | cr2_ | but not 30c |
| 01:37.29 | cr2_ | 30c is written, and then 324 is read |
| 01:37.45 | cr2_ | <PROTECTED> |
| 01:38.06 | cr2_ | 300=0 |
| 01:38.13 | cr2_ | 30c=0x3000 |
| 01:38.23 | cr2_ | read 324 |
| 01:38.54 | cr2_ | id=[324]>>16 |
| 01:39.13 | cr2_ | but then this "id" is converted into another id :) |
| 01:40.37 | maejrep | fun |
| 01:41.34 | cr2_ | hmm. now i don't understand it |
| 01:41.58 | cr2_ | looks like same conditional mixture of epson and toshiba |
| 01:43.04 | BabelO | hmm still cr2 :) |
| 01:43.16 | BabelO | evening cr2 :) you never sleep ? |
| 01:43.20 | cr2_ | yeah, need to sleep |
| 01:43.39 | BabelO | cr2_: i go a bit more on GSM / sound on omap850 |
| 01:44.21 | silven | BabelO : greetings. |
| 01:44.48 | tmzt | cr2_: how are commands sent to the mddi chip and does HSW/VSW mean we can control the timings now? |
| 01:46.37 | BabelO | hi silven, nedd to sleep too, so good night |
| 01:47.18 | cr2_ | 0,3 -> 5; 1 -> a; 2 -> f ; others =2 |
| 01:47.52 | cr2_ | hmm. only samsung and toppoly ? |
| 01:48.17 | cr2_ | maejrep: does the bl tell something about lcd id ? |
| 01:48.39 | cr2_ | tmzt: it's a bit early to talk about |
| 01:48.55 | cr2_ | ah, it's not all |
| 01:48.57 | maejrep | bl? |
| 01:49.05 | maejrep | oh bootloader? |
| 01:49.10 | cr2_ | this second id is translated into another id ;) |
| 01:49.11 | maejrep | i dont think so |
| 01:49.12 | cr2_ | yes |
| 01:49.45 | maejrep | tmzt: commands are sent via memory writes |
| 01:49.49 | *** join/#htc-linux the_sys0p (n=the_sys0@cpe-67-49-210-229.bak.res.rr.com) |
| 01:49.52 | cr2_ | 2->2, 3->7, 5->1, a->8, f->9 |
| 01:50.18 | maejrep | so where does my panel id of 3 come in? :p |
| 01:53.29 | cr2_ | you should do the ops above |
| 01:53.32 | cr2_ | 300=0 |
| 01:53.36 | cr2_ | 30c=3000 |
| 01:53.39 | cr2_ | read 324 |
| 01:53.51 | cr2_ | ok. it's 3:00 now. good night |
| 01:57.54 | maejrep | ah ok |
| 02:00.55 | *** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey) |
| 02:01.25 | *** join/#htc-linux balsat_ (n=kra@87.72.13.87) |
| 02:01.29 | tmzt | maejrep: writes to memory, like serial or i2c or memory-mapped registers? |
| 02:01.51 | maejrep | afaict, registers |
| 02:02.17 | maejrep | there is no interrupt to send or receive, you just write to memory and wait for data to read |
| 02:13.20 | *** join/#htc-linux soljin (i=45ffcf5d@gateway/web/ajax/mibbit.com/x-b27c7f5d54f32bc9) |
| 02:22.38 | silven | Does anyone know if a while(1); will crash a armv5 core? |
| 02:23.00 | maejrep | shouldnt |
| 02:23.32 | silven | Thanks. |
| 02:24.59 | maejrep | thats not based on any kind of experience .. just logically speaking, there's no reason that a simple recursive jump instruction should crash any core |
| 02:25.09 | maejrep | that's one of the basics of machine instruction code |
| 02:26.03 | silven | thanks, I'm looking for a kernel bug and trying to see if while(1) will let me spin the cpu indefinately without crashing it. |
| 02:26.08 | maejrep | the android kernel actually does a for( ;; ); when it's rebooting |
| 02:26.31 | maejrep | ^ that's what google's kernel does when rebooting |
| 02:26.42 | maejrep | it tells the arm9 core to reboot, then enters a for(); loop |
| 02:27.44 | maejrep | however, if the bug is caused by an irq, your while(1) will in fact be interrupted when that irq is raised |
| 02:27.53 | tmzt | after shutting down interrupts? |
| 02:27.54 | silven | hm |
| 02:28.10 | silven | tzmt I'm not really sure. |
| 02:28.19 | silven | It's before board init though |
| 02:28.40 | silven | I was looking at setup_bootram and such |
| 02:29.01 | maejrep | maybe your ramaddr is wrong? |
| 02:29.04 | silven | I just tossed that infinate sleep into setup.c (setup_processor()) |
| 02:29.27 | silven | ramaddr is okay. works fine on older kernels. |
| 02:29.44 | silven | I'm migrating from 2.6.25 -> 29-rc2 |
| 02:29.58 | silven | and trying to weed crap out of the codebase. |
| 02:30.05 | maejrep | huge jump ;o |
| 02:30.31 | tmzt | silven: for omap? |
| 02:30.36 | silven | yea |
| 02:30.42 | silven | I'm looking to integrae with mainline |
| 02:30.46 | silven | I got efb up for twesting |
| 02:30.58 | silven | and I'm trying to find where it's messing up |
| 02:31.03 | tmzt | efb is like the htccon from druidu? |
| 02:31.16 | *** join/#htc-linux dariball (n=dariball@p4FDC492D.dip.t-dialin.net) |
| 02:31.19 | silven | maybe |
| 02:31.32 | silven | it's a really simple framebuffer for debugging before the real fb is live. |
| 02:31.35 | tmzt | accept I think that's a console implemention as well as framebuffer |
| 02:32.10 | silven | yep, that's the one, you basically get init and putstr :) |
| 02:33.43 | silven | tzmt: what device do you have? |
| 03:08.06 | *** join/#htc-linux ali1234 (n=al@robotfuzz.co.uk) |
| 03:08.26 | maejrep | cr2: I think the logic for lcd id's was off slightly |
| 03:09.05 | maejrep | <cr2_> 0,3 -> 5; 1 -> a; 2 -> f ; others =2 <-- should be 1 -> a, 2 -> f, 3 -> 2, all others (incl 0) -> 5 |
| 03:10.07 | maejrep | cause the cmp r3,0x3 is followed by BNE (not BEQ) |
| 03:36.59 | *** join/#htc-linux pzztgotbagz (n=nonya@unaffiliated/pzztgotbagz) |
| 03:37.03 | pzztgotbagz | is it busy in here |
| 03:37.35 | pzztgotbagz | woohoo |
| 03:37.43 | pzztgotbagz | i found the 2 people from connect-utb |
| 03:39.03 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfc685.pool.einsundeins.de) |
| 04:28.28 | maejrep | cr2: |
| 04:28.30 | maejrep | Cmd>display 2 |
| 04:28.30 | maejrep | Current panel type: HITACHI... |
| 04:35.19 | maejrep | cr2: my spl only recognizes toppoly (2) and hitachi (5). the other 2 possible values (0xa, 0xf) display "unknown" with spl command "display 2" |
| 04:47.22 | *** join/#htc-linux miknix (n=miknix@adsl-67-117-91-116.dsl.sntc01.pacbell.net) |
| 04:57.12 | maejrep | also, oddly, according to my spl, my version should be reported as MicroP-Hermann, not Raph :x 85 -> Hermann, 82 -> Raph, other -> Unkonwn |
| 05:23.22 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
| 05:24.08 | *** join/#htc-linux goxboxlive (n=goxboxli@mail2.hjellnesconsult.no) |
| 06:00.18 | *** join/#htc-linux lpotter (n=ljp@58.173.176.153) |
| 06:40.05 | *** join/#htc-linux bs_ (n=kra@87.72.13.87) |
| 06:42.04 | *** join/#htc-linux RZK333 (n=rzk@daemonet.ru) |
| 06:46.17 | *** join/#htc-linux Shinto (n=John@f054220091.adsl.alicedsl.de) |
| 06:49.03 | *** join/#htc-linux dzo (n=dzo@121.98.128.127) |
| 07:05.40 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 07:05.43 | Untouchab1e | Good morning ^^ |
| 07:06.53 | *** join/#htc-linux pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be) |
| 07:41.32 | *** join/#htc-linux pichurri (n=pichurri@users3.ilo.org) |
| 07:42.29 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-168-73.web.vodafone.de) |
| 07:44.30 | cr2 | maejrep: maybe theother panels will be excluded by the double conversion. but the code looks a bit buggy in that area. maybe raph500 is better. otherwise it'll be necessary to dig through the dlls |
| 07:46.33 | maejrep | also, in the google code, for mddi_client_toshiba, it will run through init_toshiba first, then detect panel id, then go through either sharp, toshiba, or toppoly init based on the panel |
| 07:46.55 | NetRipper | maejrep, im trying to rebase (replay the commits) our *.25 stuff onto *.27... lots of conflicts.. so takes some time |
| 07:46.57 | maejrep | so, if my panel (hitachi?) is very different from raph100, we might need some new tables setup |
| 07:47.08 | cr2 | maybe we misunderstand something |
| 07:47.15 | tmzt | swetland said there where changes in 2.6.27 here, are you using 27 now? |
| 07:47.27 | swetland | there was a big overhaul of the fb and mddi code for '.27 |
| 07:47.32 | swetland | to try to make it a lot saner |
| 07:47.46 | cr2 | i thought toshiba/epson are "remote", i.e. located on the panel |
| 07:47.49 | swetland | if you guys are still running into headaches supporting multiple targets, feedback would be interesting |
| 07:48.04 | swetland | yeah the tricky thing with mddi is you have potentially a lot of pieces |
| 07:48.26 | maejrep | swetland: the main issue is that raph800 is hard to distinguish from raph100, and even harder to distinguish from raph500, but the hardware is so very different |
| 07:48.27 | cr2 | swetland: is there any good overview of mddi architecture available ? |
| 07:48.40 | swetland | the MDP and MDDI controller on the 7k, then a MDDI client, which may be a generic MDDI lcd controller (like that toshiba part) which has a panel hanging off it it, requiring panel-specific init |
| 07:49.04 | tmzt | the panel has a second controller attached to it? |
| 07:49.06 | maejrep | swetland: that explains it |
| 07:49.24 | swetland | and then, a single device *may* have multiple panels |
| 07:49.39 | swetland | htc (and other oems) like to have secondary and tertiary sources for parts |
| 07:50.08 | maejrep | NetRipper: just fair warning, a lot of stuff has changed that needed to be hacked around :) |
| 07:50.20 | swetland | so, for dream we have two different panels we detect and support. detection may be via any number of methods, depending on the board/device design |
| 07:50.34 | cr2 | swetland: there is nothing wrong with using multiple chips, i'm just missing the bigger picture |
| 07:50.48 | NetRipper | maejrep, additional hacks or hacks of ours that need to be placed differently? |
| 07:50.58 | swetland | cr2: yeah, I don't think there's any good publicly available docs for all of this mess |
| 07:51.02 | maejrep | NetRipper: eh, a little of both actually |
| 07:51.12 | swetland | the datasheets we have available aren't all that wonderful even |
| 07:51.13 | cr2 | swetland: hmmm :( |
| 07:51.22 | maejrep | ie, i now have to disable adsp and watchdog, because they detect AMSS version :) |
| 07:51.35 | NetRipper | ok |
| 07:51.45 | maejrep | but that's just via macros, so i'm sure we could look into it at some point |
| 07:51.46 | tmzt | would it make sense to have something like mddi_client as a new platform_device class? |
| 07:51.52 | tmzt | am I missing something here? |
| 07:52.00 | swetland | tmzt: we did that in the original design |
| 07:52.01 | maejrep | tmzt: i think it is ..? |
| 07:52.13 | swetland | the thing is you *also* have to deal with what's behind the mddi_client |
| 07:52.19 | cr2 | swetland: qualcomm states that it's a VESA published standard. i'm not talkng about the actual register layout on a custom chip. |
| 07:52.31 | tmzt | maejrep: oh, you where describing seperate _init's like you where initing the chip as panel |
| 07:52.41 | swetland | and to know that, you may need information outside just what client there is |
| 07:52.48 | swetland | cr2: yeah, I haven't seen the vesa docs |
| 07:52.58 | cr2 | ok |
| 07:53.02 | maejrep | tmzt: it runs the init table via the same way, just that toshiba_init has one set of instructions, then each panel has a separate set of instructions |
| 07:53.17 | tmzt | ok, that's what I was missing |
| 07:53.17 | NetRipper | maejrep, could you pack up a diff? maybe i'll try and see which approach is easier.. :) |
| 07:53.22 | maejrep | it'll run toshiba_init first, detect panel id, then run the panel-specific init instructions |
| 07:53.36 | NetRipper | i gtg to work. bbl |
| 07:53.45 | swetland | you have a bunch of moving parts. there's power and reset for the bridge chip and the panel, which may or may not use vregs from the pmic or external regulators via gpio or whatnot |
| 07:53.54 | swetland | then you have to be able to init the bridge chip |
| 07:54.11 | maejrep | NetRipper: can we not just rebase the branch without resolving conflicts, then copy over whatever changes i have already to make it work, and consider that one commit a dud? :) |
| 07:54.16 | swetland | then you have to be able to init the panel (which may mean using the spi/i2c on the bridge chip to send commands to the panel) |
| 07:55.03 | maejrep | swetland: I think I've gotten somewhere now by disabling certain portions of the init code |
| 07:55.08 | Untouchab1e | swetland, you obviously know what needs to be done.. do you have any idea on how? ^^ |
| 07:55.44 | maejrep | Untouchab1e: our hardware has every potential of being nothing like what he's got to work with :P |
| 07:56.07 | Untouchab1e | what does he got then? :) (I just kinda jumped in, sorry) |
| 07:56.09 | maejrep | i just need to find out which init instructions are killing my panel, and figure out why |
| 07:56.17 | Untouchab1e | aah |
| 07:56.18 | *** join/#htc-linux BabelO (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 07:56.20 | maejrep | Untouchab1e: g1 panels :p |
| 07:56.31 | Untouchab1e | Ah, ok, then I see the complications, hehe |
| 07:56.33 | swetland | generally I'm working on projects directly with oems and they're actually sharing docs with me |
| 07:56.42 | Untouchab1e | swetland: nice |
| 07:56.45 | cr2 | ok, i'm leaving to work |
| 07:56.46 | maejrep | btw, looks like i2c changed in .27 as well |
| 07:56.49 | swetland | it's obviously trickier if you have no idea upfront how it's all connected |
| 07:56.51 | Untouchab1e | cr2: havea good one |
| 07:56.55 | maejrep | so i need to update the keyboard and led drivers |
| 07:57.11 | maejrep | swetland: i'm kind limping along as I go ;) but I'm a quick learner |
| 07:57.16 | maejrep | s/kind/kinda/ |
| 07:57.51 | maejrep | (that is to say, I don't know up front how its all connected :) |
| 07:59.16 | Untouchab1e | I am forever greatfull for the progress you have made though maejrep.. |
| 07:59.18 | Untouchab1e | ^^ |
| 07:59.49 | *** join/#htc-linux lavender-t (n=hzhuang@c-24-17-204-47.hsd1.wa.comcast.net) |
| 07:59.51 | maejrep | swetland: out of curiosity, are there any plans at all, or any likelihood, to include 3rd party patches into google's msm branch? |
| 08:00.26 | maejrep | ie, your code works with AMSS 6+, does google have any interest of accepting patches that add support for AMSS <6 :) |
| 08:01.10 | swetland | I wouldn't mind, if it was cleanly done |
| 08:01.33 | maejrep | would QCT mind? :p |
| 08:01.34 | swetland | our goal is to get everything out into the mainline. greg-kh has suddenly started pushing a bunch of stuff that way which is nice. |
| 08:02.32 | swetland | maejrep: no clue. I'm doubtful it'd be on their radar |
| 08:03.54 | swetland | I think you'd probably want to maintain your own smd, etc drivers for the older versions |
| 08:04.17 | swetland | but there's no reason they couldn't be included and available as a build option if you're targeting hw running those amss versions |
| 08:06.47 | *** join/#htc-linux ewasx (n=Armin@armin-dev.ict.tno.nl) |
| 08:09.03 | *** join/#htc-linux rmoravcik (n=rmoravci@gtsgw.ttc.cz) |
| 08:10.17 | *** join/#htc-linux metter (n=metter@43.111.202.62.cust.bluewin.ch) |
| 08:11.38 | maejrep | swetland: of course, and that's what we've been doing -- most of our patches are kind of aimed at not breaking AMSS 6+ compatibility |
| 08:12.42 | maejrep | cause proc_comm works differently for us, so we need our own proc_comm_wince driver for the AMSS_WINCE version |
| 08:13.05 | maejrep | and consequently things like pm.o and vreg.o work differently as well, based on AMSS version |
| 08:13.54 | maejrep | google's smd mostly works with ours as well, at least GSM versions |
| 08:14.14 | maejrep | doesn't work with 7500 (CDMA vogue, kaiser, raphael, etc) |
| 08:14.38 | swetland | nods |
| 08:14.41 | maejrep | well, it does work, but smd channel 0 has to be read a different way; its not automatically detected like the other channels are |
| 08:15.18 | maejrep | I was just curious if little things like that would ever be incorporated into google's code |
| 08:15.59 | maejrep | where of course trout would be built with the current AMSS implementations, but someone with a raphael could checkout google's code, compile it with a WINCE compatible AMSS version, and have a working kernel, for example |
| 08:16.38 | maejrep | we're not ready for that obviously, but if Google is open to it, I think we would definitely try to work towards that |
| 08:17.01 | Untouchab1e | swetland: I just got my ADP1.. I reckon that the Android build on it is old and dated (Considering the Android builds we are putting on our Raph's and Diamonds is much newer)... Is there any point in upgrading to Cupcake on the ADP1 yet? |
| 08:17.54 | Untouchab1e | (sorry for the OT) |
| 08:19.12 | swetland | if you want to hack on cupcake |
| 08:19.31 | swetland | if you just want to use it, probably worth waiting a bit longer |
| 08:19.56 | Untouchab1e | Yeah, what I thought as well.. How long do you reckon untill its usable? |
| 08:20.27 | swetland | maejrep: I'd prefer not to pepper the smd.c and stuff with a ton of ifdefs for support of the older protocols, but if you guys have functional alternatives that can be compiled for the older hw, we'd have some interest |
| 08:20.38 | swetland | or you could aim to push to the mainline alongside/after our stuff goes out |
| 08:20.52 | swetland | I've been using it on my primary phone for a few weeks now |
| 08:21.27 | swetland | still a bit rough in places, it's not been through a full release process like 1.0 has yet |
| 08:22.00 | Untouchab1e | I see.. I dont reckon their is any release date or anything like that? |
| 08:22.13 | Untouchab1e | its just a "its done when its done" kinda thing? |
| 08:22.23 | maejrep | swetland: so if instead of using ifdefs for e.g., vreg.o, if we just created vreg_wince.o that was built when AMSS_WINCE is selected, that would be reasonable? |
| 08:22.26 | swetland | pretty much. getting close |
| 08:22.42 | Untouchab1e | cool |
| 08:22.48 | swetland | maejrep: I think that'd be a better approach, unless the changes were very very minimal |
| 08:22.59 | maejrep | they are for vreg ;p |
| 08:23.18 | maejrep | e.g. (pardon my paste): |
| 08:23.19 | maejrep | int vreg_enable(struct vreg *vreg) |
| 08:23.20 | maejrep | { |
| 08:23.20 | maejrep | <PROTECTED> |
| 08:23.20 | maejrep | #if defined(CONFIG_MSM_AMSS_VERSION_WINCE) |
| 08:23.20 | maejrep | <PROTECTED> |
| 08:23.21 | maejrep | #else |
| 08:23.23 | maejrep | <PROTECTED> |
| 08:23.25 | maejrep | <PROTECTED> |
| 08:23.27 | maejrep | #endif |
| 08:23.31 | maejrep | } |
| 08:23.50 | tmzt | didn't cr2 say there was a generic vreg_on/off proc_comm also? |
| 08:24.05 | tmzt | that's it |
| 08:24.15 | maejrep | hmm, possibly: 3c 0x15 pmic reg * on ? |
| 08:24.27 | maejrep | (which is what I pasted) |
| 08:24.33 | tmzt | yeah, sorry |
| 08:24.42 | maejrep | but, not a generic "VREG_SWITCH" that can turn one on or off |
| 08:25.12 | tmzt | does the list of vrefs (id or idx) match up with trout? |
| 08:25.54 | maejrep | more or less yeah .. but instead of id being 0-x, it's 1<<x |
| 08:26.08 | swetland | the other reason to keep it separate is that we'd be less likely to break you |
| 08:26.11 | maejrep | or: 2^id |
| 08:26.19 | maejrep | don't break meh D: |
| 08:26.43 | swetland | you're working against something existing. we're working on a moving target as qct adjusts the protocols going forward, etc |
| 08:27.14 | tmzt | I mean do the vreg_ calls have to change between trout/raph etc? |
| 08:27.25 | maejrep | tmzt: only in that regard ^ |
| 08:27.28 | swetland | and we don't have a full collection of assorted existing wince devices and the time to test with every one |
| 08:27.51 | maejrep | obviously not, which is why I was asking |
| 08:28.14 | maejrep | I don't think anyone would expect google to test devices you aren't developing with and working on |
| 08:28.56 | maejrep | and if it breaks a pre-6 phone, then that would be where a 3rd party has to patch it to work again |
| 08:29.17 | maejrep | at least that's my point of view |
| 08:29.58 | Untouchab1e | swetland, are you an Google employeè? |
| 08:30.04 | Untouchab1e | (if you dont mind me asking) |
| 08:30.11 | maejrep | hmm, actually, just found a bug in my vreg code :P |
| 08:30.11 | swetland | yeah. I'm the systems/kernel lead for android. |
| 08:30.30 | Untouchab1e | cool! Are you in the US or Dublin? |
| 08:30.44 | maejrep | swetland: so I probably saw you talk at Google IO then? :) |
| 08:30.48 | swetland | us. I work out of google galactic hq in mountainview |
| 08:31.01 | swetland | I was on the fireside chat panel thing |
| 08:31.14 | maejrep | I was in that |
| 08:31.15 | Skitzo | maejrep, Untouchab1e, everyone else, you're amazing! |
| 08:31.20 | Untouchab1e | Aha! My brother is currently in the Google Europe HQ in Dublin. :) |
| 08:31.30 | Untouchab1e | Skitzo: Hi ^^ |
| 08:31.50 | Skitzo | how's things? |
| 08:32.09 | Untouchab1e | all is good. currently in class though, so basically just reading the convo here :) |
| 08:32.14 | NetRipper | maejrep, yea i was thinking the same thing, but we'll lose the seperate commits we have at the moment.. although we could reference to the old commits |
| 08:32.20 | Skitzo | ahhh ;D |
| 08:32.26 | Untouchab1e | and yourself? |
| 08:32.51 | Skitzo | just got home from work to find a new build available :D |
| 08:32.51 | maejrep | NetRipper: really? can you just take my version of the file and consider the jump from 2.6.25 HEAD to 2.6.27 a single revision? |
| 08:33.01 | Untouchab1e | hehe |
| 08:33.13 | Untouchab1e | Skitzo, do you have the Raph100 or raph800? |
| 08:33.18 | Skitzo | 100 |
| 08:33.24 | maejrep | Skitzo: whats in the new build? |
| 08:33.26 | Untouchab1e | Cool |
| 08:33.36 | Skitzo | keyboard |
| 08:33.42 | Skitzo | isn't it your build, maejrep? |
| 08:33.52 | Untouchab1e | maejrep, It was just me that posted the build Netripper put together based on your work (with the Raph100 keyboard mapping) |
| 08:33.59 | maejrep | I wrote the driver, but only built a test kernel for some people here |
| 08:34.12 | maejrep | ah ok, I think j0b0 did the raph100 keymap change |
| 08:34.22 | Untouchab1e | ah, thats right |
| 08:34.28 | Untouchab1e | I stand corrected ^^ |
| 08:34.35 | Skitzo | you're managing the builds on connect-utb aren't you Untouchab1e ? |
| 08:34.39 | Untouchab1e | he also threw in the auto-rotation on keyboard-slide |
| 08:34.46 | Untouchab1e | Skitzo, yeah, Im trying to anyhow |
| 08:34.51 | maejrep | NetRipper: found a bug in vreg: |
| 08:34.53 | Untouchab1e | connect-utb is my website at least ^^ |
| 08:34.54 | maejrep | <PROTECTED> |
| 08:34.54 | maejrep | <PROTECTED> |
| 08:35.00 | Skitzo | oh nice |
| 08:35.08 | lavender-t | hello folks ! long time no see. |
| 08:35.11 | maejrep | wasn't adjusting the id like cr2 suggested |
| 08:35.23 | Untouchab1e | hi lavender! Been a long time :) |
| 08:35.33 | Untouchab1e | Skitzo, so just let me know if you have any problems :) |
| 08:35.44 | Skitzo | will do |
| 08:35.48 | Skitzo | many thanks for the hosting :) |
| 08:35.57 | Untouchab1e | No problem! The least I can do |
| 08:35.58 | maejrep | NetRipper: I can tar up my changed files, or one large diff, if you'd like to see what I've changed |
| 08:35.59 | lavender-t | i had a friend visiting so i'm now totally lost :) |
| 08:36.03 | Untouchab1e | hehe |
| 08:36.20 | maejrep | lavender-t: i have 2.6.27 booting on my raph :) |
| 08:36.23 | Untouchab1e | :D |
| 08:36.33 | lavender-t | wow ! |
| 08:36.50 | Untouchab1e | maejrep is awesome, hah! He solved the navi-led mystery, the qwerty keyboard, and now 2.6.27 :D |
| 08:36.52 | lavender-t | so we are officially on 2.6.27 ? |
| 08:37.20 | maejrep | lavender-t: moving to it.. NetRipper's the brave one actually trying to do it properly ;) |
| 08:37.29 | lavender-t | oh yeah. maejrep is awesome :) |
| 08:37.37 | Untouchab1e | ^^ |
| 08:37.59 | Untouchab1e | a shame that he has to do everything again since we are moving to 2.6.27 |
| 08:38.07 | maejrep | not really |
| 08:38.09 | lavender-t | so anyone's bricked a phone or two with 2.6.27 ? |
| 08:38.25 | Untouchab1e | maejrep: Not from scratch though ^^ |
| 08:38.37 | maejrep | i mean there's some things that have gone backwards, and need to be re-fixed |
| 08:38.53 | maejrep | but obviously staying close to mainline is a good thing |
| 08:39.02 | lavender-t | hm let me git 2.6.27 and see how it works ... |
| 08:39.36 | lavender-t | maejrep, do you have any diffs not checked in ? :) |
| 08:39.36 | tmzt | swetland: in what timeframe are you moving to 2.6.28? |
| 08:39.46 | maejrep | a lot heh |
| 08:39.55 | lavender-t | doh ! |
| 08:40.05 | maejrep | lavender-t: the changes I made to get 2.6.27 aren't committed to our ltg yet |
| 08:40.53 | NetRipper | maejrep is it possible for you to make a normal diff (not git-diff, unless git-diffs include new files?) |
| 08:41.41 | lavender-t | git add the files and git diff ? |
| 08:42.20 | NetRipper | even then they're not in the git-diff |
| 08:43.02 | tmzt | git commit locally? |
| 08:43.34 | swetland | tmzt: we did the rebase last week (friday?) and if we don't run into any serious problems we'll likely publish a branch this week |
| 08:44.29 | maejrep | NetRipper: they are if you do git diff HEAD^ |
| 08:44.44 | tmzt | but will it replace 2.6.27 in android.git.kernel? is this part of the roadmap? |
| 08:45.13 | swetland | it'll be a new branch android-2.7.28, etc |
| 08:45.16 | swetland | er 2.6.28 |
| 08:45.28 | swetland | since we rebase to move forward, and don't merge |
| 08:45.49 | maejrep | diff --git a/arch/arm/configs/htcdiamond_defconfig b/arch/arm/configs/htcdiamond_defconfig |
| 08:45.49 | maejrep | new file mode 100644 |
| 08:45.49 | maejrep | index 0000000..85c687c |
| 08:45.49 | maejrep | --- /dev/null |
| 08:45.49 | maejrep | +++ b/arch/arm/configs/htcdiamond_defconfig |
| 08:47.19 | maejrep | hmm, still need to figure out how to reboot the phone :p |
| 08:50.23 | Untouchab1e | that would be nice, hehe |
| 08:50.54 | Untouchab1e | speaking of rebooting, the G1s battery cover is kinda shit.. I am so sure its going to break each time I take it off |
| 08:51.38 | tmzt | does the hardware reboot keys work? (forget what they are) |
| 08:52.54 | maejrep | tmzt: the little reset button you press with the stylus does work |
| 08:53.05 | maejrep | but I'd like to be able to type reboot on the command line :p |
| 08:53.27 | tmzt | I mean Untouchab1e on G1, I thought there where three keys you can press to reboot |
| 08:53.38 | maejrep | oh |
| 08:53.49 | Untouchab1e | tmzt, yeah there is.. |
| 08:53.52 | maejrep | Fn+Ctrl+backspace? |
| 08:53.52 | maejrep | :D |
| 08:53.55 | Untouchab1e | haha |
| 08:54.07 | Untouchab1e | think its menu+something+something_else |
| 08:54.29 | Untouchab1e | but I still need to remove the battery-cover in order to get my SIM-card (to put it in my Raph100 before booting Android) |
| 08:55.12 | lavender-t | the soft reboot will be a lot healther for the files ... |
| 08:55.48 | maejrep | its still a modem reset - meaning still equivalent to hitting the reset button on a PC |
| 08:56.00 | maejrep | which means the files will still be corrupted if in the middle of an operation |
| 08:56.24 | tmzt | it should sync first, you add the reboot logic to the kernel's reboot commands |
| 08:56.30 | maejrep | unless you mean the 3-key reboot, which may actually go through a shutdown sequence |
| 08:56.55 | tmzt | oh, not sure on g1 since it works in bootloader/spl too |
| 08:56.56 | maejrep | the reset button on the phone doesn't do that - it just tells the arm9 core to reboot |
| 08:56.57 | Untouchab1e | I havent tried the 3-key reboot yet actually, so I am unsure if its just an instant reset, or an actual reboot (with a proper shutdown) |
| 08:57.22 | Untouchab1e | but I have it with me, so if I just find out the 3-keys (il check now), I can see |
| 08:58.38 | Untouchab1e | Its the Green call button + Menu + End button |
| 08:59.01 | Untouchab1e | hmm.. |
| 08:59.18 | Untouchab1e | impossible to tell what really went on there, lol |
| 08:59.31 | tmzt | sync first from terminal if you can |
| 08:59.31 | lavender-t | maejrep, how's your proc_comm now ? can we use it to set the sd clocks now ? |
| 09:00.12 | *** join/#htc-linux stefan_schmidt (n=stefan@c120.apm.etc.tu-bs.de) |
| 09:01.21 | maejrep | Untouchab1e: static struct keyreset_platform_data trout_reset_keys_pdata = { |
| 09:01.21 | maejrep | <PROTECTED> |
| 09:01.22 | maejrep | <PROTECTED> |
| 09:01.22 | maejrep | <PROTECTED> |
| 09:01.22 | maejrep | <PROTECTED> |
| 09:01.22 | maejrep | <PROTECTED> |
| 09:01.24 | maejrep | ;) |
| 09:01.40 | maejrep | lavender-t: clocks cannot be set by proc_comm on pre-6 amss |
| 09:01.45 | Untouchab1e | yeah, I figured out the keys |
| 09:01.50 | Untouchab1e | thanks :) |
| 09:02.26 | lavender-t | oh ? i thought diamond was v6 ? |
| 09:04.53 | maejrep | no, the g1 sets clocks by proc_comm, but we have to use memory registers to set the clocks |
| 09:06.33 | maejrep | and afaik it should work fine |
| 09:06.41 | maejrep | we just need to know where each clock's register is |
| 09:06.47 | maejrep | ie, it works fine for sdcc |
| 09:07.09 | maejrep | similar code can work for other clocks, if we just know where to write |
| 09:07.19 | Untouchab1e | what did they do with the clocks on the vouge? |
| 09:07.22 | maejrep | we also got that 7-arg function to work |
| 09:07.34 | maejrep | Untouchab1e: hard-coded the values, and then wrote to the appropriate register |
| 09:08.16 | lavender-t | ok. |
| 09:09.03 | *** join/#htc-linux timebomb (n=tb@e176096084.adsl.alicedsl.de) |
| 09:09.07 | Untouchab1e | But the clocks are indeed set correctly and running fine on the vouge now, right? |
| 09:09.18 | Untouchab1e | (havent followed that project very closely) |
| 09:10.25 | maejrep | afaik |
| 09:10.41 | maejrep | i'm sure we can just use his clock id and register values |
| 09:10.51 | Untouchab1e | mm |
| 09:12.07 | maejrep | the actual Md/Ns values (that's the "official" name of the a0/a4 registers, lavender-t ;) we should mostly be able to calculate using cr2's 7-arg formula |
| 09:12.09 | tmzt | Untouchab1e: it's more than the vogue |
| 09:12.30 | Untouchab1e | what is mroe than the vouge? heh |
| 09:12.34 | Untouchab1e | more* |
| 09:12.47 | tmzt | more devices than just the vogue |
| 09:12.58 | Untouchab1e | hehe, I know.. was just curious as to how they did it |
| 09:13.01 | NetRipper | ermmm |
| 09:13.02 | NetRipper | so |
| 09:13.23 | NetRipper | given android will move to 2.6.28 in a week or so, should we migrate to 2.6.27 or wait for .28? |
| 09:13.48 | Untouchab1e | Do we know how long they will stay with 2.6.28 though? |
| 09:14.24 | tmzt | my reading on mailing list discussions was that google would follow the last stable release but not stay current with upstream git |
| 09:14.52 | NetRipper | what does 'upstream git' mean? |
| 09:15.11 | tmzt | I mean linus.git, the very latest tree |
| 09:15.26 | tmzt | like 2.6.29-rcX right now |
| 09:15.35 | NetRipper | ah |
| 09:15.35 | NetRipper | ok |
| 09:15.43 | NetRipper | in other words, they do as they please? ;) |
| 09:15.49 | Untouchab1e | haha |
| 09:16.07 | Untouchab1e | making it fun to try to keep up |
| 09:16.26 | tmzt | swetland would be the one to ask if you can word the question better |
| 09:16.59 | NetRipper | wasn't really a question, i was just kidding |
| 09:17.05 | NetRipper | bad joke ;) |
| 09:17.05 | lavender-t | agree. better know what's in there for us. |
| 09:17.20 | Untouchab1e | :P |
| 09:17.41 | lavender-t | oh netripper's sense of humor :) |
| 09:18.08 | tmzt | http://thread.gmane.org/gmane.comp.handhelds.android.kernel/81 |
| 09:18.12 | Untouchab1e | not compatible with tmzt's sense of humor |
| 09:20.39 | maejrep | heh |
| 09:23.13 | *** join/#htc-linux DasFx (n=John@dasfx-lptp.euronet.nl) |
| 09:24.03 | maejrep | NetRipper: any idea why with: CONFIG_HTC_FB_CONSOLE_BOOT=y, it still continues to use it after it should have already moved on to the real fb? |
| 09:24.47 | NetRipper | maejrep, no, it should do a handover.. try to grep for it and see if you might have missed something |
| 09:25.13 | NetRipper | maybe druidu made a change in something kernel-specific |
| 09:25.14 | maejrep | weird thing is it does the handover about 60 seconds into the boot |
| 09:25.19 | Untouchab1e | speaking of humor, failpix of the day: http://failblog.files.wordpress.com/2009/01/fail-owned-age-to-pee-fail.jpg |
| 09:25.31 | maejrep | but until then, it has the 1-sec delay between each message |
| 09:25.47 | NetRipper | maejrep, you can disable the delay at least ;) |
| 09:26.04 | NetRipper | maejrep, it doesn't cause corruption? |
| 09:26.12 | maejrep | then at 120 seconds is when it starts dma on the fb |
| 09:26.21 | maejrep | in what sense? I don't see any corruption |
| 09:26.41 | NetRipper | well if you boot with both consoles active on 2.6.25, you'll see dma's getting mixed up.. |
| 09:26.47 | NetRipper | causing weird behaviour |
| 09:27.07 | maejrep | hmm |
| 09:27.07 | maejrep | no |
| 09:27.07 | maejrep | but I see the real fb now |
| 09:27.08 | maejrep | it just takes about 3 minutes |
| 09:27.15 | NetRipper | lol |
| 09:27.23 | maejrep | maybe it's all the printk's i have ;x |
| 09:27.26 | NetRipper | is the original proc_comm still active? |
| 09:27.30 | maejrep | no |
| 09:27.39 | maejrep | i actually removed it from Makefile |
| 09:27.40 | NetRipper | some other things that keep timing out? |
| 09:27.41 | maejrep | well |
| 09:27.58 | maejrep | obj-$(CONFIG_MSM_AMSS_VERSION_6225) += proc_comm.o |
| 09:27.58 | maejrep | obj-$(CONFIG_MSM_AMSS_VERSION_WINCE) += proc_comm_wince.o |
| 09:28.06 | maejrep | (plus the other 2 6* versions) |
| 09:28.38 | NetRipper | sounds like something in the init is not working properly and causing delays |
| 09:28.39 | tmzt | they have exactly the same api and names? |
| 09:28.44 | maejrep | proc comm does have like 4-5 prink's for debugging :p |
| 09:28.47 | maejrep | tmzt: no |
| 09:28.48 | *** join/#htc-linux Sti_0239 (n=Where_is@58.75-201-80.adsl-dyn.isp.belgacom.be) |
| 09:29.06 | NetRipper | tmzt, no, they don't share the same .h file either.. it's a seperate implementation |
| 09:29.24 | maejrep | NetRipper: which means that your 2 vibra calls at boot actually last about 5 seconds ;) |
| 09:29.35 | NetRipper | maejrep, do they? |
| 09:29.49 | maejrep | for me.. and in .27 |
| 09:29.53 | NetRipper | hm |
| 09:29.57 | maejrep | i'm gonna disable the delay |
| 09:29.59 | maejrep | see if that helps any |
| 09:30.11 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 09:30.35 | NetRipper | ok |
| 09:30.40 | NetRipper | i gtg back to work |
| 09:34.19 | lavender-t | hi maejrep, could you post your diffs somewhere and i'll give it a try ? |
| 09:35.28 | maejrep | for .27? |
| 09:35.33 | lavender-t | yep |
| 09:38.32 | maejrep | 290KB diff heh |
| 09:40.20 | lavender-t | so big ! gzip should be fine ... |
| 09:40.47 | maejrep | http://www.privatepaste.com/041X08BBhM .. or http://www.privatepaste.com/041X08BBhM/download if you want to use wget |
| 09:41.44 | maejrep | 1) i haven't updated diamond code to work yet, 2) some of the changes are specific to raph800, so you may also need to make some changes for raph100 |
| 09:41.51 | maejrep | NetRipper: ^ you might like to have that as well :p |
| 09:43.42 | lavender-t | thanks maejrep ! oh yeah, the tux picture is in there ... :) |
| 09:44.25 | maejrep | heh yeah, I just went through adding stuff from when raph support was first added |
| 09:50.26 | tmzt | how many files did you change in 2.6.27? |
| 09:50.48 | tmzt | git diffstat I think |
| 09:53.04 | maejrep | 21 new files, 34 modified files |
| 09:53.19 | maejrep | including things like Kconfig and Makefile |
| 09:53.38 | tmzt | those definately should be included |
| 09:53.53 | maejrep | yes |
| 09:56.04 | *** join/#htc-linux radem205 (n=aaa@e144118.upc-e.chello.nl) |
| 09:57.47 | maejrep | lavender-t: you can see cr2's formula implemented in clock-wince.c |
| 09:57.50 | *** join/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 10:02.50 | lavender-t | cool thanks ! |
| 10:21.15 | *** join/#htc-linux TripleQ (n=joost@ip49-198-173-82.adsl2.static.versatel.nl) |
| 10:35.02 | *** part/#htc-linux silven (n=zmc@lurian.net) |
| 10:35.56 | *** join/#htc-linux Abracadabra (n=aaabraca@62-244-191-249.cust.exponential-e.net) |
| 10:42.28 | *** join/#htc-linux myxor (n=myxor@pdbn-4d089516.pool.mediaWays.net) |
| 10:45.29 | *** join/#htc-linux timebomb (n=tb@e176119079.adsl.alicedsl.de) |
| 10:56.56 | *** join/#htc-linux rl2000 (n=rl2000@0x573b8b62.hhnqu1.dynamic.dsl.tele.dk) |
| 11:01.55 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 11:03.42 | tmzt | setprop ro.radio.usb-ppp yes # why didn't we see this before? |
| 11:05.17 | tmzt | use-ppp |
| 11:08.57 | *** join/#htc-linux myxor (n=myxor@pdbn-4d089516.pool.mediaWays.net) |
| 11:09.42 | *** join/#htc-linux skool (n=azachars@nat/sun/x-f591febb30d6801a) |
| 11:12.21 | maejrep | ? |
| 11:13.11 | tmzt | hey, it apparently enables ppp in the ril and eliminates the need for dzo's scripts |
| 11:13.20 | tmzt | I think it was added for eeepc |
| 11:13.41 | maejrep | that's a kernel parameter? |
| 11:13.52 | tmzt | no, it goes in /init.rc |
| 11:14.03 | tmzt | also, the rild command line in /init.rc can be changed |
| 11:14.14 | maejrep | oh for android? |
| 11:14.19 | tmzt | yeah |
| 11:14.38 | tmzt | that's was more relevant to what dcordes_ was working on |
| 11:23.08 | *** join/#htc-linux ptl (n=patola@201.82.88.99) |
| 11:23.11 | ptl | Hello |
| 11:24.14 | ptl | I am considering upgrading my ROM to a cooked one, like Michy's. I am searching for all xda-developers.com, but can't find a guide. Do any of you know such guide? And how do I find my SPL version? Lots of red numbers in the reboot, no 1.20 or 3.5/3.6 there. |
| 11:24.28 | ptl | oh, my phone is HTC Athena. |
| 11:28.39 | tmzt | how do you get to bootloader on athena? |
| 11:28.54 | *** join/#htc-linux skool (n=azachars@nat/sun/x-7407c809447c29ad) |
| 11:32.44 | ptl | tmzt, I power it off then power it on. I also use WkTask 'reboot' and it gets to the bootloader screen. That is, the blank screen with numbers, right? |
| 11:33.28 | tmzt | no, I mean the three-color screen assuming athena has one |
| 11:33.45 | tmzt | someone in #xda-devs or #hpcdev can probably help you better with this |
| 11:34.51 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 11:37.47 | ptl | ok... will try them. Thanks |
| 11:52.11 | dcordes_ | maejrep: do you know how to fix the display problem in latest git? |
| 12:23.54 | *** join/#htc-linux paulproteus (n=paulprot@2002:db69:2513:0:0:0:0:1) |
| 12:31.10 | maejrep | display problem? |
| 12:31.13 | maejrep | .25 or .27? |
| 12:33.19 | *** join/#htc-linux stefan_schmidt (n=stefan@w1189.wlan.rz.tu-bs.de) |
| 12:33.24 | AstainHellbring | morning maejrep |
| 12:50.02 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 13:00.07 | *** join/#htc-linux dcordes-x1 (n=zsirc@ip-90-187-232-75.web.vodafone.de) |
| 13:13.41 | *** join/#htc-linux Othello (i=Othello@gateway/tor/x-f525f76f183e3e46) |
| 13:19.30 | *** join/#htc-linux dariball_ (n=dariball@p4FDC492D.dip.t-dialin.net) |
| 13:26.48 | *** join/#htc-linux Skitzo (n=DCLXVI@eth582.vic.adsl.internode.on.net) |
| 13:47.47 | *** join/#htc-linux cr2 (n=konversa@crpl6.physik.uni-wuppertal.de) |
| 13:48.47 | cr2 | maejrep: http://www.wipo.int/pctdb/images4/PCT-PAGES/2006/222006/06058052/06058052.pdf |
| 13:54.24 | *** join/#htc-linux PoohbaLT (n=Poohba@pool-96-235-128-209.cmdnnj.east.verizon.net) |
| 14:12.31 | *** join/#htc-linux drasar (n=maik@lamer.optinet.cz) |
| 14:21.36 | dcordes_ | maejrep: in the .25 with 800 |
| 14:24.29 | NetRipper | maejrep, how much did you merge from the .25? |
| 14:24.40 | dcordes_ | maejrep: can you give me your 2.6.27 differences? I would like to see if it boots on x1 |
| 14:24.44 | dcordes_ | hej NetRipper |
| 14:24.49 | NetRipper | hi dcordes_ |
| 14:25.11 | NetRipper | dcordes_, < maejrep> http://www.privatepaste.com/041X08BBhM .. or http://www.privatepaste.com/041X08BBhM/download if you want to use wget |
| 14:25.30 | NetRipper | maejrep, no need for me to repeat the work if you already did it ;) |
| 14:26.08 | dcordes_ | 10k lines |
| 14:29.35 | dcordes_ | NetRipper: did you boot it on raph100? |
| 14:36.29 | maejrep | NetRipper: as in what? only the new files were straight up copied |
| 14:36.40 | maejrep | everything else I merged by hand |
| 14:37.03 | maejrep | dcordes_: display problem on raph800 being the color issue? |
| 14:37.34 | maejrep | if so, you need to change the color mode / bit packing, in msm_fb.c |
| 14:38.14 | dcordes_ | maejrep: you got the color mode / bit packing patches for raph800 somewhere so I can test on x1? |
| 14:38.53 | maejrep | dcordes_: actually it's probably in that large diff ;) |
| 14:39.23 | dcordes_ | okeh |
| 14:39.30 | maejrep | @@ -635,14 +650,14 @@ static void setup_fb_info(struct msmfb_info *msmfb) |
| 14:40.06 | maejrep | off to work |
| 14:40.48 | dcordes_ | patch unexpectedly ends in middle of line |
| 14:40.48 | dcordes_ | patch: **** malformed patch at line 9997: |
| 14:41.05 | dcordes_ | ok have a nice day |
| 14:41.52 | maejrep | yeah you can't patch it from that point ;p |
| 14:41.55 | maejrep | but those are the changes |
| 14:42.02 | maejrep | and its the same in .25 or .27 |
| 14:42.17 | maejrep | there are other changes in that file, that's why it doesn't work with patch |
| 14:42.18 | dcordes_ | Rotary Wombat |
| 14:42.34 | dcordes_ | wait, I need a different diff? |
| 14:44.05 | maejrep | no i mean for the color mode change |
| 14:44.24 | dcordes_ | ok so I need to include that manually from the .25 ? |
| 14:44.43 | maejrep | yeah just make those same few modifications to .25's msm_fb.c |
| 14:45.04 | dcordes_ | uhm it doesn't compile with just the patch applied and htcraphael_defconfig |
| 14:45.17 | dcordes_ | adscp.c |
| 14:45.29 | maejrep | take it out of .config |
| 14:45.33 | dcordes_ | ok |
| 14:46.03 | maejrep | sorry, didn't update defconfig (cause we should plan to support that and the watchdog files eventually) |
| 14:46.06 | dcordes_ | builds |
| 14:46.46 | maejrep | ok leaving now, bbl |
| 14:46.50 | dcordes_ | cya |
| 15:14.03 | NetRipper | maejrep, what i meant was, are there still things left to merge from *.25 in your diff? |
| 15:14.25 | NetRipper | im going to take a look when im back from work |
| 15:14.53 | NetRipper | dcordes_, no i didnt boot yet.. |
| 15:14.59 | NetRipper | bbl again |
| 15:17.01 | toer | lo |
| 15:28.40 | *** join/#htc-linux cr2 (n=cr2@ip-90-187-228-232.web.vodafone.de) |
| 15:30.42 | *** join/#htc-linux goxboxlive (n=goxboxli@185.84-48-126.nextgentel.com) |
| 15:51.31 | maejrep[w] | NetRipper: no, that should be everything that's in .25 git afaik |
| 15:59.23 | *** join/#htc-linux MethoS (n=lem@host-091-096-211-104.ewe-ip-backbone.de) |
| 16:08.51 | *** join/#htc-linux exco (n=exco@e181097211.adsl.alicedsl.de) |
| 16:13.14 | dcordes_ | cr2: got a link? |
| 16:13.20 | dcordes_ | I know somebody who dows |
| 16:13.25 | dcordes_ | s/dows/does/ |
| 16:17.41 | *** join/#htc-linux GPFerror (n=gpferror@cpe-76-187-41-132.tx.res.rr.com) |
| 16:20.24 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbfc685.pool.einsundeins.de) |
| 16:28.55 | dcordes_ | I just tried to boot the http://www.privatepaste.com/041X08BBhM kernel on xperia. it freezes after console handover: boot [htc_fb-1] -> real [tty0] |
| 16:29.16 | dcordes_ | somebody from the raph/diam faction got an idea? |
| 16:38.47 | pichurri | dcordes_, that's the patch for 2.6.27, right? |
| 16:38.56 | dcordes_ | yeap |
| 16:39.18 | dcordes_ | I suspected it's the arch/arm/mach-msm/htc_fb_console.c thing |
| 16:39.21 | dcordes_ | but doesn't look like it |
| 16:39.34 | pichurri | dcordes_, I think its just long timeouts that maejrep had, leave it for a minute or so... |
| 16:41.37 | dcordes_ | but that was also in the .25 kernel |
| 16:41.40 | dcordes_ | the freeze after handover |
| 16:43.53 | pichurri | dcordes_, hum, what is the output? |
| 16:43.58 | *** join/#htc-linux daspsycho (n=daspsych@213.155.79.202) |
| 16:44.56 | dcordes_ | console handover: boot [htc_fb-1] -> real [tty0] |
| 16:45.56 | pichurri | dcordes_, sorry... |
| 16:47.19 | maejrep[w] | dcordes_: turn off HTC_FB_CONSOLE_BOOT=y (set to n) |
| 16:47.26 | maejrep[w] | and see how far it gets |
| 16:47.34 | maejrep[w] | you might be getting a kernel panic or oops |
| 16:47.55 | maejrep[w] | I was getting a couple NULL pointer dereferences when I was working with it |
| 16:49.53 | *** join/#htc-linux miknix (n=miknix@12.104.145.50) |
| 16:50.36 | dcordes_ | maejrep[w]: oks |
| 16:51.19 | *** part/#htc-linux exco (n=exco@e181097211.adsl.alicedsl.de) |
| 16:51.41 | dcordes_ | I want a plstic backcover for my x1. I'm getting the chills everytime I remove it because it can scratch the rest of the housing |
| 16:52.54 | *** join/#htc-linux ewasx (n=armin@5-157.surfsnel.dsl.internl.net) |
| 17:03.48 | dcordes_ | maejrep[w]: ok it panic'D |
| 17:07.56 | maejrep[w] | know where? |
| 17:08.11 | maejrep[w] | the backtrace should tell you where it's happening |
| 17:22.17 | *** join/#htc-linux liberostelios (n=liberost@79.107.28.155) |
| 17:24.02 | *** join/#htc-linux nizox_ (n=none@eros.ph0k.eu) |
| 17:45.09 | *** join/#htc-linux pH5 (n=ph5@e178195059.adsl.alicedsl.de) |
| 17:47.05 | *** join/#htc-linux mrincredible (n=wmirc_us@99-204-182-34.pools.spcsdns.net) |
| 17:56.06 | *** join/#htc-linux exco (n=exco@e181097211.adsl.alicedsl.de) |
| 17:59.26 | *** join/#htc-linux marmotta (n=skodde@unaffiliated/skodde) |
| 18:02.05 | *** part/#htc-linux BabelO_ (n=fcr@lun34-2-82-238-28-28.fbx.proxad.net) |
| 18:11.08 | *** join/#htc-linux Mullins (n=bw@89.204.243.128) |
| 18:23.11 | *** join/#htc-linux dariball (n=dariball@p4FDC492D.dip.t-dialin.net) |
| 18:32.19 | *** join/#htc-linux the_fish (n=cruel1@p5491C618.dip.t-dialin.net) |
| 18:32.25 | the_fish | hello..... anyone there? |
| 18:34.30 | the_fish | tmzt, u there? need help :| |
| 18:41.36 | NetRipper | dcordes_, you have to remove your backcover to soft-reset? |
| 18:41.57 | *** join/#htc-linux dariball (n=dariball@p4FDC492D.dip.t-dialin.net) |
| 18:42.30 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 19:01.24 | *** join/#htc-linux _newbie3 (n=kvirc@dslb-088-064-019-102.pools.arcor-ip.net) |
| 19:08.56 | *** join/#htc-linux zsircusr (n=zsirc@ip-77-25-254-107.web.vodafone.de) |
| 19:23.34 | *** join/#htc-linux Balsat (n=kll@87.72.13.87) |
| 19:39.20 | *** join/#htc-linux sietse (n=sietse@vogons.xs4all.nl) |
| 19:42.42 | Mullins | dzo: Are you there? |
| 19:44.35 | Balsat | Trying to compile a kernel, but get a error making tmp.vmlinux1 "arm-none-linux-gnueabi-ld: no machine record defined" anyone knows was wrong? |
| 19:45.16 | Mullins | you must ensure a MACH_TYPE is set |
| 19:45.50 | tmzt | CONFIG_MACH_ |
| 19:45.55 | tmzt | in .config |
| 19:46.51 | Balsat | Thanks |
| 19:51.07 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-133-197.web.vodafone.de) |
| 19:52.37 | cr2 | http://pocketnow.com/images/brandon/lineup.jpg |
| 19:57.06 | *** join/#htc-linux zycho (n=zycho@a89-182-8-231.net-htp.de) |
| 20:10.33 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 20:10.34 | *** join/#htc-linux sean_d (n=sean@adsl-69-232-201-43.dsl.pltn13.pacbell.net) |
| 20:10.34 | *** join/#htc-linux woodyPL (n=woody@gateway/shell/blinkenshell.org/x-1f097ac9de48f2cd) |
| 20:10.48 | *** join/#htc-linux ChanServ (ChanServ@services.) |
| 20:10.49 | *** mode/#htc-linux [+o ChanServ] by irc.freenode.net |
| 20:11.28 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 20:13.37 | cr2 | ~ping dcordes_ |
| 20:13.38 | apt | pong dcordes_ |
| 20:13.56 | *** join/#htc-linux Xime (n=xime@bankize.net) |
| 20:15.45 | *** join/#htc-linux pH5 (n=ph5@e178206050.adsl.alicedsl.de) |
| 20:16.10 | *** join/#htc-linux pichurri (n=pichurri@194.230.146.32) |
| 20:16.44 | cr2 | BabelO: http://www.sony.net/Products/Linux/Download/DSC-G3.html |
| 20:18.12 | dzo | Mullins: yes,i'm here now. |
| 20:19.43 | Mullins | dzo: ah, I figuresd it out. I was building cupcake but just realised I need to use mkcramfs on the system folder |
| 20:21.22 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 20:21.50 | Mullins | dzo: There is no easy way to share the changes you make to cupcake dzo? The default build is not like yours |
| 20:22.18 | *** join/#htc-linux dcordes-x1 (n=zsirc@ip-90-186-157-47.web.vodafone.de) |
| 20:22.31 | dzo | ok, no problem. I didn't make those changes it was foobar, I'll pm him. |
| 20:22.43 | dcordes-x1 | cr2 pong |
| 20:23.20 | dzo | hi dcordes |
| 20:23.44 | dzo | got audio working nicely now on kaiser. |
| 20:24.28 | AstainHellbring | nice dzo |
| 20:24.51 | AstainHellbring | what is still needing to be worked on for kaiser now? |
| 20:25.33 | dzo | I've managed to trace power collapse so will work on that next. we need charging and battery status too. |
| 20:26.19 | cr2 | dzo: i've documented the full wince vreg api |
| 20:27.03 | cr2 | dzo: now i'm looking at the unknown clocks |
| 20:27.39 | dzo | cr2: good work, I think that is only used by newer devices though. |
| 20:27.59 | dzo | (if you mean the pcom interface) |
| 20:28.52 | cr2 | dzo: how do you control vregs on 7200 ? |
| 20:29.35 | *** join/#htc-linux Sti_0239 (n=Where_is@88.205-65-87.adsl-dyn.isp.belgacom.be) |
| 20:29.49 | cr2 | i mean this one: |
| 20:29.53 | cr2 | http://wiki.xda-developers.com/index.php?pagename=MSM_VREG |
| 20:30.12 | cr2 | 7200 devices have less clocks, but the api is still the same |
| 20:30.44 | cr2 | but you need to know which voltage is used for which device, and it varies wildly |
| 20:32.10 | cr2 | the 0-8 wince ids are available on titan |
| 20:33.25 | dzo | I can't trace pcom on 7200, may have to modify haret to trace 4K pages. |
| 20:33.45 | dzo | OK got to go now, bye.. |
| 20:34.49 | Mullins | cya later dzo |
| 20:35.40 | *** join/#htc-linux frysee (i=4d14b78a@gateway/web/ajax/mibbit.com/x-01dfc7bde6515be6) |
| 20:35.48 | cr2 | dcordes-x1: are you alive ? |
| 20:37.04 | *** join/#htc-linux miknix (n=miknix@sjcc176x121.sjccnet.com) |
| 20:37.50 | cr2 | maejrep[w]: i got an idea why the toshiba-like code is mixed with epson |
| 20:40.23 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 20:42.11 | *** join/#htc-linux Untouchab1e (n=Untoucha@82.147.51.146) |
| 20:42.44 | *** join/#htc-linux timebomb (n=tb@e176123067.adsl.alicedsl.de) |
| 20:49.38 | *** join/#htc-linux Sti_0239 (n=Where_is@88.205-65-87.adsl-dyn.isp.belgacom.be) |
| 20:49.55 | maejrep[w] | cr2: you mean in the spl? |
| 20:50.18 | maejrep[w] | like how it still writes to 150000, as well as 300/30c/324 ? |
| 20:50.25 | cr2 | maejrep[w]: yes |
| 20:50.50 | cr2 | maejrep[w]: maybe some regs are predefined in the mddi spec |
| 20:50.52 | *** join/#htc-linux chab7 (n=kvirc@212.92.4.114) |
| 20:50.59 | Zoolooc | hi folks |
| 20:51.23 | Zoolooc | seems like the kaiser will be a well-supported device after all? |
| 20:51.24 | cr2 | maejrep[w]: the 7200 mddi differs from 7201A, you can see it from kaisermddi vs. raphaelmddi |
| 20:51.42 | cr2 | Zoolooc: after all :) |
| 20:52.22 | cr2 | maejrep[w]: and we need to make audio work. it's the shame that we are behind 7x00 :) |
| 20:52.52 | Zoolooc | cr2: remember that pessimistic atmosphere some more than a year ago ;) ? |
| 20:53.37 | cr2 | Zoolooc: there were zero docs, and no androed |
| 20:53.58 | Zoolooc | very true |
| 20:54.42 | cr2 | Zoolooc: omap850 is older, but is still not in such a good shape |
| 20:55.23 | Zoolooc | hacking sometimes goes mysterious ways |
| 20:57.26 | cr2 | maejrep[w]: no, i don't see any new clocks. only 0xe0 |
| 20:57.56 | cr2 | which is not an MD/NS clock |
| 20:59.04 | cr2 | maejrep[w]: so we have 5 clocks + 4 sd clocks |
| 20:59.32 | tmzt | why doesn't g1 adsp work? |
| 20:59.48 | cr2 | pwm,i2c,mddi,sdc1,sdc2,sdc3,sdc4,uart1dm,uart2dm |
| 21:00.27 | cr2 | tmzt: audioParam differ even between vogue/kaiser/titan. we need to check our values |
| 21:00.49 | tmzt | is there still a codec connected to msm? |
| 21:01.30 | cr2 | maejrep[w]: there is also the uart clock 0xc0 (unused), and the strange 0xe0 clock without "enable" bit |
| 21:01.44 | cr2 | i don't know if the 0xe0 clock is used at all |
| 21:02.02 | *** join/#htc-linux miknix_ghost (n=miknix@12.104.145.50) |
| 21:02.09 | tmzt | is this the 19.x clock? |
| 21:02.32 | cr2 | dont'know. i'll check the dump |
| 21:02.53 | cr2 | a86000e0 | 00000031 |
| 21:03.18 | cr2 | 0xc0 looks like a usual a-clock |
| 21:03.22 | cr2 | a86000c0 | 00000a00 |
| 21:04.48 | cr2 | 1,5,3,6,7,b |
| 21:06.30 | cr2 | maejrep[w]: the 0x1c pcom call looks interesting |
| 21:08.13 | cr2 | 0,a,c |
| 21:08.37 | cr2 | =0,1,5,3,6,7,a,b,c |
| 21:10.56 | cr2 | 0 is bit 0x200, 1 is e0 10 20, 3 is e0 1000 2000, 5 is uart2dm |
| 21:11.35 | tmzt | did maejrep's notes about mddi id work? |
| 21:13.42 | cr2 | 6 is sdc1, 7 is sdc2, a is mddi, c is something strange |
| 21:13.50 | cr2 | which notes ? |
| 21:14.30 | cr2 | for mddi clk there is 200 and 800 |
| 21:14.51 | cr2 | 200+800=a00 |
| 21:15.06 | cr2 | that looks good |
| 21:15.32 | dcordes | cr2: only semi |
| 21:15.51 | cr2 | ok. so the a-clocks don't set the MSM_CLK "pseudo"-enable bit |
| 21:17.46 | cr2 | maejrep[w]: so they don't need the MSM_CLK mask |
| 21:18.26 | *** join/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 21:19.51 | cr2 | maejrep[w]: i think that any further progress may be done only by disassembling amss. or looking at the 7201A docs |
| 21:20.47 | cr2 | but since wince does not use them, we will be able to avoid controlling them too. |
| 21:24.39 | cr2 | maejrep[w]: some clock are obviusly always enabled. like EBI1 and EBI2 ;) |
| 21:27.15 | *** part/#htc-linux yoyey (n=yoann@lns-bzn-49f-81-56-185-87.adsl.proxad.net) |
| 21:27.31 | *** join/#htc-linux dwaradzyn (n=chatzill@chello089079197022.chello.pl) |
| 21:28.23 | dwaradzyn | cr2: some 20 hours ago you asked for someone with blackstone. i'm here if you still need it |
| 21:30.58 | cr2 | dwaradzyn: yes. do you have the wince dmesg ? |
| 21:31.15 | dwaradzyn | not yet |
| 21:31.29 | cr2 | on umts phones it's usually at 0x17200000 (1MB) |
| 21:31.38 | cr2 | can you check ? |
| 21:33.05 | dcordes | hi dwaradzyn |
| 21:35.44 | exco | is usb already working in android on vogue/kaiser? |
| 21:36.04 | cr2 | exco: dont think so. but don<'t really know |
| 21:36.29 | cr2 | exco: working wifi will be much better to have |
| 21:37.42 | exco | yes, but until then :-) |
| 21:43.17 | dcordes | exco: the problem is msm7?00 doesn't have the same hsusb controller as found in the mms7201a boards like trout |
| 21:43.22 | dcordes | which has available sources |
| 21:43.51 | exco | that's a shame |
| 21:53.58 | dcordes | maejrep: it only shows memory addresses and stack overflow bla |
| 21:54.21 | dcordes | cache refill kmen |
| 22:17.12 | cr2 | dwaradzyn: fall asleep ? :) |
| 22:17.52 | *** join/#htc-linux MethoS (n=lem@host-091-096-211-104.ewe-ip-backbone.de) |
| 22:18.10 | dwaradzyn | cr2: http://pastebin.com/m7820dee0 is it ok? |
| 22:18.55 | cr2 | dwaradzyn: thanks. looks very good |
| 22:19.23 | dwaradzyn | there was more than 1mb of that |
| 22:19.23 | cr2 | dwaradzyn: can you do a reset, and dump it again ? |
| 22:19.29 | cr2 | more ? |
| 22:21.31 | dwaradzyn | mistake, no more than 1 mb :) |
| 22:24.24 | cr2 | athena/hermes had 3MB |
| 22:24.29 | cr2 | what a waste ;) |
| 22:27.54 | dcordes | cr2: any idea why newer raph kernel panics on kovsky? |
| 22:30.41 | cr2 | dcordes: it half-panics on raph itself. do you have a backtrace ? |
| 22:31.52 | cr2 | dwaradzyn: does the ts work for you ? |
| 22:31.54 | dcordes | yep |
| 22:32.02 | cr2 | paste |
| 22:32.15 | dcordes | copy all the addresses and stuff manually? |
| 22:32.23 | dcordes | it's a lot of data |
| 22:33.05 | dwaradzyn | cr2: screen is messy, not legible |
| 22:33.47 | cr2 | dwaradzyn: ok. i just see that the ts config is different from raph |
| 22:33.54 | cr2 | from the logs |
| 22:34.22 | dwaradzyn | pastebin crashed on 1mb paste :( |
| 22:35.08 | cr2 | dwaradzyn: bzip2+uuencode/mimencode ? |
| 22:36.22 | dwaradzyn | http://rapidshare.com/files/186819347/wince_dmesg_blackstone.zip |
| 22:37.23 | cr2 | ok |
| 22:37.30 | cr2 | 22:34:49 [D:TP] pTsscRegs->tssc_ctl=0x107d(b) |
| 22:37.30 | cr2 | 22:34:49 [D:TP] pTsscRegs->tssc_status=0x700(b) |
| 22:39.39 | NetRipper | cr2, the other panel of raph is the epson? |
| 22:39.59 | cr2 | NetRipper: only 800. 100 is sane :) |
| 22:40.04 | NetRipper | ok |
| 22:40.32 | cr2 | NetRipper: i'll go through 100 anyway. step by step |
| 22:40.50 | cr2 | need to 'sed' the register names instead of the numbers there |
| 22:41.01 | cr2 | so it's more readable |
| 22:41.17 | NetRipper | cr2, you're going through the code you mean? |
| 22:43.55 | cr2 | i'll go |
| 22:44.03 | cr2 | we need to compare it with epson too |
| 22:44.16 | cr2 | this the the last big RE project left :) |
| 22:44.40 | dcordes | what is the interesting part in a panic traceback? |
| 22:45.25 | NetRipper | why the last big? |
| 22:45.25 | NetRipper | :) |
| 22:46.00 | NetRipper | oh regarding this phone you mean |
| 22:46.01 | NetRipper | :P |
| 22:48.44 | cr2 | NetRipper: everything else is more of less known |
| 22:49.06 | cr2 | NetRipper: dzo made sound working on kaiser |
| 22:49.15 | NetRipper | nice |
| 22:49.29 | cr2 | you may check the data needed for raph |
| 22:50.00 | XD | whats the latest on andriod for raph500? |
| 22:50.01 | NetRipper | i first need to sort out maejrep's patch |
| 22:50.11 | NetRipper | and apply it to git |
| 22:52.32 | cr2 | 22:35:23 [K] !!! GetBatteryIDDetection, HTC_SMEM_BATTERY_ID = 655 |
| 22:52.48 | cr2 | 22:35:23 [K] !!! GetBatteryIDDetection, HTC_SMEM_BATTERY_ID = 681 |
| 22:52.55 | cr2 | strange |
| 22:53.21 | cr2 | NetRipper: i have some comments there. and some things need to be fixed. |
| 22:53.39 | cr2 | XD: the same as on 800. |
| 22:54.06 | cr2 | XD: i think nobody did anything with android, because all the effort goes into the kernel |
| 22:54.14 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 22:56.24 | dwaradzyn | cr2: i got it connected to usb, maybe thats the second battery :P |
| 22:57.56 | maejrep[w] | I was never able to find battery ID when I tried |
| 22:58.03 | maejrep[w] | smem is going to be fun to work with |
| 22:58.37 | dcordes | what is the half kernel panic you get on raphael? |
| 22:59.46 | maejrep[w] | who? |
| 22:59.51 | maejrep[w] | and what's a half kernel panic? |
| 22:59.52 | cr2 | dcordes: the dmesg posted by maejrep[w] |
| 23:00.14 | cr2 | maejrep[w]: you need to call pcom_wince to get the battery data into smem |
| 23:00.36 | maejrep[w] | right, 0x8a / 0x8b? |
| 23:00.40 | maejrep[w] | the one wince does every 10 seconds |
| 23:01.22 | maejrep[w] | but wouldn't it make sense for it to remain there? It seems odd for it to only be in smem long enough for it to be read once |
| 23:01.31 | dcordes | well I have a full panic on the x1. right after bootup |
| 23:01.44 | cr2 | maejrep[w]: yes, the 10second irq |
| 23:01.46 | maejrep[w] | whats the panic message? |
| 23:01.48 | NetRipper | oh |
| 23:01.50 | NetRipper | this is nice |
| 23:02.27 | cr2 | maejrep[w]: the clk code should not set the bits for a-clocks |
| 23:02.58 | cr2 | maejrep[w]: i've edited the MSM_CLK already. i consider it finished for practical purposes. |
| 23:03.18 | maejrep[w] | should not set which bits? |
| 23:03.23 | maejrep[w] | in glblclkena ? |
| 23:03.31 | maejrep[w] | or the Md/Ns regs? |
| 23:03.33 | cr2 | hm. maybe the uart2DM divisors need to be studied after you'll enable the hs serial |
| 23:03.49 | cr2 | MD/NS set the bit, but non-MD/NS do not. |
| 23:04.10 | dcordes | maejrep[w]: where is the panic messages? it's a full page of output |
| 23:04.15 | maejrep[w] | the clkena bit? |
| 23:04.22 | cr2 | maejrep[w]: yes |
| 23:04.35 | maejrep[w] | dcordes: the first line should say why it panicked (ie, "NULL pointer dereference") |
| 23:04.42 | maejrep[w] | then the backtrace will tell you *where* |
| 23:04.45 | dcordes | ah ok |
| 23:04.47 | cr2 | maejrep[w]: there are also several minor things to be fixed in your patch |
| 23:04.52 | dcordes | let me boot again |
| 23:04.58 | maejrep[w] | cr2: which patch? |
| 23:05.09 | maejrep[w] | .27? |
| 23:05.37 | cr2 | the 15" 3x4 lcd is so much better than the lame 1024x600 ;) |
| 23:05.59 | maejrep[w] | @_@ |
| 23:06.23 | dcordes | maejrep[w]: the addresses of the traceback thing are printed very slowly |
| 23:06.31 | maejrep[w] | I'm on a 20" mac with a 22" ws 2nd monitor at work, and at home I have a dualhead, 22" ws and 26" ws ;x |
| 23:06.33 | dcordes | so it seems to be some corruption that slows down the system |
| 23:06.40 | maejrep[w] | dcordes: that's htc_fb_console |
| 23:06.46 | NetRipper | dcordes, the htc_fb_console slows down intentially |
| 23:06.51 | maejrep[w] | it deliberately puts a 1s delay between each printk |
| 23:06.56 | cr2 | maejrep[w]: .27 |
| 23:06.57 | maejrep[w] | and the kernel is doing a separate printk() for each address |
| 23:07.04 | maejrep[w] | thus 1s between each |
| 23:07.06 | NetRipper | maejrep[w], that's normal |
| 23:07.11 | NetRipper | uh |
| 23:07.12 | NetRipper | oops |
| 23:07.13 | NetRipper | nvm |
| 23:07.14 | NetRipper | :) |
| 23:07.15 | maejrep[w] | i know ;) |
| 23:07.30 | cr2 | 26" ? what is the pixel count/dpi ? |
| 23:07.30 | NetRipper | cr2, let me know which minor things, as im preparing the patch for igt |
| 23:07.36 | dcordes | maejrep[w]: stack: .. ? |
| 23:07.40 | maejrep[w] | dcordes: yep |
| 23:07.46 | NetRipper | git* |
| 23:07.48 | maejrep[w] | the first line there will say what function it was in |
| 23:08.01 | cr2 | NetRipper: can you pastebin the ptch ? |
| 23:08.09 | NetRipper | maejrep[w], did earlier |
| 23:08.11 | maejrep[w] | cr2: eh. don't recall off hand.. but it's a westinghouse, so the quality is only so-so |
| 23:08.28 | NetRipper | http://www.privatepaste.com/041X08BBhM |
| 23:08.41 | cr2 | maejrep[w]: the size only matters when the pixel count is appropriate |
| 23:08.50 | maejrep[w] | i agree |
| 23:09.16 | dcordes | maejrep[w]: after stack: are only addresses like 10 lines. and then there is ...cache_alloc_refill+0x0/0x5d8...kmem_cache_alloc..... |
| 23:09.17 | maejrep[w] | it can do 1920x1080 |
| 23:09.23 | maejrep[w] | the only issue I have with it is delay |
| 23:09.24 | cr2 | on the other hand, vga on raph is an overkill :) |
| 23:09.38 | cr2 | ok |
| 23:09.55 | maejrep[w] | dcordes: those are functions (cache_alloc_refill, etc) |
| 23:10.00 | dcordes | with the wvga it's a whole new world of console reading |
| 23:10.21 | cr2 | i have an old crt with 2048x1536@75Hz. it's great for google maps |
| 23:10.23 | maejrep[w] | need to find the top-most function to know where the panic happened at, then follow it down to see what is calling it in order to find where the error is |
| 23:10.37 | maejrep[w] | nice |
| 23:10.42 | NetRipper | maejrep[w], your patch removes clock.o from the Makefile... does the clock-wince.o replace clock.o fully? |
| 23:11.28 | maejrep[w] | yes |
| 23:11.36 | maejrep[w] | clock.c is only defines |
| 23:11.41 | cr2 | #define MSM_SMI_BASE 0x00000000 |
| 23:11.44 | maejrep[w] | rather, an enum of clocks |
| 23:12.00 | cr2 | #define MSM_EBI1_BASE 0x10000000 |
| 23:12.00 | maejrep[w] | clock-7x01a.c is what clock-wince was copied from |
| 23:12.14 | NetRipper | maejrep[w], no, clock.c is an implementation, clock-7x01a.c are only defines |
| 23:12.18 | dcordes | maejrep[w]: before the stack: line there is a line "Process swapper (pid: 0, stack limit = ... |
| 23:12.22 | cr2 | i think these should go into an msm*io.h header |
| 23:12.48 | NetRipper | cr2, arent they already in msm_io.h? |
| 23:12.50 | maejrep[w] | cr2: they moved those |
| 23:12.52 | maejrep[w] | (google) |
| 23:13.09 | maejrep[w] | NetRipper: no, some of the defines were moved into the files that use them |
| 23:13.16 | NetRipper | ok |
| 23:13.31 | cr2 | NetRipper: can you remove the &smc91x_device - related things ? |
| 23:13.42 | maejrep[w] | cr2: I already did, in my patch, no |
| 23:13.46 | maejrep[w] | +? |
| 23:14.05 | cr2 | +vreg_mmc = vreg_get(0, "mmc"); |
| 23:14.06 | cr2 | +rc = vreg_enable(vreg_mmc); |
| 23:14.18 | cr2 | raph/diam do not use "mmc" vreg |
| 23:14.33 | maejrep[w] | I didn't change that |
| 23:14.52 | dcordes | maejrep[w]: maybe I need to define a mem value in cmdline? |
| 23:15.05 | cr2 | we should create a list of vregs used by each phone, for what purpose |
| 23:15.08 | maejrep[w] | dcordes: what's the stack? |
| 23:15.20 | maejrep[w] | cr2: odd thing is it "just works" |
| 23:15.37 | maejrep[w] | so maybe it doesn't matter? the vreg is already on from wince? |
| 23:15.41 | cr2 | maejrep[w]: raph config is the same as g1: gp6 for sd (afair) |
| 23:15.53 | *** join/#htc-linux RZK333 (n=rzk@daemonet.ru) |
| 23:16.04 | dcordes | Stack (0xc029ec8 to 0xc0294000) |
| 23:16.08 | maejrep[w] | cr2: btw, off topic.. do you know of anything that would cause the phone to reboot everytime it goes to sleep? :( |
| 23:16.09 | cr2 | maejrep[w]: wifi is more difficult. g1 uses "mmc", raph/diam use msme+msmp |
| 23:16.16 | NetRipper | can you pastebin your .config maejrep[w]? |
| 23:16.19 | NetRipper | for comparison |
| 23:16.28 | maejrep[w] | cr2: yeah will be good to have those things documented :) |
| 23:16.41 | cr2 | maejrep[w]: corrupted smem ? |
| 23:16.56 | dcordes | maejrep[w]: is that the info you asked for? there is more data but it's hard to copy manually |
| 23:17.11 | cr2 | maejrep[w]: the ascii "reasons" need an own page too... |
| 23:18.50 | cr2 | lol |
| 23:18.55 | cr2 | 22:35:23 [K] IsDoForceDischargeRoutine_bMainBatteryReplaced - 0x1 BatteryVoltage-3972)!!! |
| 23:19.37 | cr2 | uh |
| 23:19.42 | cr2 | [K] +mddi_Change_Speed=814 |
| 23:19.43 | cr2 | [K] -mddi_Change_Speed=a41 |
| 23:19.43 | cr2 | [K] +mddi_Change_Speed=a41 |
| 23:19.43 | cr2 | [K] -mddi_Change_Speed=a19 |
| 23:20.19 | maejrep[w] | NetRipper: http://www.privatepaste.com/631y4WkYZw |
| 23:20.23 | NetRipper | maejrep[w], thx |
| 23:20.48 | *** join/#htc-linux lavender-t (n=hzhuang@c-24-17-204-47.hsd1.wa.comcast.net) |
| 23:21.02 | maejrep[w] | cr2: yeah, the reasons would be nice, but I can't even get it to trigger a reboot yet, or a power down for that matter |
| 23:21.23 | lavender-t | good afternoon :) |
| 23:21.25 | maejrep[w] | cr2: corrupted smem would cause it to reboot on suspend? :x |
| 23:21.26 | dcordes | maejrep[w]: more of these addresses are needed? |
| 23:21.27 | NetRipper | it does shut down the cpu though, as everything stops responding ;) |
| 23:21.42 | maejrep[w] | dcordes: I meant the stack of function calls |
| 23:21.52 | maejrep[w] | starting at the top, going down, list the function names |
| 23:22.06 | dcordes | with two letters leading? |
| 23:22.17 | maejrep[w] | [18:09:16] <dcordes> maejrep[w]: after stack: are only addresses like 10 lines. and then there is ...cache_alloc_refill+0x0/0x5d8...kmem_cache_alloc..... <-- ie, "cache_alloc_refill", etc |
| 23:22.18 | cr2 | maejrep[w]: suspend is rather complex procedure, it reconfigures most gpios and does a lot of weird stuff |
| 23:22.23 | dcordes | I will try putting mem=128 now first |
| 23:22.34 | maejrep[w] | dcordes: is it 128M contiguous? |
| 23:22.36 | cr2 | maejrep[w]: suspend is probably one of the most complex routines |
| 23:22.38 | NetRipper | dcordes, you should rather decrease memory |
| 23:22.49 | dcordes | I use no value now |
| 23:22.55 | NetRipper | use mem=64M |
| 23:22.58 | maejrep[w] | cr2: is that something a hard reset and/or spl flash might "correct" ? |
| 23:23.00 | dcordes | ok |
| 23:23.12 | *** join/#htc-linux Sti_0239 (n=Where_is@88.205-65-87.adsl-dyn.isp.belgacom.be) |
| 23:23.20 | maejrep[w] | it only started happening this weekend, and probably only when i started working on .27 :( |
| 23:23.23 | cr2 | maejrep[w]: spl flash - no, hard reset maybe |
| 23:23.43 | maejrep[w] | i always leave it plugged in when I'm doing development, so I never noticed it |
| 23:23.46 | NetRipper | maejrep[w], it reboots in wince on suspend as well? |
| 23:23.56 | maejrep[w] | but once it's off the charger, it'll reboot every 3 minutes |
| 23:24.00 | maejrep[w] | NetRipper: yup |
| 23:24.04 | NetRipper | maejrep[w], ouch |
| 23:24.12 | maejrep[w] | it gets to wince, waits 2min, goes to sleep, and reboot |
| 23:24.34 | cr2 | maejrep[w]: i think we need to fix the vreg* asap, bcsause it can have unpleasant longterm effects |
| 23:24.46 | maejrep[w] | like making my phone reboot? :D |
| 23:24.56 | NetRipper | lol |
| 23:24.58 | cr2 | maejrep[w]: hardreset as a first action |
| 23:25.10 | maejrep[w] | ok, will do that tonight |
| 23:25.43 | maejrep[w] | ok I need to get back to work |
| 23:25.46 | maejrep[w] | will be lurking |
| 23:25.48 | lavender-t | are you talking about .27 ? |
| 23:26.24 | dcordes | oh that fixed the bug |
| 23:26.54 | NetRipper | dcordes, good |
| 23:27.18 | dcordes | why is that needed? can't the kernel use the full mem? |
| 23:27.37 | NetRipper | dcordes, no, as some part of the mem is used by arm9 |
| 23:27.42 | cr2 | dcordes: the g1-type memory layout is fixed, and hardcoded |
| 23:27.51 | *** part/#htc-linux Balsat (n=kll@87.72.13.87) |
| 23:28.17 | cr2 | hehe. i need to create the DreamMemoryMap page |
| 23:28.26 | cr2 | the Dream_GPIO is already there |
| 23:28.59 | cr2 | NetRipper: the vibra pause on wince is 0xc8 :) |
| 23:29.07 | NetRipper | pause? |
| 23:29.13 | cr2 | between on and off |
| 23:29.18 | cr2 | ative time |
| 23:29.23 | NetRipper | ohh.. so it restarts faster? |
| 23:29.24 | cr2 | s/at/act/ |
| 23:29.37 | cr2 | it runs for 0xc8 msec |
| 23:29.41 | dcordes | msmfb_start_dma printk spamming |
| 23:29.53 | cr2 | debug messages |
| 23:29.53 | NetRipper | cr2, when doing what? |
| 23:30.14 | cr2 | NetRipper: the standard wince operation at startup |
| 23:30.22 | NetRipper | cr2, isn't that spl? |
| 23:30.34 | cr2 | sorry, yes |
| 23:30.37 | NetRipper | ok |
| 23:30.39 | cr2 | spl |
| 23:30.55 | NetRipper | i prefer two short ones ;p |
| 23:31.00 | cr2 | :) |
| 23:31.10 | NetRipper | im stubborn |
| 23:32.20 | *** join/#htc-linux balsat (n=kra@87.72.13.87) |
| 23:33.12 | lavender-t | netripper, were you guys talking about booting .27 ? |
| 23:33.27 | NetRipper | lavender-t, we're porting to .27.. there are some issues |
| 23:33.58 | cr2 | lavender-t: it boots but there are many issues with the lcd init |
| 23:34.07 | lavender-t | cool. i just compiled it with maejrep's diff sent last night |
| 23:34.57 | lavender-t | i mean for diam. but it didnt even hit the vibration yet and hang. |
| 23:35.17 | NetRipper | lavender-t, the diff is not good for diam |
| 23:35.31 | NetRipper | only raphael |
| 23:35.35 | lavender-t | did the raph work ? |
| 23:35.41 | NetRipper | yes |
| 23:35.46 | NetRipper | partially |
| 23:35.53 | NetRipper | diamond will too, just wait for git |
| 23:35.55 | lavender-t | i actually had to go in and fix some code to make diam even to compile |
| 23:36.05 | NetRipper | qdsp? |
| 23:36.09 | NetRipper | adsp i mean |
| 23:36.12 | lavender-t | yep |
| 23:36.19 | NetRipper | known issue |
| 23:36.23 | lavender-t | also board-htcdiamond.c |
| 23:36.31 | NetRipper | yea it's not been updated |
| 23:36.38 | lavender-t | some functions are changed, including gpio init |
| 23:36.46 | cr2 | lavender-t: you have diam800 ? |
| 23:36.59 | lavender-t | cr2: diam110 |
| 23:37.14 | cr2 | lavender-t: yes, some raph800 gpios are hardcoded in the patch |
| 23:37.15 | cr2 | ok |
| 23:37.28 | cr2 | 110 ? do you know the differences to 100 ? |
| 23:37.58 | lavender-t | 110 is less sexier than 100. a big bulk battery to make americans happy |
| 23:37.58 | NetRipper | there's a diam110? man.. :) |
| 23:38.13 | maejrep[w] | [18:29:37] <cr2> it runs for 0xc8 msec <-- meaning, you can set 0xc8 to 100, then send 0x17 for vibra on, and not have to worry about turning it back off manually? |
| 23:38.16 | cr2 | NetRipper: edit the wiki |
| 23:38.37 | NetRipper | cr2, sir yes sir ;) |
| 23:38.47 | cr2 | maejrep[w]: wince uses only the generic api 0x15/0x16 |
| 23:39.00 | cr2 | lol |
| 23:39.06 | lavender-t | it has the us 3g bands |
| 23:39.13 | maejrep[w] | cr2: but is that what you mean by c8? |
| 23:39.17 | NetRipper | lavender-t, on which msmsdcc_id is your sd card? |
| 23:39.47 | cr2 | maejrep[w]: vibra on, msleep 0xc8, vibra off |
| 23:39.47 | lavender-t | 2 |
| 23:39.58 | NetRipper | lavender-t, ok and do you know abou twifi? |
| 23:40.02 | maejrep[w] | there's a pmic-vibra-on/off dex cmd, plus a 'vibra motor on/off' cmd (plus a generic pmic reg on/off) |
| 23:40.13 | lavender-t | no idea now. |
| 23:40.17 | NetRipper | lavender-t, ok |
| 23:40.27 | maejrep[w] | cr2: oh, so 0xc8 is the number of ms that spl sleeps? it's not a built in sleep? |
| 23:40.27 | cr2 | maejrep[w]: motor on/off is not used |
| 23:40.29 | lavender-t | but i can do some research |
| 23:40.34 | maejrep[w] | cr2: but it works :) |
| 23:40.55 | NetRipper | lavender-t, it's probably on SDC1, but if you know for sure, can you remove the ? at the bottom of the page here? http://wiki.xda-developers.com/index.php?pagename=MSM_SDIO |
| 23:41.25 | cr2 | maejrep[w]: yes. dzo says that if you change the vibra "voltage", then i'l lbe "custom vibra" :) |
| 23:41.33 | maejrep[w] | lol |
| 23:41.36 | NetRipper | lol |
| 23:41.42 | maejrep[w] | that sounds fun ;D~ |
| 23:41.42 | NetRipper | don't let the women know |
| 23:41.45 | maejrep[w] | haha |
| 23:42.26 | dcordes | lol onscreen keyboard orientation changed after opening the keyboard |
| 23:42.49 | NetRipper | yes lol |
| 23:42.50 | NetRipper | isn't it neat |
| 23:42.51 | NetRipper | ;) |
| 23:43.18 | NetRipper | maejrep[w], btw, your "sd card slot detect" gpio, is my "keyboard slide" gpio ;) |
| 23:43.30 | *** join/#htc-linux MethoS (n=lem@host-091-096-211-104.ewe-ip-backbone.de) |
| 23:43.30 | maejrep[w] | rofl |
| 23:43.36 | maejrep[w] | that could get annoying I'm sure :) |
| 23:43.39 | NetRipper | yes |
| 23:43.41 | NetRipper | when i open my keyboard |
| 23:43.45 | NetRipper | my mmc goes away |
| 23:43.48 | maejrep[w] | rofl |
| 23:43.59 | maejrep[w] | shouldn't that be the other way around? |
| 23:44.01 | dcordes | ah that is expected? so x1 keyboard slide gpio is same as on raph |
| 23:44.08 | NetRipper | maejrep[w], the sd card slot detect is inversed |
| 23:44.11 | maejrep[w] | oh |
| 23:44.12 | maejrep[w] | right |
| 23:44.14 | cr2 | NetRipper: i've forgot, did you find the stylus gpio ? |
| 23:44.23 | NetRipper | cr2, no i havent looked for it |
| 23:44.28 | NetRipper | im already busy on 100 things |
| 23:44.31 | cr2 | ok |
| 23:44.32 | maejrep[w] | cr2: I noted it on raph800 |
| 23:44.35 | maejrep[w] | it's on the gpio page |
| 23:44.39 | NetRipper | my todo list only grows ;) |
| 23:44.58 | cr2 | put it online :) |
| 23:45.11 | NetRipper | cr2, how should stylus gpio be reported? via keypad? |
| 23:45.18 | NetRipper | or seperate driver? |
| 23:45.49 | cr2 | no idea. it's more important which event it should send |
| 23:45.55 | maejrep[w] | NetRipper: put your todo list on the wiki |
| 23:46.27 | NetRipper | maejrep[w], it's a mess right now.. i'll make a todo list on wiki later |
| 23:46.28 | maejrep[w] | NetRipper: i would consider it an EV_SW |
| 23:46.41 | NetRipper | EV_SW turns landscape/portrait |
| 23:46.43 | NetRipper | on android |
| 23:47.02 | maejrep[w] | NetRipper: no, EV_SW is the type |
| 23:47.06 | maejrep[w] | SW_LID turns it landscape |
| 23:47.07 | NetRipper | oh |
| 23:47.09 | NetRipper | ah ok |
| 23:47.19 | maejrep[w] | we can make it whatever other SW_* types there are that we want |
| 23:47.22 | NetRipper | just added a todo to add a todo on wiki |
| 23:47.26 | maejrep[w] | (ie, SW_POWER!) |
| 23:47.31 | maejrep[w] | haha |
| 23:47.48 | dcordes | NetRipper: make sure you don't end up with an infinite loop |
| 23:48.18 | NetRipper | dcordes, on what? |
| 23:48.19 | maejrep[w] | todo list: 1) see todo list |
| 23:48.21 | NetRipper | ah |
| 23:48.32 | NetRipper | yes i'll make sure not to add that todo to the wiki too;) |
| 23:50.22 | lavender-t | cr2: the stylus in my diam100 is 37 |
| 23:50.28 | dcordes | I think x1 i2c read/write is at a different location. how can I locate it? |
| 23:52.14 | cr2 | dcordes: you are my hero :) now i've understood how they do pwm. |
| 23:52.19 | NetRipper | maejrep[w], do you think the gpio differences are GSM<->CDMA or worse? |
| 23:52.31 | NetRipper | pwm? |
| 23:52.50 | maejrep[w] | between x1 and raph? |
| 23:52.55 | cr2 | dcordes: dump mmu 0xa9900000 2 |
| 23:53.01 | NetRipper | maejrep[w], no, between raph and raph |
| 23:53.03 | dcordes | ok |
| 23:53.20 | NetRipper | maejrep[w], raph gsm and raphcdma (i.e. raph100/110 vs raph500/800) |
| 23:53.33 | cr2 | lavender-t: ok |
| 23:53.33 | maejrep[w] | i think its mostly 7200 vs 7500 |
| 23:53.41 | maejrep[w] | 720x(x) vs 750x(x) |
| 23:53.45 | NetRipper | maejrep[w], ah yes that's a better way of putting it |
| 23:53.46 | NetRipper | :) |
| 23:54.01 | NetRipper | maejrep[w], i think i'll add the _CDMA variants to use the same boardfile |
| 23:54.03 | maejrep[w] | since raph cdma matches vogue pretty closely |
| 23:54.07 | NetRipper | and update all #if's |
| 23:54.14 | maejrep[w] | strange thing about it though is kaiser .. aren't most kaisers gsm? |
| 23:54.22 | maejrep[w] | is kaiser 720x also? |
| 23:54.31 | cr2 | maejrep[w]: you may detect 1A vs 0A too |
| 23:54.55 | cr2 | maejrep[w]: the bit in a 0x270 reg afair. it's in wiki |
| 23:55.01 | NetRipper | maejrep[w], as i need some way to make it work for both raph100 and raph800, regarding your gpio's |
| 23:55.18 | cr2 | NetRipper:pdata |
| 23:55.25 | NetRipper | cr2, pdata? |
| 23:55.48 | cr2 | NetRipper: and the vreg list name should be also in pdata. swetland bashing is in coming :) |
| 23:56.13 | cr2 | NetRipper: yes, driver-specific data |
| 23:56.22 | dcordes | 9a000000 | 00000000 | 1MB section | CB AP=1 T=7 |
| 23:56.22 | dcordes | ba000000 | 00000000 | 1MB section | AP=1 T=7 |
| 23:56.22 | dcordes | f0400000 | 00000000 | 1MB section | AP=0 D=f |
| 23:56.44 | maejrep[w] | hmm |
| 23:56.47 | NetRipper | cr2, how does that work? |
| 23:56.49 | maejrep[w] | dcordes: is that your i2c area? |
| 23:57.00 | maejrep[w] | my i2c is at b2300000 (virtual) |
| 23:57.03 | cr2 | dcordes: ? it should list the virtal addresses for 0xa9900000 |
| 23:57.36 | cr2 | maejrep[w]: he does not se |
| 23:57.41 | cr2 | e anything there |
| 23:58.11 | maejrep[w] | should be easy to find in spl |
| 23:58.14 | dcordes | cr2: that? cp15: r1=0085387f r2=103e0000 r3=00000001 r13=2c000000 |
| 23:58.27 | NetRipper | cr2, i think i'll do it the easy way now.. when we have the first (reasonably proper) commit, we can beautify things |
| 23:59.36 | maejrep[w] | NetRipper: that's what I did :P |
| 23:59.45 | cr2 | maejrep[w]: wince kernel/drivers do multiple ioremaps |
| 23:59.53 | lavender-t | my diam100 maps a9900000 to b2300000 and 92300000 |
| 23:59.58 | cr2 | NetRipper: ok |
