| 00:04.26 | *** join/#htc-linux cr2 (n=cr2@ip-90-187-226-68.web.vodafone.de) |
| 00:04.35 | cr2 | tmzt: snd->snd_epts = (struct msm_snd_endpoints *)pdev->dev.platform_data; |
| 00:04.52 | tmzt | yes |
| 00:04.55 | tmzt | but there just integers |
| 00:05.03 | cr2 | how they are defined for g1 ? |
| 00:05.12 | cr2 | i doubt that we define them |
| 00:05.31 | tmzt | I tried the ones from trout |
| 00:05.42 | tmzt | I don't think rpc was working then though |
| 00:06.28 | cr2 | we have 1 and 0xd |
| 00:06.45 | cr2 | at least i've seen them in rpccall log |
| 00:07.19 | cr2 | this looks ok |
| 00:07.23 | cr2 | 633 SND(0, "HANDSET"), |
| 00:07.24 | cr2 | 634 SND(1, "SPEAKER"), |
| 00:07.43 | cr2 | there is no msm_snd because there are no SND ;) |
| 00:08.10 | tmzt | ah |
| 00:08.18 | cr2 | 644 SND(13, "HTC BH M100"), |
| 00:08.20 | tmzt | really? |
| 00:08.23 | cr2 | this is 0xd |
| 00:08.27 | tmzt | how does it enumerate? |
| 00:08.39 | cr2 | [02:04] <cr2> tmzt: snd->snd_epts = (struct msm_snd_endpoints *)pdev->dev.platform_data; |
| 00:08.49 | tmzt | those endpoints are related to acoustic I think |
| 00:09.12 | cr2 | it has an ioctl returning the number of endpoints, and *char info |
| 00:09.28 | cr2 | well, it's your domain :) |
| 00:10.14 | cr2 | i need to try playing to headset, and recording. from headset. |
| 00:10.39 | tmzt | bluetooth has to be setup first |
| 00:10.50 | cr2 | 644 SND(13, "HTC BH M100"), |
| 00:11.00 | tmzt | BH M100? |
| 00:11.03 | cr2 | this seems to be the standard headset. at least for raph100 |
| 00:11.25 | tmzt | they use this instead of routing? |
| 00:12.32 | cr2 | The HTC BH M100 has everything you need in a Bluetooth headset. |
| 00:12.36 | cr2 | strange |
| 00:13.04 | cr2 | maybe i've looked at somebodies else rpccall smem |
| 00:13.39 | tmzt | I think it might use that if it doesn't recognize the headset |
| 00:13.50 | cr2 | tmzt: you call an rpc for routing. |
| 00:14.04 | cr2 | ok |
| 00:14.11 | tmzt | then what is endpoint actually used for? |
| 00:14.20 | cr2 | but i think that we may just take the g1 list |
| 00:14.41 | tmzt | I asked swetland about it last year and the response was it was tuned for those headsets |
| 00:14.57 | cr2 | you call an ioctl on msm_snd and it sends an rpc |
| 00:15.19 | cr2 | the "tuned" audioparams are loaded into sram |
| 00:15.24 | tmzt | yeah |
| 00:15.28 | cr2 | s/sram/smem/ |
| 00:15.52 | cr2 | AudioPara* and HTC acoustic |
| 00:19.28 | cr2 | ok, i'll leave it for tomorrow/today |
| 00:19.44 | cr2 | also the rfkill, and the BT alt gpios patch. |
| 00:19.48 | cr2 | good night |
| 00:27.31 | Kevin2 | tmzt: Does the patch at http://dpaste.com/60982/ help? If you have a haret log of a session with "watch gpios" in it, then you can run the new tool: ./testdump.py < haretlog -- and it will dump the gpio registers at the end. |
| 00:28.52 | tmzt | maybe, that looks about right |
| 00:29.23 | tmzt | I can convert that to what I need |
| 00:43.25 | dcordes_ | byebye |
| 00:47.20 | *** join/#htc-linux ali12341 (n=al@robotfuzz.co.uk) |
| 00:55.42 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 01:08.52 | *** join/#htc-linux Patrick_Bateman (n=infidel2@unaffiliated/swc666/x-4934821) |
| 01:09.45 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 01:11.04 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 01:15.00 | *** join/#htc-linux ImCoKeMaN (n=imcokema@pool-74-99-144-198.hrbgpa.fios.verizon.net) |
| 01:52.45 | *** join/#htc-linux infernix (i=nix@unaffiliated/infernix) |
| 01:56.40 | *** join/#htc-linux timebomb (n=tb@e179196103.adsl.alicedsl.de) |
| 02:39.40 | *** join/#htc-linux stickboy (n=anonymou@ool-457e4101.dyn.optonline.net) |
| 02:41.57 | tmzt | tsc2003 driver: http://marc.info/?l=linux-kernel&m=124515657307667&w=2 |
| 03:09.07 | *** join/#htc-linux mrmoku` (n=mrmoku@ppp-93-104-46-250.dynamic.mnet-online.de) |
| 03:47.23 | *** join/#htc-linux jaSOnGg (n=IamSOG@218.19.240.75) |
| 03:50.22 | xsacha-tv | tmzt, hey |
| 03:51.49 | xsacha-tv | i found that my LED driver has very very detailed documentation.. it has nice diagrams, explains every gpio, pin function, explains how to read and write to the i2c bus and the electrical format and even has a register list :) |
| 03:51.59 | xsacha-tv | i was wondering with the register list, how do i find the offset? |
| 03:52.51 | xsacha-tv | i have the leds, vibrator and keypad working already but it has very interesting stuff about lighting patterns, wave forms and so on |
| 04:11.05 | tmzt | offset? |
| 04:11.23 | xsacha-tv | to read from memory? |
| 04:11.35 | tmzt | memory? |
| 04:14.35 | xsacha-tv | hmm isnt that where the registers are? |
| 04:15.35 | *** join/#htc-linux goxboxlive1 (n=jrs@mail2.hjellnesconsult.no) |
| 04:15.52 | xsacha-tv | it shows writing to the registers to change the lighting patterns |
| 04:25.58 | tmzt | the registers are accessed over i2c |
| 04:26.08 | xsacha-tv | oh ok |
| 04:26.28 | tmzt | you need to write an i2c chip driver |
| 04:26.31 | xsacha-tv | i dont know how to use i2c.. is there some sort of writei2c command? |
| 04:26.34 | xsacha-tv | ah |
| 04:26.46 | tmzt | it shouldn't be spsecic to your device |
| 04:26.58 | xsacha-tv | well it's not that important. i was just hoping to increase the brightness of blue, for example |
| 04:27.07 | tmzt | just expose the various settings through mfd |
| 04:27.07 | xsacha-tv | winmo makes blue very dull and almost black |
| 04:27.48 | tmzt | then write a led/backlight driver |
| 04:27.53 | tmzt | which uses it |
| 04:27.58 | xsacha-tv | ok |
| 04:36.35 | *** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey) |
| 04:39.22 | *** join/#htc-linux droid001 (n=mc@p4FDCD7B9.dip.t-dialin.net) |
| 04:48.50 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) |
| 04:49.13 | Amaranth | wow, more people than I thought |
| 04:53.56 | xsacha-tv | i found my battery driver uses I2C too, in detail here: http://datasheets.maxim-ic.com/en/ds/MAX8660-MAX8661.pdf |
| 04:54.35 | xsacha-tv | so ill work on those I2C things now. there's an old MAX68xx battery I2C driver but mine is MAX86xx |
| 04:56.11 | xsacha-tv | I2C looks complicated though.. acknowledge bits and 'pulling high' 'pulling low' |
| 04:57.33 | Amaranth | has anyone ever had linux boot directly on their phone instead of booting from winmo? |
| 04:58.02 | tmzt | no except omap |
| 04:58.07 | tmzt | with eol |
| 04:58.13 | tmzt | what phone? |
| 04:58.32 | Amaranth | kaiser |
| 04:58.41 | tmzt | ok |
| 05:00.05 | tmzt | we are working on something like that |
| 05:00.24 | tmzt | for kais you probably want to see if dzo has any plans |
| 05:00.27 | Amaranth | i'm sure it'd be complicated since you need some way to update/recover |
| 05:00.43 | tmzt | no, spl already does that |
| 05:00.49 | Amaranth | oh, right |
| 05:01.01 | Amaranth | some kind of RUU-like too then |
| 05:02.29 | tmzt | ruu is a client for the spl |
| 05:02.38 | tmzt | we would like use htc-flasher |
| 05:03.24 | Amaranth | oh, I thought RUU was the name of the tool |
| 05:03.45 | Amaranth | just got the kaiser on friday, already flashed it 4 times and installed a couple different android builds on it |
| 05:03.54 | Amaranth | now I'm trying to make my own |
| 05:04.07 | tmzt | ok |
| 05:04.34 | Amaranth | I notice the wiki is pretty bare, is there any other place for information on how all this works? |
| 05:08.11 | tmzt | htc-linux.org? |
| 05:08.24 | tmzt | wiki.xda-developers.com |
| 05:08.37 | tmzt | how what work exactly? |
| 05:12.18 | Amaranth | tmzt: I dunno, just an overview of what is working and how it was done |
| 05:12.18 | Amaranth | somewhere to start |
| 05:12.43 | Amaranth | oh, htc-linux.org has different stuff, the topic only links to the wiki |
| 05:23.27 | tmzt | yeah |
| 05:24.07 | tmzt | I can try to answer questions |
| 05:24.32 | tmzt | but I can't really go through everything right now |
| 05:25.55 | tmzt | working: sd card, display, keyboard, radio/modem, gprs, 3g?? |
| 05:26.12 | tmzt | audio routing might be working on kaiser, not sure |
| 05:26.34 | tmzt | uh, usb client |
| 05:26.56 | tmzt | not bluetooth or wifi I think, but that should be doable |
| 05:29.29 | tmzt | as for how it was done, research on windows dirvers and bootloader code |
| 05:29.37 | tmzt | tracing read/writes |
| 05:30.12 | tmzt | google android tree with basic support for msm7201A released near the end of 2007 |
| 05:32.27 | Amaranth | wifi is actually my main interest at this point |
| 05:32.45 | Amaranth | and getting a build that 1) has a terminal and 2) isn't crashy |
| 05:32.58 | Amaranth | it looks like there is some progress on wifi, was hoping I'd find out more here |
| 05:33.30 | tmzt | ok |
| 05:33.34 | xsacha-tv | tmzt: my silly samsung tv died :( |
| 05:33.39 | tmzt | ? |
| 05:33.43 | xsacha-tv | gonna get it repaired |
| 05:33.47 | tmzt | what did you do? |
| 05:33.55 | xsacha-tv | nothing! was just watching tv |
| 05:34.10 | xsacha-tv | the picture died (like the screen backlight) but audio stays on |
| 05:34.18 | xsacha-tv | a broken inverter for backlight or something |
| 05:34.27 | tmzt | well, for wifi to work we need to fix mmc clocks |
| 05:34.33 | tmzt | oh |
| 05:34.40 | tmzt | yeah, sounds right |
| 05:34.47 | xsacha-tv | it's only 2.5 months old:( |
| 05:36.32 | xsacha-tv | never had a product break on me before.. i usually chuck em out before they break i guess |
| 05:37.29 | xsacha-tv | my old nokia brick phone is still going. i chucked out my 1988 amiga a couple of years ago |
| 05:38.01 | xsacha-tv | oh well, .. any ideas what i can do for tips on I2c? |
| 05:38.27 | xsacha-tv | should i work on the old max6875 driver and adapt it for max8660? |
| 05:39.31 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 05:51.33 | *** join/#htc-linux pleemans (n=toi@mailhost.infoco.be) |
| 06:02.21 | tmzt | xa: probably |
| 06:02.29 | tmzt | xsacha-tv: |
| 06:02.43 | xsacha-tv | hi |
| 06:04.12 | xsacha-tv | i've created drivers/i2c/chips/max8660.c , looked at zylonite_battery.dll http://pastebin.com/mf2bcec9 and got some max8660 documentation: http://datasheets.maxim-ic.com/en/ds/MAX8660-MAX8661.pdf |
| 06:04.18 | xsacha-tv | so starting now |
| 06:04.18 | tmzt | if the chips are similar enough try addiding the new chip to the old driver |
| 06:04.38 | xsacha-tv | dont think they are that similar |
| 06:05.25 | xsacha-tv | <PROTECTED> |
| 06:07.28 | *** join/#htc-linux kiozen (n=oeichler@p54921771.dip0.t-ipconnect.de) |
| 06:09.46 | tmzt | sounds like 0x81 is the chip address |
| 06:10.12 | xsacha-tv | thats the old max6875 though |
| 06:11.02 | xsacha-tv | on the diagram it says 2-wire I2C, Standard I2C (GPIO32/33) + Power I2C |
| 06:11.17 | xsacha-tv | mean anything:? |
| 06:11.18 | tmzt | you might not even have eeprom |
| 06:11.29 | xsacha-tv | i cant find 'eep' anywhere in documentation |
| 06:13.13 | tmzt | ? |
| 06:13.16 | tmzt | oh |
| 06:13.27 | xsacha-tv | there's 2 pages dedicated to explaining how to write to I2C in documentation but it doesnt mention reading.. |
| 06:14.25 | xsacha-tv | this is strange but it says: "Note that the R bit is always zero since the MAX8660/MAX8661 are write only." |
| 06:14.51 | xsacha-tv | R/W (W has a line on top) bit |
| 06:15.43 | xsacha-tv | don't i want to read values, not write? |
| 06:17.37 | ali12341 | shouldn't you be using the kernel i2c code for this? |
| 06:19.37 | tmzt | you write to read |
| 06:19.55 | xsacha-tv | i want to use i2c_smbus_read_i2c_block_data |
| 06:19.59 | tmzt | ali, any ideas? |
| 06:20.08 | tmzt | maybe |
| 06:20.35 | xsacha-tv | i get that i need to write for it to tell me stuff, but i need to read too right? |
| 06:20.52 | ali12341 | there is no reading and writing |
| 06:20.55 | xsacha-tv | the old max6875 had a CMD_BLK_READ (0x84) that i cant find in the documentation |
| 06:21.00 | ali12341 | there is only sending a message and getting a reply |
| 06:21.25 | xsacha-tv | well yeah i get the sending write bit, but how do i receive reply? |
| 06:21.39 | ali12341 | the kernel i2c driver handles it for you |
| 06:21.52 | *** join/#htc-linux timebomb (n=tb@e179196103.adsl.alicedsl.de) |
| 06:22.05 | xsacha-tv | the second parameter is a CMD_BLK_READ though, i dont have it |
| 06:23.49 | xsacha-tv | i notice the winmo driver does AND 0xFF (get last 8 bits) and then applies some 10101011 mask (last bit is high for acknowledge) |
| 06:24.01 | xsacha-tv | kernel handles this for me? |
| 06:25.06 | ali12341 | the kernel driver handles all the wire details |
| 06:25.33 | ali12341 | all you have to do is send the right values |
| 06:25.59 | ali12341 | what i2c controller is used? |
| 06:26.11 | xsacha-tv | pxa? |
| 06:26.28 | ali12341 | ok, it has a driver already, right? |
| 06:26.49 | xsacha-tv | yes |
| 06:27.00 | ali12341 | and you enabled it in the kernel config? |
| 06:27.03 | xsacha-tv | yes |
| 06:27.09 | ali12341 | do you have /dev/i2c/0? |
| 06:27.19 | xsacha-tv | probably |
| 06:28.44 | ali12341 | do you have i2c-tools? |
| 06:28.50 | ali12341 | for example i2cdump |
| 06:29.20 | xsacha-tv | no |
| 06:30.12 | xsacha-tv | i dont have a /dec/i2c :( |
| 06:30.33 | xsacha-tv | /dev/i2c * |
| 06:30.46 | ali12341 | did you compile the driver as modules? |
| 06:30.59 | xsacha-tv | the controller? |
| 06:31.02 | ali12341 | yes |
| 06:31.05 | xsacha-tv | no |
| 06:32.23 | ali12341 | did you enable i2c-dev in the kernel? |
| 06:32.57 | xsacha-tv | I2C_CHARDEV ? |
| 06:33.09 | ali12341 | probably |
| 06:33.14 | xsacha-tv | yes, enabled |
| 06:33.30 | ali12341 | pastebin the .config please |
| 06:34.06 | xsacha-tv | http://pastebin.com/m1bf80e0f |
| 06:35.26 | ali12341 | maybe you just need to mknod it |
| 06:36.33 | ali12341 | mknod /dev/i2c-0 c 89 0 |
| 06:37.52 | xsacha-tv | i2c/0 right? |
| 06:38.32 | ali12341 | doesnt matter |
| 06:38.35 | xsacha-tv | my /dev is blank by the way |
| 06:38.41 | ali12341 | well that's not good |
| 06:39.17 | xsacha-tv | :\ |
| 06:39.43 | *** join/#htc-linux infernix (i=nix@unaffiliated/infernix) |
| 06:39.47 | xsacha-tv | it creates everything on startup |
| 06:40.15 | ali12341 | of course |
| 06:40.25 | ali12341 | you need to run mknod on the live system |
| 06:41.50 | tmzt | i2c-0 |
| 06:43.36 | xsacha-tv | i get <7>i2c-core: driver [max6875] registered |
| 06:44.08 | tmzt | disable that driver |
| 06:44.20 | ali12341 | also disable the bit banging gpio driver |
| 06:44.55 | ali12341 | and pxa slave |
| 06:45.11 | ali12341 | and ocores and simtec |
| 06:45.41 | xsacha-tv | ok |
| 06:52.15 | xsacha-tv | all i get now is <6>i2c /dev entries driver <7>i2c-core: driver [dev_driver] registered |
| 06:59.10 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 07:00.44 | tmzt | good |
| 07:00.59 | xsacha-tv | i had that before as well though |
| 07:03.50 | tmzt | but you have the char driver now right? |
| 07:05.15 | xsacha-tv | where is it ? /dev/char? |
| 07:05.25 | xsacha-tv | if i have it now, i had it before :\ nothing changed |
| 07:09.54 | tmzt | you have to mknod it |
| 07:13.43 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
| 07:16.38 | xsacha-tv | every time i boot? what do i do with it? i have nothing running over i2c right now |
| 07:30.13 | xsacha-tv | <PROTECTED> |
| 07:31.51 | tmzt | this is for testing |
| 07:32.04 | tmzt | you will use a kernel chip driver later |
| 07:36.52 | *** join/#htc-linux MethoS (n=clemens@dyndsl-085-016-163-188.ewe-ip-backbone.de) |
| 08:03.06 | *** join/#htc-linux onen|openBmap (n=quassel@p57BC63D7.dip.t-dialin.net) |
| 08:05.24 | xsacha-tv | grr, studied this documentation and still cant figure out how to read the replies |
| 08:06.38 | xsacha-tv | it doesnt mention any read byte but says it uses smbus.. smbus required a read byte to read |
| 08:06.57 | xsacha-tv | then it says write bit is always 0 because it's a write-only device.. im so confused |
| 08:09.02 | xsacha-tv | read bit for max6875 was 0x84.. i could try that |
| 08:09.03 | ali12341 | you cant read from it |
| 08:09.29 | xsacha-tv | dont get technical on me, it calls it reading :P |
| 08:09.34 | ali12341 | "read bit" is 1 bit, 1 or 0 |
| 08:09.41 | xsacha-tv | read byte* |
| 08:09.58 | ali12341 | smbus means all messages are 1 byte long |
| 08:10.13 | ali12341 | you dont need to read any documentation at that level |
| 08:10.18 | ali12341 | because the kernel handles it for you |
| 08:10.28 | xsacha-tv | well the kernel wants a read byte |
| 08:11.04 | ali12341 | read Documentation/i2c/smbus-protocol |
| 08:11.41 | xsacha-tv | i2c_smbus_read_block_data(struct i2c_client *client, u8 command, u8 *values); |
| 08:11.49 | xsacha-tv | that command has to be the read byte |
| 08:12.09 | xsacha-tv | but i dont know what it's meant to be |
| 08:13.31 | ali12341 | that is for reading a block of reigsters at the same time |
| 08:13.35 | ali12341 | read the docs |
| 08:14.05 | xsacha-tv | yeah i need that |
| 08:14.23 | ali12341 | you can't read a block of registers, you can't read anything from it if it is write only |
| 08:14.32 | xsacha-tv | *sigh* |
| 08:19.39 | ali12341 | i2c-tools has a tool called i2cset |
| 08:20.24 | ali12341 | this is the command line: i2cset [-f] [-y] I2CBUS CHIP-ADDRESS DATA-ADDRESS VALUE |
| 08:20.34 | ali12341 | so you can already control your chip using it, like this: |
| 08:20.48 | ali12341 | I2CBUS is /dev/i2c-0 |
| 08:21.16 | ali12341 | CHIP-ADDRESS is the slave address of the device which according to the datasheet can only be 0x68 or 0x6a depending how it is wired |
| 08:21.44 | ali12341 | DATA-ADDRESS is one of the registers from page 34 |
| 08:21.51 | ali12341 | and VALUE is the value you want to write |
| 08:22.56 | ali12341 | i2c_smbus_write_byte_data is the equivalent kernel api |
| 08:25.16 | ali12341 | extern s32 i2c_smbus_write_byte_data(struct i2c_client * client, u8 command, u8 value); |
| 08:26.33 | ali12341 | command is the register and value is the value |
| 08:26.53 | ali12341 | client is a handle to the device which you have to initialize using the other i2c functions |
| 08:28.19 | xsacha-tv | but... how do i get a reply? |
| 08:28.29 | ali12341 | you dont. ever |
| 08:28.36 | ali12341 | the device is write only |
| 08:28.43 | xsacha-tv | whats the point of this chip. i want voltage/charge level from it |
| 08:28.49 | ali12341 | it doesnt do that |
| 08:28.53 | xsacha-tv | :| |
| 08:28.57 | ali12341 | the datasheet is very clear |
| 08:29.36 | ali12341 | the chip is a power control chip for DC-DC conversion |
| 08:29.58 | ali12341 | basically it is used to turn off external devices like bluetooth, wifi, leds etc |
| 08:30.24 | ali12341 | the battery level might be another chip on the same i2c bus or it might not |
| 08:30.34 | xsacha-tv | hm, strange. it's the only thing connected to the battery? |
| 08:30.45 | xsacha-tv | i'll look harder then |
| 08:30.59 | ali12341 | the battery may have an internal i2c chip |
| 08:34.17 | *** join/#htc-linux stephan_ (n=stephan@rgnb-5d87d973.pool.einsundeins.de) |
| 09:07.31 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 09:10.21 | *** join/#htc-linux timebomb (n=tb@85.182.255.196) |
| 09:14.37 | *** join/#htc-linux pleemans (n=toi@mailhost.infoco.be) |
| 09:29.07 | *** join/#htc-linux stephan__ (n=stephan@rgnb-5d87c882.pool.einsundeins.de) |
| 09:59.35 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 10:16.17 | *** join/#htc-linux nebi (n=nebi@217.142.147.19) |
| 10:25.03 | *** part/#htc-linux stephan__ (n=stephan@rgnb-5d87c882.pool.einsundeins.de) |
| 10:29.06 | *** join/#htc-linux KindofBlue (n=KindofBl@rgnb-5d87c882.pool.einsundeins.de) |
| 10:39.47 | KindofBlue | Hello, I have a HTC Universal running with Debian(Titchy) and Kernel 2.6.21-hh20. |
| 10:42.57 | *** join/#htc-linux ptitjes (n=didier@212.73.198-77.rev.gaoland.net) |
| 10:59.31 | *** join/#htc-linux KindofBlue (n=KindofBl@rgnb-5d874633.pool.einsundeins.de) |
| 11:16.29 | *** join/#htc-linux m0zzie (n=m0zzie@60-241-53-34.static.tpgi.com.au) |
| 11:24.55 | *** join/#htc-linux dcordes (n=dcordes@unaffiliated/dcordes) |
| 12:27.44 | *** join/#htc-linux Amaranth (n=travis@74.221.34.123) |
| 12:35.54 | *** join/#htc-linux BabelO_ (n=fcr@unaffiliated/babelo) |
| 12:45.32 | *** join/#htc-linux cmonex (n=xy6091@tuhre5zz6u.adsl.datanet.hu) |
| 12:59.32 | *** join/#htc-linux marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 13:15.47 | *** join/#htc-linux KindofBlue (n=KindofBl@rgnb-5d87da61.pool.einsundeins.de) |
| 13:17.55 | KindofBlue | Hello, I have a HTC Universal running with Debian(Titchy) and Kernel 2.6.21-hh20. |
| 13:18.27 | KindofBlue | With 2.6.21-hh20 it consumes 30mA in suspend (WinCE 3 mA) this means ca. 2 days (linux) to 20 days (WinCE). |
| 13:18.40 | KindofBlue | <PROTECTED> |
| 13:18.55 | KindofBlue | <PROTECTED> |
| 13:19.16 | KindofBlue | Is there anybody, who has a newer Kernel working on Universal ? |
| 13:19.42 | *** join/#htc-linux methril|work (n=Methril@213.27.233.98) |
| 13:22.51 | *** part/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 13:24.09 | *** join/#htc-linux Slyon (n=lukas@p4FDB384E.dip0.t-ipconnect.de) |
| 13:34.16 | *** join/#htc-linux Moku (n=John@92.228.159.53) |
| 13:48.34 | *** join/#htc-linux Shinto (n=John@f048127026.adsl.alicedsl.de) |
| 13:50.21 | *** part/#htc-linux Slyon (n=lukas@p4FDB384E.dip0.t-ipconnect.de) |
| 13:55.49 | *** join/#htc-linux Moku (n=John@f049031185.adsl.alicedsl.de) |
| 14:13.23 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 14:16.16 | *** join/#htc-linux Shinto (n=John@f048106186.adsl.alicedsl.de) |
| 14:23.22 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 14:30.40 | *** join/#htc-linux Moku (n=John@f054193144.adsl.alicedsl.de) |
| 14:35.32 | *** join/#htc-linux Shinto (n=John@e181253254.adsl.alicedsl.de) |
| 14:36.59 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 14:37.58 | *** part/#htc-linux sdt555 (n=titus@147.145.40.44) |
| 14:47.18 | *** join/#htc-linux Shinto (n=John@f049080178.adsl.alicedsl.de) |
| 14:53.08 | *** join/#htc-linux Tinyboom (n=nahh@62.84-49-90.nextgentel.com) |
| 14:53.52 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 14:55.25 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 14:58.51 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:00.17 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:01.32 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:06.18 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:09.35 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:12.57 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:16.07 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:18.51 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:21.24 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 15:30.02 | *** join/#htc-linux pleemans (n=toi@mailhost.infoco.be) |
| 15:34.58 | *** join/#htc-linux Moku (n=John@78.48.7.86) |
| 15:50.35 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 16:10.13 | *** join/#htc-linux tcccp (i=hey@2001:470:c926:666:666:666:666:666) |
| 16:10.16 | tcccp | re |
| 16:15.34 | *** join/#htc-linux pH5 (n=ph5@e178197124.adsl.alicedsl.de) |
| 16:23.18 | *** join/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 16:36.12 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 16:37.36 | *** join/#htc-linux surgex0 (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
| 16:38.55 | *** part/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 16:48.47 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 16:59.19 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87c2f3.pool.einsundeins.de) |
| 17:04.08 | *** join/#htc-linux surge (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
| 17:05.07 | *** join/#htc-linux surge (i=surge@pool-98-118-158-217.bflony.fios.verizon.net) |
| 17:08.38 | *** join/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 17:08.42 | *** part/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 17:08.49 | *** join/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 17:08.53 | *** part/#htc-linux vts (n=vts@62-47-203-138.adsl.highway.telekom.at) |
| 17:34.23 | *** join/#htc-linux IamSOG (n=IamSOG@218.20.216.58) |
| 17:46.54 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 17:47.58 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
| 17:52.52 | Echo31 | Hi pH5 |
| 17:53.32 | pH5 | hej Echo31 |
| 17:55.38 | *** join/#htc-linux vts (n=vts@62-47-211-96.adsl.highway.telekom.at) |
| 17:55.42 | *** join/#htc-linux TonyDanza_ (n=root@CPE0018394c86b6-CM001ceab59d68.cpe.net.cable.rogers.com) |
| 17:55.50 | TonyDanza_ | hey all |
| 17:56.34 | pH5 | hej TonyDanza_ |
| 17:58.32 | TonyDanza_ | so i'm considering moving to an HTC dream (aka G1) from an iphone 2G |
| 17:59.07 | TonyDanza_ | however i havnt really seen a whole bunch in the way of 3rd party apps... maybe i'm looking in the wrong places but it dosnt look like there is a huge community behind andriod yet |
| 18:01.55 | TonyDanza_ | I'm mainly looking for andriod replacements for my commonly used iphone apps (terminal for SSH etc... irc, MSN messenger) |
| 18:02.11 | pH5 | TonyDanza_: did you try #android? |
| 18:02.19 | pH5 | this channel is about kernel development |
| 18:07.11 | TonyDanza_ | ah |
| 18:07.35 | TonyDanza_ | cool. i'll check that out. thanks |
| 18:07.38 | *** part/#htc-linux TonyDanza_ (n=root@CPE0018394c86b6-CM001ceab59d68.cpe.net.cable.rogers.com) |
| 18:15.52 | *** join/#htc-linux StarLite (n=nnscript@s55916ca6.adsl.wanadoo.nl) |
| 18:31.43 | Echo31 | pH5: I found the correct constants for cpld2 . http://fr.pastebin.ca/1478616 |
| 18:33.12 | pH5 | god no, that turns everything on. doesn't .initial_values=0x0003 work? |
| 18:33.29 | pH5 | this cpld is strictly output-only? |
| 18:33.57 | pH5 | and why NR_BUILTIN_GPIO, what is .gpio_base of cpld1? |
| 18:34.03 | Echo31 | pH5: I will retry with .initial_values=0x0003 |
| 18:35.26 | Echo31 | pH5: I don't yet initialize cpd1 |
| 18:35.37 | pH5 | ok |
| 18:37.32 | pH5 | Echo31: and looking at http://www.htc-linux.org/wiki/index.php?title=CPLD2, HTC_EGPIO_OUTPUT is wrong, too. |
| 18:37.51 | Echo31 | pH5: it is failed with .initial_values=0x0003 |
| 18:38.04 | pH5 | only bits 0-8 are output pins, so .direction should be something like 0x01ff |
| 18:38.31 | pH5 | Echo31: really failed or only backlight off? |
| 18:38.39 | pH5 | (which is bit 5) |
| 18:39.16 | Echo31 | ph5: perhaps blacklight off |
| 18:39.39 | pH5 | check that, maybe use 0x0023 until you have fixed up the backlight driver |
| 18:40.29 | Echo31 | pH5: .initial_values=0x0003 and .direction= 0x01ff -> backlight off : i can try 0023 |
| 18:44.37 | Echo31 | pH5: It is ok with .initial_values=0x0023 and .direction= 0x01ff |
| 18:44.57 | pH5 | ok, let's use that for now |
| 18:46.44 | Echo31 | pH5: now, i have to attack cpld1 |
| 18:47.08 | *** join/#htc-linux dicki (n=dicki@cpc3-rdng6-0-0-cust831.winn.cable.ntl.com) |
| 19:01.07 | Echo31 | pH5: for cpld1 starting, can I initialize only the 4 first output registers? .initial_values is it necessary ? |
| 19:08.04 | *** join/#htc-linux pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 19:08.11 | *** part/#htc-linux dicki (n=dicki@cpc3-rdng6-0-0-cust831.winn.cable.ntl.com) |
| 19:28.58 | *** join/#htc-linux cr2 (n=cr2@ip-90-186-120-36.web.vodafone.de) |
| 19:29.25 | cr2 | kiozen: here ? |
| 19:30.08 | kiozen | cr2: hi |
| 19:30.43 | cr2 | hi kiozen |
| 19:30.49 | cr2 | some news about n560 |
| 19:31.02 | cr2 | the pwm1 is lcd contrast |
| 19:31.19 | kiozen | oh it has contrast? |
| 19:31.22 | cr2 | and some guy has written the driver for leds |
| 19:31.49 | cr2 | he has merged too much from loox720, but still it's some progress. |
| 19:32.31 | kiozen | cool |
| 19:32.44 | kiozen | BabelO is doing track recording right now |
| 19:32.51 | cr2 | is n520 verx different from n560 ? |
| 19:33.00 | kiozen | afaik yes |
| 19:33.01 | cr2 | in M ? |
| 19:33.06 | kiozen | yes M |
| 19:33.22 | kiozen | and I should finetune waypoints |
| 19:33.31 | kiozen | and backlight handling |
| 19:33.38 | cr2 | i think they changed the LCD parameters for n520, but reuse the n560 core |
| 19:33.42 | cr2 | ok |
| 19:33.49 | cr2 | think about contrast :) |
| 19:34.12 | *** part/#htc-linux vts (n=vts@62-47-211-96.adsl.highway.telekom.at) |
| 19:34.18 | cr2 | even jornada820 had lcd contrast, but then all devices were made bkl-only |
| 19:34.29 | kiozen | should I update kernel fom cvs |
| 19:34.31 | kiozen | ? |
| 19:35.15 | cr2 | pH5: does 2.6.30 magician support resume and pxa uart power ? |
| 19:35.53 | cr2 | kiozen: something needs to be decided. should we port n560 to 2.6.30 ? |
| 19:36.25 | kiozen | I vote for yes, because bt is buggy like hell right now |
| 19:36.38 | cr2 | ok |
| 19:37.04 | cr2 | with the cpld for athena we will have enough experience for n560 |
| 19:37.19 | cr2 | afair the n560 cpld does not have irqs ? |
| 19:37.46 | kiozen | you ask the wrong one :) |
| 19:38.17 | pH5 | cr2: I've got resume working in my dev tree. |
| 19:38.44 | pH5 | instead of uart power, I've got an rfkill driver to power the calypso chip. |
| 19:39.09 | cr2 | kiozen: http://www.akshaal.info |
| 19:39.25 | pH5 | but there's a patch by marex pending iirc |
| 19:39.49 | cr2 | pH5: we have bt and gps on uarts. rfkill for gps too ? |
| 19:40.21 | kiozen | cr2: cool |
| 19:41.01 | cr2 | kiozen: the leds and contrast are cool, the rest looks like a big mess in his patches |
| 19:41.31 | cr2 | kiozen: and he missed several things about bitbang spi & things |
| 19:41.32 | kiozen | lol |
| 19:41.54 | cr2 | i may check the loox720 resume patch, though |
| 19:42.46 | cr2 | kiozen: he uses the 720 cpld driver with htc-egpio. and resume code from 720 and from n560. that can't be good. |
| 19:43.02 | cr2 | i'd like to know if he can resume... |
| 19:43.28 | Echo31 | Hi cr2 |
| 19:44.07 | pH5 | cr2: nah, certainly not. even for bt/gsm power it's not really the right thing (at least if the chips have a powered-but-rf-silence setting). |
| 19:44.33 | cr2 | hi Echo31 |
| 19:44.47 | cr2 | pH5: yeah, but nobody has a better idea ;) |
| 19:44.52 | pH5 | if the gps powers up fast, powering via uart open is ok (like ir transceivers) |
| 19:45.04 | pH5 | otherwise we are supposed to do it in userspace if i understood correctly. |
| 19:45.23 | pH5 | it's now possible to export gpio pins to sysfs |
| 19:45.27 | Echo31 | cr2: with the help of pH5, finally, i can initialize athena cpld2 |
| 19:45.56 | *** join/#htc-linux vts (n=vts@62-47-211-96.adsl.highway.telekom.at) |
| 19:45.59 | *** part/#htc-linux vts (n=vts@62-47-211-96.adsl.highway.telekom.at) |
| 19:46.02 | cr2 | pH5: ok, that's a possible solution too. rfkill is a hack. |
| 19:46.41 | cr2 | but the driver should still check if the power is applied, and reject to start if it is not. |
| 19:47.12 | cr2 | Echo31: great :) what about cpld1 ? it's just a last small step :) |
| 19:48.33 | cr2 | kiozen: did we document the gpio 114,115,116 state machine for switching the pxa speed ? |
| 19:49.21 | kiozen | 114 ??? output, turbo mode=1,standart=0, power-saving=1 or 0 |
| 19:49.22 | kiozen | 115 ??? output, turbo mode=1,standart=1, power-saving=0 |
| 19:49.24 | kiozen | 116 ??? output, turbo mode=0,standart=1, power-saving=0 |
| 19:50.08 | cr2 | i had some notes, but after moving to Munich i can't find anything. even for athena ;) |
| 19:51.24 | cr2 | kiozen: if you change from one frequency to another ( there are 3 states ?), then these gpios are changed in a certain sequence. it's easy to trace them |
| 19:51.51 | cr2 | i think 624MHz, 104MHz and something in between |
| 19:54.21 | kiozen | yes if I recall right there are 4 steps |
| 19:54.47 | kiozen | but speed scaling always seemed to work |
| 19:54.59 | cr2 | 4 is "floating" |
| 19:55.47 | Echo31 | cr2: For now on cpld1, the following constants of .initial_values , the LCD displays strange colors, and it powers off. |
| 19:56.26 | cr2 | Echo31: post the full config |
| 19:56.42 | cr2 | Echo31: i'll look for the pd 0x08000000 0x20 dumps |
| 19:59.49 | Echo31 | cr2: i tried the code hereafter for cpld1 : http://fr.pastebin.ca/1478709 |
| 20:02.22 | cr2 | Echo31: the direction needs to be fixed |
| 20:02.48 | cr2 | what is 0x20 bit for cpld ? |
| 20:04.04 | cr2 | 5 0x0020 backlight pwr (on=1) |
| 20:04.14 | cr2 | is it really necessary on boot ? |
| 20:05.01 | cr2 | imvho it's a good practice to shutdown the bkl, lcd, wifi, bt and so on in haret boot script |
| 20:05.28 | cr2 | we can't do it for the lcd right now, but the bkl should not be a problem. |
| 20:05.32 | Echo31 | cr2: i don't know. I tried few possible values |
| 20:05.47 | cr2 | Echo31: for what ? |
| 20:06.22 | cr2 | Echo31: does it boot with 0x3 value ? |
| 20:06.35 | Echo31 | cr2: I have tried of value for LCD pwr on |
| 20:06.36 | cr2 | backlight will be down, but it's not dramatic |
| 20:06.51 | cr2 | yes, lcd is 0x3 |
| 20:07.32 | cr2 | for cpld there are charging gpios. i think we didn't really trace them yet ? |
| 20:07.42 | cr2 | s/cpld/cpld1/ |
| 20:08.36 | cr2 | compiled snd for raph100 :) |
| 20:11.20 | Echo31 | cr2: the cpld2 works only 0x0023 et 0x01ff |
| 20:13.29 | cr2 | Echo31: backlight bit 0x20 is always on ? |
| 20:14.17 | Echo31 | cr2: for the Gpin ? |
| 20:14.21 | cr2 | what is 'pd 0x09000000 4' with backlight off ? |
| 20:14.27 | pH5 | cr2: if this is power to the backlight, that 0x0020 cpld gpio should be requested/handled/freed by the pwm-backlight's .init/.notify/.exit methods. |
| 20:15.07 | cr2 | pH5: it's a 'backlight related' gpio. there are some others too. |
| 20:15.54 | cr2 | tmzt: /dev/msm_snd is there now. |
| 20:16.00 | pH5 | on magician I have 2 gpios for the backlight |
| 20:16.36 | cr2 | tmzt: but there is no userspace code to call its ioctls, though it's not difficult to write it from scratch. |
| 20:17.20 | cr2 | pH5: i think we'd fix more important things first, before the bkl :) |
| 20:18.00 | pH5 | cr2: so leave the initial value at 0x23 for now, until the backlight is handled properly |
| 20:18.12 | cr2 | Echo31: if disabling the 0x20 bit does not break the LCD, we should disable it. |
| 20:18.19 | cr2 | pH5: ok |
| 20:19.27 | pH5 | otoh, if it is driven by a pxa pwm on athena too, this really is one low-hanging fruit :) |
| 20:19.31 | cr2 | Echo31: let's look at the cpld1 directions, then the code looks reasonable to me. |
| 20:19.41 | cr2 | pH5: yes, pwm0 |
| 20:20.20 | cr2 | pH5: on n560 the bkl is on pwm0 and contrast is on pwm1. can the current code handle that ? |
| 20:22.58 | cr2 | pH5: what is the real purpose of an "input" gpio for cpld ? |
| 20:23.09 | pH5 | cr2: I don't think there's a driver for that in mainline yet. |
| 20:23.12 | cr2 | pH5: if it's a non-irq gpio of course |
| 20:23.26 | cr2 | ok, then we need to think about it. |
| 20:23.55 | pH5 | basically, you'll have to implement an lcd_device for that |
| 20:24.01 | cr2 | the input gpio prevents writing to it, that's ok |
| 20:24.22 | cr2 | but i still can read the state of an output gpio... |
| 20:24.25 | pH5 | exactly. that's all, to tell the gpio API that gpio_direction_output calls should fail |
| 20:24.40 | cr2 | ok |
| 20:24.44 | pH5 | sure, usually that's the driven state |
| 20:25.32 | Echo31 | cr2: You want change for cpld2 .initial_values=0x0023 to .initial_values=0x0003 |
| 20:25.46 | cr2 | ok, then we may declare input only the unknown gpios and irq |
| 20:26.08 | cr2 | Echo31: yes. |
| 20:26.18 | pH5 | Echo31: eventually, yes. then you'll have to add that gpio to the pwm-backlight driver so it can enable it. |
| 20:26.29 | pH5 | cr2: yes, that's what I would suggest. |
| 20:26.32 | Echo31 | cr2: the LCD powers off |
| 20:26.34 | cr2 | Echo31: the bl driver should take care about its power. |
| 20:26.46 | cr2 | Echo31: ok, leave it enabled. |
| 20:27.00 | cr2 | must be some common lcd/bkl power pin. |
| 20:27.32 | pH5 | is athena transflective? |
| 20:27.45 | cr2 | Echo31: can you boot with backlight off ? |
| 20:29.00 | Echo31 | cr2: perhaps, but how i can check it. |
| 20:29.06 | cr2 | Echo31: i mean if the LCD is completely off, or it's just hard to read with bkl off |
| 20:29.24 | cr2 | hmm. not with mainline haret ;) |
| 20:30.15 | cr2 | Echo31: put the bkl brighness to a minimum/disable it in wince settings |
| 20:32.16 | cr2 | lol |
| 20:32.17 | Echo31 | cr2: The Athena AP4 is not easy to change this value. I try |
| 20:32.53 | cr2 | playwav -rec /tmp/rec.wav says "ARM9 has CRASHED" |
| 20:33.54 | pH5 | lol |
| 20:34.41 | cr2 | Echo31: ok, let's finish with cpld1 first |
| 20:35.16 | Echo31 | cr2: ok |
| 20:35.32 | cr2 | the direction is ok. |
| 20:35.39 | cr2 | initial values. |
| 20:36.31 | cr2 | why is G 0x20 ? is it a wince value ? |
| 20:37.13 | cr2 | pH5: does the "initial_value" make sense for an input gpio ? |
| 20:37.20 | pH5 | no |
| 20:37.39 | Echo31 | cr2: because; the cable usb is plugged |
| 20:37.46 | cr2 | for D |
| 20:37.48 | cr2 | <PROTECTED> |
| 20:37.59 | cr2 | GPIOD7 0x0080 lcd bkl related (on=1) |
| 20:38.37 | cr2 | Echo31: GPIOG5 0x0020 1582 present, CPLD2 location (get) |
| 20:39.09 | pH5 | given that, I think the htc-egpio driver should either use (.initial_values & .direction) as initial values and/or at warn when (.initial_values & ~.(direction)) != 0 |
| 20:39.11 | cr2 | Echo31: it's an input gpio that tells you that CPLD1 is at 0x09000000 |
| 20:39.15 | Echo31 | cr2: It is my usb client |
| 20:39.51 | cr2 | Echo31: then your device setup is different from mine. |
| 20:39.54 | Echo31 | cr2: ok |
| 20:40.18 | cr2 | usb detect is here for me: GPIOE4 0x0010 USB cable irqack |
| 20:40.57 | cr2 | Echo31: "preserving" the input gpio does not make sense anyway. |
| 20:41.13 | pH5 | cr2: that's probably only the edge detect. there could be an input level bit, too |
| 20:41.53 | cr2 | pH5: didn't see any. also not in the wince drivers |
| 20:43.37 | cr2 | Echo31, pH5 the rest looks good for me |
| 20:43.37 | *** join/#htc-linux stickboy (n=anonymou@ool-457e4101.dyn.optonline.net) |
| 20:43.37 | cr2 | Echo31: can you remove this 0x20 and boot with this config ? |
| 20:43.51 | Echo31 | cr2: i change Gpin 0x20 to 0 |
| 20:44.07 | cr2 | ok |
| 20:44.37 | cr2 | pH5: any comments ? |
| 20:46.11 | cr2 | Echo31: the usb client will not work anyway. |
| 20:46.14 | pH5 | well, the irqack register shouldn't be registered with the gpio api |
| 20:46.30 | pH5 | if it contains the edge detect status |
| 20:47.03 | cr2 | pH5: it's tested (for demux) and cleared. |
| 20:47.12 | Echo31 | cr2: the LCD become white , pink and after black |
| 20:47.54 | cr2 | Echo31: what is the wince "initial" setup ? |
| 20:48.33 | cr2 | GPIOD2 0x0004 LCD panel bit2 (get) |
| 20:48.43 | cr2 | GPIOD4 0x0010 LCD panel bit4 (get) |
| 20:48.44 | pH5 | cr2: yeah, so that egpio_cpld1_chips[4] should be removed from the list |
| 20:48.53 | cr2 | we should preserve these bits |
| 20:49.00 | Echo31 | cr2: I remove the part on the irqack |
| 20:49.13 | cr2 | pH5: ok |
| 20:49.14 | pH5 | cr2: what does (get) mean? isn't that an input |
| 20:49.17 | pH5 | ? |
| 20:49.40 | cr2 | pH5: it's not written , but queried |
| 20:49.40 | pH5 | also, I'd remove those .initial_values = 0x00 lines, that's just noise. |
| 20:50.08 | cr2 | pH5: but with these 2 LCD bits, it's strange. because sometimes they are written. |
| 20:50.09 | pH5 | cr2,Echo31: then .direction shouldn't be HTC_EGPIO_OUTPUT for the D bank |
| 20:50.15 | pH5 | ah, ok |
| 20:50.53 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
| 20:51.03 | Echo31 | cr2 : I remove only the initial_values for irqack? |
| 20:51.32 | cr2 | pH5: first i've thought it's an LCD panel id, but later saw some piece of code that writes there. |
| 20:51.41 | pH5 | Echo31: no, the complete E bank htc_egpio_chip shall be removed |
| 20:52.03 | Echo31 | cr2: The last time, you said a output |
| 20:52.36 | cr2 | Echo31: what values for these 2 bits you have in wince ? have your checked your wince dmesg ? |
| 20:52.46 | cr2 | i'll look in my logs |
| 20:54.36 | *** join/#htc-linux pe7er (n=Adium@f053195042.adsl.alicedsl.de) |
| 20:55.16 | Echo31 | cr2: I remove Ebank and i shift the gpio_base |
| 20:58.04 | cr2 | ok |
| 20:58.20 | cr2 | can't find my athena dmesg |
| 20:59.44 | cr2 | <PROTECTED> |
| 20:59.51 | cr2 | <PROTECTED> |
| 21:00.07 | cr2 | let's check |
| 21:00.35 | Echo31 | cr2: after the changes, athena boots, the LCD become grey and after white |
| 21:00.47 | cr2 | 34 , ca , 5b, 90, 00, ff , 21, a |
| 21:01.05 | cr2 | Echo31: we need to preserver the 2 LCD bits |
| 21:01.46 | cr2 | A=34, B=ca, C=5b, D=90, E=00, F=21, G=a, H=0 afair |
| 21:02.00 | *** join/#htc-linux onen|openBmap (n=quassel@mry91-1-89-87-198-158.dsl.club-internet.fr) |
| 21:02.41 | cr2 | [Sa Jun 27 2009] [14:31:44] <cr2> HaRET(1)# pd 0x08000000 0x100 |
| 21:02.43 | cr2 | [Sa Jun 27 2009] [14:31:44] <cr2> 08000000 | 00000004 00500013 00fe0000 000a0021 | ......P.....!... |
| 21:02.44 | cr2 | [Sa Jun 27 2009] [14:31:44] <cr2> 08000010 | 00000000 00000000 00000000 00000000 | ................ |
| 21:02.50 | cr2 | yes, 0 |
| 21:03.19 | Echo31 | cr2: i take your contants of each bank ( E is removed) |
| 21:03.40 | cr2 | no, i need to look what do they mean |
| 21:04.40 | cr2 | GPIOA3 0x0008 battery related (bic,orr) msleep10+spi |
| 21:04.50 | cr2 | this bit is set. charging ? |
| 21:05.24 | cr2 | 3 is bt power. not needed |
| 21:05.58 | cr2 | B=0 |
| 21:06.59 | cr2 | C=0 |
| 21:08.01 | cr2 | GPIOD4 0x0010 LCD panel bit4 (get) |
| 21:08.04 | cr2 | this bit is set |
| 21:08.27 | cr2 | GPIOD7 0x0080 lcd bkl related (on=1) |
| 21:08.34 | cr2 | this one was not set for me |
| 21:08.45 | cr2 | GPIOD6 0x0040 SD power (on=1) |
| 21:08.48 | cr2 | but i had this one |
| 21:09.09 | cr2 | ok, so bit2=0 and bit4=1 |
| 21:09.18 | cr2 | E dropped |
| 21:09.33 | cr2 | F input |
| 21:09.57 | cr2 | fe/ff |
| 21:10.26 | cr2 | so, these isp1582 bits are set. |
| 21:10.39 | cr2 | G input |
| 21:11.01 | cr2 | a=8+2 |
| 21:11.11 | cr2 | unknown |
| 21:11.21 | cr2 | hm. sorry |
| 21:12.42 | cr2 | 21 |
| 21:12.45 | cr2 | GPIOG0 0x0001 battery related (get) |
| 21:12.50 | cr2 | status ? |
| 21:13.02 | cr2 | Echo31: is our battery full charged ? |
| 21:13.41 | Echo31 | cr2: now the led is orange ( soon green) |
| 21:13.47 | cr2 | also keep in mind that the +0xe register is missing |
| 21:14.14 | cr2 | Echo31: dump the cpld1 regs, when the led is green |
| 21:14.52 | cr2 | <PROTECTED> |
| 21:14.54 | cr2 | <PROTECTED> |
| 21:15.01 | cr2 | Echo31: = 8 ? |
| 21:15.07 | cr2 | pH5: right ? |
| 21:16.11 | Echo31 | cr2: now i have |
| 21:16.11 | Echo31 | [6] ={ |
| 21:16.11 | Echo31 | .reg_start = 7,// Bank H Output |
| 21:16.11 | Echo31 | |
| 21:16.23 | Echo31 | cr2: E is dropped |
| 21:16.26 | cr2 | Echo31: i think it should be 8 |
| 21:16.42 | cr2 | pH5: need a comment :) |
| 21:17.14 | cr2 | Echo31: it's offset is 8*2=0x10 |
| 21:17.45 | Echo31 | cr2: it is the 8th register |
| 21:17.54 | cr2 | yes |
| 21:18.38 | cr2 | should be I actually |
| 21:18.54 | tmzt | cool |
| 21:18.59 | tmzt | what was missing? |
| 21:20.25 | cr2 | tmzt: what android code calls msm_snd ioctls ? |
| 21:20.43 | cr2 | tmzt: to select the input/output device |
| 21:21.11 | Echo31 | cr2 : for you offset = .reg_start ? |
| 21:21.27 | cr2 | tmzt: i suggest to create a wiki table for the ADSP queues and such things. |
| 21:21.51 | cr2 | Echo31: yes, but we need to ask pH5. i'm too lazy to look into the actual code. |
| 21:22.23 | cr2 | tmzt: so we may have a side-by-side comparison of dzo amss4, amss6210,amss6220,... |
| 21:22.27 | tmzt | I think acoustic |
| 21:22.42 | tmzt | whatever it is we don't have source |
| 21:23.00 | cr2 | which .so ? |
| 21:23.04 | tmzt | it might be libhardware actual, but legacy doesn't have it |
| 21:23.14 | tmzt | not sure |
| 21:23.21 | tmzt | Jr: ping |
| 21:23.37 | pH5 | what's the problem? the H bank was reg_start=8 before, which was correct |
| 21:24.19 | cr2 | pH5: i see in the patch .reg_start = 7, // H Output |
| 21:25.01 | pH5 | yeah, please disregard |
| 21:25.16 | pH5 | the eighth register is number 7 |
| 21:25.28 | cr2 | tmzt: eh ? /dev/msm_audpre |
| 21:25.46 | cr2 | pH5: H is +0x10 |
| 21:25.55 | cr2 | pH5: in the list |
| 21:26.34 | cr2 | tmzt: and /dev/msm_pcm_ctl |
| 21:27.07 | cr2 | <PROTECTED> |
| 21:27.27 | cr2 | HANDSET |
| 21:27.28 | cr2 | HEADSET |
| 21:27.30 | cr2 | CARKIT |
| 21:27.33 | pH5 | so H is the 9th register? |
| 21:27.47 | pH5 | if so, .reg_start = 8 |
| 21:28.25 | cr2 | tmzt: _ZN7android31check_and_set_audpre_parametersEPci |
| 21:28.32 | cr2 | pH5: yes, that's what i say |
| 21:28.36 | Echo31 | H is 7th or 8th ? |
| 21:28.43 | cr2 | 8th |
| 21:28.51 | cr2 | from 0, so it's 9th :) |
| 21:29.23 | cr2 | tmzt: _ZN7android30check_and_set_audpp_parametersEPci |
| 21:29.29 | pH5 | but I thought this thing only has 8 registers, 4 + irqack + 3 more? |
| 21:29.47 | *** part/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
| 21:30.41 | cr2 | pH5: yes, but there is a hole at +0xe |
| 21:31.05 | pH5 | aha |
| 21:31.14 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
| 21:31.27 | cr2 | tmzt: yeah, objdump -d --demangle=gnu libhtc_acoustic.so |
| 21:31.40 | cr2 | tmzt: 00003190 <snd_get_endpoint>: |
| 21:31.59 | Echo31 | cr2: find the updated code http://fr.pastebin.ca/1478826 |
| 21:32.43 | cr2 | <PROTECTED> |
| 21:32.44 | cr2 | <PROTECTED> |
| 21:32.56 | cr2 | pH5: what should be at the .end ? |
| 21:33.26 | pH5 | .end = .start + size - 1 |
| 21:33.41 | cr2 | ok |
| 21:33.52 | cr2 | Echo31: G and H don't need .initial |
| 21:33.57 | pH5 | in your case 0x10-1 seems to be the right choice? |
| 21:34.39 | cr2 | Echo31: add the comment to 0x10 .initial that it's LCD panel bit |
| 21:34.41 | Echo31 | cr2: i remove initial of G and H |
| 21:35.12 | cr2 | pH5: 0x10 ? |
| 21:35.46 | cr2 | pH5: isn't it 0x12 ? |
| 21:36.03 | pH5 | yeah. I think I'm going to resign from this discussion now :) |
| 21:36.15 | cr2 | :) |
| 21:36.38 | cr2 | pH5: it's just a complex driver with no docs. |
| 21:40.35 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 21:42.57 | cr2 | Echo31: does it boot now ? |
| 21:45.48 | Echo31 | cr2: the LCD is grey and after brightness |
| 21:47.20 | cr2 | Echo31: add the bkl bit to .initial |
| 21:48.10 | Echo31 | cr2: on cpld2 |
| 21:48.26 | cr2 | GPIOD7 0x0080 lcd bkl related (on=1) |
| 21:48.35 | cr2 | on cpld1 |
| 21:48.41 | Echo31 | cr2: ok |
| 21:48.42 | cr2 | and 0x23 for cpld2 |
| 21:51.20 | Echo31 | cr2; the LCD become red and after black |
| 21:51.27 | cr2 | hmm |
| 21:52.14 | cr2 | something is wrong then |
| 21:53.24 | Echo31 | cr2: I resend the code http://fr.pastebin.ca/1478871 |
| 21:55.01 | cr2 | change to 0x12 |
| 21:55.07 | cr2 | <PROTECTED> |
| 21:55.09 | cr2 | ? |
| 21:56.46 | *** join/#htc-linux Jim_P (n=Miranda@p57BB277F.dip.t-dialin.net) |
| 21:58.43 | Echo31 | cr2: the same thing |
| 22:02.36 | cr2 | yeah. dfficult without a serial console |
| 22:06.15 | *** join/#htc-linux Squarc (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 22:12.38 | Echo31 | cr2: Perhaps a undefined gpio from cpld1 with a incorrect init_value |
| 22:12.39 | tmzt | does usb work? |
| 22:12.59 | tmzt | newer kernels should support usb console |
| 22:13.05 | tmzt | with serial gadget |
| 22:13.59 | Echo31 | tmzt : with usb host |
| 22:15.44 | cr2 | tmzt: usb client does not work |
| 22:15.50 | cr2 | it's isp1582/3 chipset |
| 22:16.31 | cr2 | there is old philips-written driver, but it's not very useful |
| 22:17.36 | *** join/#htc-linux Squarc1 (n=Squarc@82-217-32-29.cable.quicknet.nl) |
| 22:20.33 | tmzt | ah |
| 22:21.34 | cr2 | Echo31: if you don't touch the cpld gpios, nothing should actually happen |
| 22:23.03 | cr2 | Echo31: how does your cpld2 declaration looks like ? can you post the whole file ? |
| 22:24.05 | Echo31 | cr2: ok |
| 22:25.46 | Echo31 | cr2: find http://fr.pastebin.ca/1478904 |
| 22:26.28 | cr2 | .gpio_base = NR_BUILTIN_GPIO + 64 ? |
| 22:26.47 | cr2 | why 64 ? |
| 22:26.50 | Echo31 | cr2: I can remove 8 for the gpio_base of cpld2 |
| 22:27.16 | Echo31 | cr2: it was 8*8 now 8*7 |
| 22:27.57 | cr2 | the irq pins do not count ? |
| 22:28.40 | *** join/#htc-linux MrKeuner (n=This@unaffiliated/mrkeuner) |
| 22:29.08 | cr2 | ok |
| 22:29.18 | Echo31 | cr2: for 64 , I don't think a big importance |
| 22:29.35 | *** join/#htc-linux MethoS (n=clemens@host-091-096-215-205.ewe-ip-backbone.de) |
| 22:30.28 | cr2 | you should not create holes |
| 22:30.37 | cr2 | <PROTECTED> |
| 22:30.38 | cr2 | <PROTECTED> |
| 22:31.46 | Echo31 | cr2: where are the holes? |
| 22:32.28 | cr2 | 8*8 |
| 22:33.29 | cr2 | again .initial_values for HTC_EGPIO_INPUT |
| 22:33.57 | Echo31 | cr2: if I comment cpld1, the cpld2 works with 8*8 |
| 22:34.09 | cr2 | tmzt: so, what is your idea to debug adsp ? |
| 22:34.43 | cr2 | Echo31: cpld1 only ? |
| 22:35.25 | Echo31 | cr2: I can try. |
| 22:37.58 | Echo31 | cccr2: It is the same behaviour that cpld1+cpld2 |
| 22:50.54 | *** part/#htc-linux MrKeuner (n=This@unaffiliated/mrkeuner) |
| 23:05.28 | *** join/#htc-linux nebi (n=nebi@217.142.147.19) |
| 23:07.00 | tmzt | cr2: I think we can dump rpc packets in the kernel on a g1 |
| 23:09.26 | cr2 | tmzt: does not help -> different amss |
| 23:09.51 | cr2 | on wince i have traced all the packets. |
| 23:10.22 | cr2 | it's more about the adsp config differences. |
| 23:11.50 | cr2 | this adsp driver is a google cuckoo's egg |
| 23:14.20 | cr2 | good night |
| 23:17.56 | *** join/#htc-linux darkstar62 (n=darkstar@97-126-107-190.tukw.qwest.net) |