| 00:03.22 | *** join/#openmoko peter__b (~peter_b@mnch-5d872697.pool.mediaWays.net) |
| 00:34.12 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 00:38.38 | *** join/#openmoko PaulF (~pavel@ppp85-141-66-56.pppoe.mtu-net.ru) |
| 01:05.25 | *** join/#openmoko Defiant (~Defiant@e177141242.adsl.alicedsl.de) |
| 01:12.13 | *** join/#openmoko fredrin (~Fredrik@cm-84.208.108.15.getinternet.no) |
| 01:13.34 | *** join/#openmoko fredrin (~Fredrik@cm-84.208.108.15.getinternet.no) |
| 01:20.39 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 01:23.29 | *** join/#openmoko rooly (~chris@ip174-64-161-112.lf.br.cox.net) |
| 02:14.33 | *** join/#openmoko pcfe (~pcfe@a88-115-26-73.elisa-laajakaista.fi) |
| 02:14.33 | *** join/#openmoko pcfe (~pcfe@redhat/pcfe) |
| 02:17.37 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 03:02.13 | *** join/#openmoko brian (~brian@ip72-204-125-6.fv.ks.cox.net) |
| 03:06.20 | *** join/#openmoko borg__ (~olaf@p54868035.dip0.t-ipconnect.de) |
| 03:16.36 | brian | su |
| 03:18.57 | brian | br549er |
| 03:19.02 | brian | haha |
| 03:19.38 | brian | "Doc" any good hardware news? |
| 03:40.39 | *** join/#openmoko astrocub (~astrocub@unaffiliated/ibuffy) |
| 03:57.09 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 04:07.10 | *** join/#openmoko johnsu01` (~user@fencepost.gnu.org) |
| 04:12.18 | *** join/#openmoko eolson (~eolson@c-24-13-244-61.hsd1.il.comcast.net) |
| 04:13.08 | *** join/#openmoko cz_jc (~jc@88.146.126.102) |
| 04:33.57 | *** join/#openmoko DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 04:40.19 | *** join/#openmoko SparFux (~raoul@g224211127.adsl.alicedsl.de) |
| 05:02.13 | *** join/#openmoko mrmoku|a` (~mrmoku@ppp-188-174-86-157.dynamic.mnet-online.de) |
| 05:16.04 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 05:23.43 | SparFux | Does anybody own a Samsung mobile? I ask myself for how long I have to load the battery for the first time. After short display of loading battery, the screen is now black for 10 hours already. |
| 05:23.55 | SparFux | And the manual is crap, I have to say. |
| 05:52.03 | *** join/#openmoko yanu (~yanu@d51A5B984.access.telenet.be) |
| 05:52.03 | *** join/#openmoko yanu (~yanu@lugwv/member/yanu) |
| 06:12.39 | *** join/#openmoko Heinervdm (~thomas@pD9E151CB.dip.t-dialin.net) |
| 06:14.13 | *** join/#openmoko SparFux1 (~raoul@g224210230.adsl.alicedsl.de) |
| 06:14.33 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 06:16.17 | *** join/#openmoko drscream (~drscream@gw.it.tt.avira.com) |
| 06:23.51 | *** join/#openmoko Judge_Gregg (~quassel@lib59-7-88-185-52-126.fbx.proxad.net) |
| 06:31.48 | *** join/#openmoko geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 07:00.48 | *** join/#openmoko Gabrys (~Gabrys@89.229.55.160) |
| 07:04.14 | *** join/#openmoko Kame2 (~manuel@port-92-196-242-133.dynamic.qsc.de) |
| 07:09.51 | *** join/#openmoko playya__ (~playya@unaffiliated/playya) |
| 07:15.06 | *** join/#openmoko zoff99 (chatzilla@chello080109110017.13.15.vie.surfer.at) |
| 07:17.17 | *** join/#openmoko astrocub (~astrocub@unaffiliated/ibuffy) |
| 07:22.25 | *** join/#openmoko zoff99 (chatzilla@chello080109110017.13.15.vie.surfer.at) |
| 07:26.44 | *** join/#openmoko Amorphous (jan@unaffiliated/amorphous) |
| 07:27.28 | *** join/#openmoko radekp (~radek@88.146.48.30) |
| 07:32.15 | *** join/#openmoko radek_ (~radek@88.146.48.30) |
| 07:44.01 | *** join/#openmoko naught101 (~ned@c122-106-225-163.belrs3.nsw.optusnet.com.au) |
| 07:55.04 | *** join/#openmoko MNZ (~mnzaki@41.239.88.234) |
| 07:55.31 | *** part/#openmoko MNZ (~mnzaki@41.239.88.234) |
| 07:56.17 | *** join/#openmoko radek__ (~radek@88.146.48.30) |
| 08:13.09 | *** join/#openmoko spydon (~spydon@nl103-146-152.student.uu.se) |
| 08:15.38 | *** join/#openmoko Fish9 (~Fish@86.65.182.207) |
| 08:32.16 | *** join/#openmoko Defiant (~Defiant@e177141242.adsl.alicedsl.de) |
| 08:35.56 | *** join/#openmoko soman (~somnath@118.102.130.34) |
| 08:58.23 | *** join/#openmoko Gabrys (~Gabrys@cxp210.internetdsl.tpnet.pl) |
| 09:18.17 | *** join/#openmoko abram (~abram@78-153-84-122.soco-dsl.de) |
| 09:22.29 | *** join/#openmoko cosmos1 (~cosmos@fra06-1-88-167-178-248.fbx.proxad.net) |
| 09:22.55 | cosmos1 | hello |
| 09:23.20 | cosmos1 | how to fix opengl glx on qtmokoV26? |
| 09:23.50 | cosmos1 | ...trying to run Gem on neoFR... |
| 09:27.15 | *** join/#openmoko chihchun (~chihchun@210.240.39.7) |
| 09:44.45 | *** join/#openmoko pespin (~pespin@175.pool85-50-90.dynamic.orange.es) |
| 09:59.44 | gena2x | cosmos1: hi |
| 09:59.58 | gena2x | cosmos1: i saw your message at #qtmoko |
| 10:00.29 | gena2x | cosmos1: qtmoko has a bit special xserver (XGlamo) |
| 10:01.25 | gena2x | cosmos1: anyway, no driver supporing glx (in hardware) exist at this moment |
| 10:02.03 | gena2x | cosmos1: software rendering speed will be... below any usability. |
| 10:02.08 | gena2x | cosmos1: why do you need it? |
| 10:03.45 | gena2x | cosmos1: what is Gem? |
| 10:25.08 | *** join/#openmoko naeg (~naeg@111-166-19-84.nbiserv.com) |
| 11:13.39 | cosmos1 | gena2x: Gem is a puredata extension for rendering and processing images, 3D objects and video. |
| 11:14.54 | cosmos1 | gena2x: and for pure data, see: |
| 11:14.55 | cosmos1 | http://puredata.info/ |
| 11:16.17 | cosmos1 | gena2x: actually you can run puredata on qtmoko via qx (apt-get install puredata). |
| 11:19.09 | cosmos1 | The best is to create windows that fit the FR screen (480 x 612) considering the upper tab. Also the interface should be minimal, with few big bang objects. |
| 11:19.18 | gena2x | cosmos1: unfortunately, current Xglamo missing some important extensions and stock Xserver has vt switching bug. |
| 11:20.06 | gena2x | cosmos1: may be it is possible to fix this problem by recompilation of Xglamo |
| 11:20.25 | gena2x | cosmos1: but this is sure not a priority at this moment |
| 11:21.41 | gena2x | cosmos1: contact radek__ if you want sources to investigate this problem at your own |
| 11:22.28 | cosmos1 | gena2x: ok, it would be nice in the future to run puredata + gem (why not pd-exdended) and Processing on the FR |
| 11:23.42 | radek__ | cosmos1: there is a plan to replace Xglamo with full xserver with glamo driver, but cant tell when it will be done... |
| 11:23.44 | cosmos1 | gena2x: Processing: |
| 11:23.45 | cosmos1 | http://processing.org/ |
| 11:24.05 | radekp | gena2x: btw any news about the power bug? :) |
| 11:24.44 | gena2x | radekp: sure. |
| 11:24.54 | cosmos1 | radekp: you mean the recamping bug? |
| 11:25.07 | gena2x | cosmos1: no |
| 11:25.16 | radekp | cosmos1: nono, the bug with hugh current in suspend |
| 11:25.28 | gena2x | radekp: i have patch |
| 11:25.30 | cosmos1 | gena2x: you mean the black screen? |
| 11:25.43 | radekp | gena2x: nice, still stesting it? |
| 11:25.45 | gena2x | cosmos1: http://docs.openmoko.org/trac/ticket/2349#comment:13 |
| 11:26.02 | gena2x | radekp: it works well |
| 11:26.18 | gena2x | radekp: but seem something else is broken |
| 11:26.28 | gena2x | radekp: not by this patch |
| 11:27.01 | radekp | gena2x: what does it mean "something else"? |
| 11:27.20 | gena2x | radekp: want full details? :) |
| 11:27.56 | gena2x | no, really i mean if it is interesting, i can describe |
| 11:28.02 | radekp | gena2x: sure :) |
| 11:28.35 | radekp | yes it's very interesting for me, i would like to start using 2.6.34 kernel |
| 11:29.42 | gena2x | ok. all regulators has 'ENA' registers. ENA may be turned on/off or tied to one or more PCF's GPIOs, so it will be switched even manually or automatically with GPIO. |
| 11:30.06 | gena2x | regulator in question is cpu core 1.3v (DOWN1) |
| 11:30.21 | gena2x | cpu has special signal to turn it on/off |
| 11:31.14 | gena2x | (PWREN). so power off automagically while suspend and on on resume. |
| 11:32.06 | gena2x | so, ENA register should just set GPIO and nobody should touch it. u-boot does exactly this. |
| 11:32.29 | gena2x | but kernel has definitions for each register |
| 11:32.57 | gena2x | and kernel regulator infrastructure tries to manage it |
| 11:33.10 | gena2x | so it turns this on manually on boot |
| 11:33.17 | gena2x | but do not turn off in suspend |
| 11:33.40 | radekp | hmm interesting... |
| 11:33.51 | gena2x | it has special field in platform structure with special field to turn it off in suspend. |
| 11:34.05 | gena2x | and this seem worked in .29 |
| 11:34.30 | gena2x | so, now kernel _should_ turn it on/off while suspend/resume. |
| 11:34.43 | gena2x | as far as i understand |
| 11:34.53 | gena2x | so, two problems here |
| 11:35.11 | gena2x | 1. why in hell it touches it at all |
| 11:36.29 | gena2x | 2. why if it ordered to turn it off while suspend to ram it is actually not doing this. |
| 11:36.53 | gena2x | that's all in fact. |
| 11:37.07 | gena2x | now i am trying to answer this question |
| 11:38.12 | *** join/#openmoko Orias_Korva (~atilla@dct27.wtb.tue.nl) |
| 11:41.04 | gena2x | so, as regulator infrastucture if for manual managing |
| 11:41.35 | gena2x | (contolling only 1 bit) i think it should just be set to off. |
| 11:41.54 | gena2x | i mean set to never turn on this bit |
| 11:42.06 | gena2x | this will fix (1) |
| 11:42.22 | gena2x | but would be good to understand what happened with (2) |
| 11:42.26 | gena2x | radekp: ok? |
| 11:44.23 | radekp | gena2x: you i i think i understand |
| 11:44.31 | radekp | s/you/yup |
| 11:45.01 | radekp | gena2x: but this is not related to #2349? or is it? |
| 11:45.28 | gena2x | seem you didn't understood :) |
| 11:45.56 | gena2x | setting manually this bit to 1, enables DOWN1 output |
| 11:46.25 | gena2x | so it stay enabled while suspend independently of PWREN |
| 11:46.45 | gena2x | and eats that additional milliwats |
| 11:48.47 | gena2x | by 'manually' i mean contolling it not via GPIO but intead via automatic linux regulator infrastructure |
| 11:49.28 | gena2x | being more simple, if you disable that bit and not let regulators touch it, you'll get your 5mA. |
| 11:50.21 | gena2x | now relation is clear? |
| 11:55.38 | cosmos1 | radekp: do you think that is actually possible to install Processing on the GTA2? |
| 11:56.34 | radekp | gena2x: ahh oki, i think it's clear |
| 11:56.45 | radekp | cosmos1: no idea... |
| 11:57.54 | radekp | gena2x: so you have working patch, but you want to explore it more... |
| 11:58.23 | gena2x | my personal kernel suspend still suffers from other problems |
| 11:58.33 | *** join/#openmoko JesusMcCloud-lt (~Jesus@84-119-56-172.dynamic.xdsl-line.inode.at) |
| 11:58.40 | gena2x | i mean GPS and GSM power_on/power_off things |
| 11:58.54 | gena2x | i still have to do this |
| 11:59.09 | gena2x | but strange enought, not on first boot |
| 11:59.28 | gena2x | but overall current is now ok |
| 11:59.38 | gena2x | i'll publish patch now |
| 12:01.18 | gena2x | ah, i forgot i added script to check suspend which does power_on/power_off automagically |
| 12:01.49 | gena2x | ah, i also forgot that you had some patches to fix gps/gsm issue |
| 12:02.15 | gena2x | but i also should not that after powering on/off i have no need to issue any commands to modem |
| 12:02.24 | gena2x | s/not/add/ |
| 12:02.26 | larsc | radekp: do you know who is supposed to set reg 0x1f? the bootloader or the kernel? |
| 12:04.02 | radekp | larsc: no idea, ask gena2x :) |
| 12:04.09 | larsc | ok |
| 12:05.21 | gena2x | larsc: did you read my description? |
| 12:05.31 | gena2x | above |
| 12:06.19 | lindi- | these pcf registers are available over i2c? |
| 12:06.36 | gena2x | yes |
| 12:06.42 | larsc | gena2x: not yet. will do now |
| 12:11.15 | *** join/#openmoko esa-petri (~esa-petri@nobe.lnet.fi) |
| 12:14.40 | larsc | gena2x: what is your proposed fix? |
| 12:15.25 | gena2x | larsc: adding it now to bug report |
| 12:15.31 | gena2x | moment |
| 12:16.10 | larsc | ok |
| 12:19.38 | *** join/#openmoko esa-petri (~esa-petri@nobe.lnet.fi) |
| 12:31.52 | gena2x | larsc: ok, checked qi code and patch is http://www.bsdmn.com/openmoko/pr2349donot_manage_down1.diff |
| 12:32.43 | larsc | well, thats the easy way. but yes it works |
| 12:33.17 | gena2x | this is not only easy way but also only one which is right imo |
| 12:33.38 | gena2x | idea how to do it in better way? |
| 12:34.03 | gena2x | general ideas accepted too |
| 12:34.05 | gena2x | :) |
| 12:35.07 | larsc | nothing thats not overly complicated |
| 12:35.11 | *** join/#openmoko d1b (~db@d1b.org) |
| 12:37.10 | gena2x | i thing kernel should not touch that regulator |
| 12:37.37 | gena2x | because no reason exist to touch it |
| 12:38.01 | gena2x | as it should be managed by PWREN |
| 12:38.50 | gena2x | i see no even complicated way to do it better |
| 12:40.37 | gena2x | but all this leaves question (2) - why .state_mem.enable=0 is not working |
| 12:42.01 | larsc | .state_mem is complicated |
| 12:42.45 | larsc | a regultor driver needs special callbacks like set_suspend_{state,voltage,etc.} to apply state_mem |
| 12:42.50 | *** join/#openmoko sigi (~sigius@93-125-185-45.dsl.alice.nl) |
| 12:43.32 | larsc | furthermore the machine code needs to call regulator_set_suspend, when it suspends |
| 12:43.43 | larsc | we have neither |
| 12:44.14 | *** join/#openmoko Ryback_ (~ulisses@enlightenment/developer/ryback) |
| 12:44.17 | gena2x | hm. DOWN1 is not alone with .state_mem.enabled==0 |
| 12:45.16 | gena2x | may be this is cause of my gsm/gps problems.. |
| 12:45.30 | gena2x | may be i'll try to solve (2) too, but later |
| 12:45.30 | larsc | i think we should drop the whole state_mem fields cause they are not used and might confuse someone who reads the code |
| 12:45.49 | gena2x | really not used? |
| 12:45.52 | larsc | yes |
| 12:46.01 | gena2x | but worked in .29? |
| 12:46.08 | larsc | don't think so |
| 12:46.34 | gena2x | but regulators (non-pcf code) has support for this |
| 12:47.09 | larsc | yes. but the machine code needs to call regulator_set_suspend |
| 12:47.25 | larsc | otherwise the core will never look at those fields |
| 12:48.02 | larsc | and the regulator driver needs to implement the set_suspend_{enabled,disabled} callbacks |
| 12:49.35 | larsc | s,regulator_set_suspend,regulator_suspend_prepare, |
| 12:50.46 | gena2x | gena@work:~/prg/openmoko/kernel5/linux-2.6/drivers/regulator$ global -rx regulator_suspend_prepare |
| 12:50.46 | gena2x | regulator_suspend_prepare 183 ../../include/linux/regulator/machine.h int regulator_suspend_prepare(suspend_state_t state); |
| 12:51.01 | gena2x | ops |
| 12:51.05 | gena2x | wrong paste |
| 12:51.22 | gena2x | ignore please |
| 12:54.14 | gena2x | interesting, may be we are missing more power because of this. |
| 12:55.45 | radekp | i wonder how much the current should really be - if my measuring was ok then modem takes like 3mA in deep sleep |
| 12:56.17 | gena2x | i have 5mA |
| 12:56.25 | larsc | just found this patch http://www.mail-archive.com/openmoko-kernel@lists.openmoko.org/msg05811.html |
| 12:56.27 | gena2x | without modem i hope |
| 12:57.05 | *** join/#openmoko gcwilson (~gcwilson@cpe-70-112-194-75.austin.res.rr.com) |
| 12:59.06 | radekp | will measure it |
| 12:59.12 | gena2x | nice comment - /* Wow, when we are going into suspend, after pcf50633 |
| 12:59.12 | gena2x | - * runs its suspend (which happens real early since it |
| 12:59.12 | gena2x | - * is an i2c device) we are running out of the 22uF cap |
| 12:59.12 | gena2x | - * on core_1v3 rail !!!! |
| 12:59.12 | gena2x | - */ |
| 13:00.18 | larsc | reading the follow-up comments it seems the patch is wrong |
| 13:02.13 | gena2x | hm.. pmu has standby... |
| 13:02.44 | gena2x | i didn't focus my attention to this fact |
| 13:03.01 | *** join/#openmoko bentob0x (~laurent@ip-213-49-115-226.dsl.scarlet.be) |
| 13:03.10 | *** join/#openmoko beneth` (~beneth`@beneth.fr) |
| 13:03.53 | larsc | when the pmu is in standby the system is off |
| 13:08.02 | gena2x | finished reading |
| 13:09.20 | gena2x | anyway to remove mem structs we should review regulators with .enabled==0 |
| 13:10.16 | gena2x | and that callbacks should not be complicated |
| 13:10.41 | gena2x | (i have no scheme in my head now) |
| 13:10.42 | *** join/#openmoko alexxy (~alexxy@gentoo/developer/alexxy) |
| 13:11.50 | gena2x | if something may be disabled on suspend, it should be disabled. |
| 13:12.08 | larsc | well, we would have to tell the driver what pin to use as a indicator whether the system is in suspend |
| 13:13.05 | gena2x | and if state_mem.enabled==0 is only (nonhack) way to implement this disabling, it should be implemented |
| 13:13.07 | larsc | and then in the set_suspend_{enabled,disabled} callback set the bit for that gpio |
| 13:13.34 | larsc | enabled == 0 alone does nothing you also need disabled = 1 |
| 13:14.29 | larsc | DocScrutinizer: do you have any idea how memldo is wired up? It's not clear to me from the schematics |
| 13:14.35 | gena2x | stop, stop. i lost you. |
| 13:15.03 | DocScrutinizer51 | sorry, afk |
| 13:15.21 | DocScrutinizer51 | what's your precise Q? |
| 13:15.40 | gena2x | we are speaking about state_mem for all regultors now? |
| 13:15.56 | gena2x | ah |
| 13:16.01 | gena2x | i got your idea |
| 13:16.15 | larsc | DocScrutinizer: is it connected to the same consumers than down2? |
| 13:16.19 | gena2x | use gpio pin instead of state_mem mechanism? |
| 13:16.54 | DocScrutinizer51 | what is memldo? a signal name? |
| 13:17.18 | DocScrutinizer51 | or the regulator in pcd50633? |
| 13:17.25 | larsc | DocScrutinizer: the later |
| 13:17.32 | DocScrutinizer51 | mompl |
| 13:17.50 | larsc | gena2x: combine them both. |
| 13:18.16 | *** join/#openmoko methril_ (~methril@189.27.129.89.dynamic.adsl.gvt.net.br) |
| 13:18.23 | larsc | gena2x: for .state_mem to work you need some kind of indicator for the regulator whether the system is in suspend or not |
| 13:18.45 | gena2x | such 'indicator' is callback, yes? |
| 13:19.06 | larsc | the indicator would be the gpio pin |
| 13:20.12 | DocScrutinizer | larsc: there's no memldo |
| 13:20.31 | larsc | yes there is |
| 13:21.29 | larsc | but i think i now have understood how it works. |
| 13:21.32 | gena2x | i mean with mem_state mechanism, we can control via callbacks. on suspent, well get control, turn off regulator manually and turn on resume manually too |
| 13:22.35 | larsc | i guess we would be turing the regulator of to early if we'd disable it directly from the callback |
| 13:23.02 | gena2x | but if we'll made it GPIO driven (GPIO1 of pcf is active then cpu is not in suspend), it will work automagically |
| 13:23.20 | gena2x | but we'll have to enable GPIO bit install of unconditional on. |
| 13:23.26 | gena2x | s/install/instead/ |
| 13:23.54 | DocScrutinizer | larsc: there's auto, down1/2, HCLDO, LDO1..6 |
| 13:24.02 | DocScrutinizer | no memldo |
| 13:24.08 | gena2x | so we'll have no need in callbacks at all |
| 13:24.56 | DocScrutinizer | sdram is powered via SDRAM_1V8 derived from IO_1V8 |
| 13:26.39 | DocScrutinizer | IO_1V8 is from DOWN2 |
| 13:26.47 | gena2x | but i do not understand why conbine this two methods :) |
| 13:28.44 | larsc | DocScrutinizer: well the pcf50633 certainly has a memldo. but i guess it is not used? |
| 13:29.06 | larsc | gena2x: i think the best solution right now is to keep your approch |
| 13:29.19 | DocScrutinizer | WTF? turn off mem VDD regulator? that's not possible physically (as there's no such thing as a mem LDO) and logically (as your system will fail to resume when RAM isn't powered) |
| 13:29.48 | gena2x | DocScrutinizer: yes |
| 13:30.02 | gena2x | DocScrutinizer: it has MEMLDO -> max current 1mA |
| 13:30.21 | DocScrutinizer | gena2x: so what? read pcf50633 datasheet? |
| 13:30.29 | gena2x | now reading! |
| 13:30.59 | DocScrutinizer | iirc there's memldo in parallel to down2(?) to supply mem with VDD when system in syspend |
| 13:31.05 | DocScrutinizer | suspend* |
| 13:31.51 | gena2x | 'The volatile memory is intended to be supplied by DOWN2 in Active state and by MEMLDO in non-active states' |
| 13:32.05 | larsc | DocScrutinizer: yes. that was the question, whether it actually is |
| 13:32.24 | DocScrutinizer | it's an alternative lightweight method to supply power to a regulator output that otherwise (during normal operation) is powered by a strong switching converter iirc |
| 13:32.26 | larsc | cause right now I think DOWN2 is always on |
| 13:33.14 | DocScrutinizer | depends on your system's power requirements on that VDD rail, during suspend |
| 13:33.25 | *** join/#openmoko djp_ (~djp@fsf/member/djp-) |
| 13:33.35 | DocScrutinizer | if it's too high for memldo you need to keep on down2 |
| 13:34.41 | DocScrutinizer | anyway you can *try* to switch to memldo as very last step prior to suspend, and IF it resumes after that, switch to down2 very first action after resume |
| 13:35.01 | larsc | guessing from the numbers in the schematics the freerunner seems to need at least 2ma from down2/memldo |
| 13:35.14 | gena2x | larsc: memldo == DOWN2FB pin, connected to DOWN2 |
| 13:35.23 | DocScrutinizer | that's probably the reason for memldo not being used then |
| 13:35.30 | gena2x | DocScrutinizer: not really. |
| 13:35.40 | gena2x | DocScrutinizer: i mean 'last first' thing |
| 13:36.05 | DocScrutinizer | gena2x: ?? |
| 13:36.25 | gena2x | DocScrutinizer: we can kindly ask pcf to bind it to GPIO1 |
| 13:36.33 | DocScrutinizer | there *might* be other ever higher prio things to do |
| 13:36.54 | gena2x | DocScrutinizer: so it will be put up as soon as cpu core resumes |
| 13:36.58 | gena2x | and automagically |
| 13:37.06 | DocScrutinizer | sounds nice, yes |
| 13:37.29 | gena2x | hm... why not try now? :) |
| 13:41.18 | gena2x | yeah, we sure not using it, as even voltage not set :) |
| 13:43.26 | gena2x | hm. can this two be enabled at once? |
| 13:44.09 | gena2x | DocScrutinizer: ^? |
| 13:44.32 | larsc | gena2x: memldo will be automatically off if down2 is on |
| 13:44.41 | DocScrutinizer51 | gena2x: don't get it wrong (polarity aka logic/inverted logic), when core goes down you DISable down2 and ENable memld |
| 13:44.57 | gena2x | thanks. seems missed this. |
| 13:45.07 | larsc | so memldo should be set to always on |
| 13:45.19 | larsc | and down2 to on when gpio1 is high |
| 13:45.40 | gena2x | ok. i'll test how this affect suspend current |
| 13:45.46 | DocScrutinizer51 | memldo is largely irrelevant |
| 13:46.12 | DocScrutinizer51 | always on or dowwn2^-1 |
| 13:46.51 | DocScrutinizer51 | anyway GPIO must switch OFF down2 |
| 13:48.29 | DocScrutinizer51 | if it's really down2 (not checked) |
| 13:48.53 | gena2x | ok, all clear. setting proper values now. |
| 13:53.24 | *** join/#openmoko CVirus (~Satan@41.130.233.90) |
| 13:55.37 | DocScrutinizer | so I can close document /home/jr/Documents/OpenMoko/GTA02/GTA02-MB-A7_50-71481-01.pdf ? :-D |
| 13:56.24 | gena2x | i have no questions atm, thanks |
| 13:56.30 | DocScrutinizer | yw |
| 14:07.05 | *** join/#openmoko ruskie (ruskie@sourcemage/mage/ruskie) |
| 14:08.01 | *** join/#openmoko pabs3 (~pabs@d122-104-118-138.per9.wa.optusnet.com.au) |
| 14:08.36 | pabs3 | any OpenMoko folks planning on coming to LCA? http://mobilefoss.jamespurser.com.au/Call_For_Papers |
| 14:13.28 | *** join/#openmoko jksa (~jksa@87.57.112.154) |
| 14:15.19 | jksa | hi guys - anyone know of a gsm 07.10 (mux) implementation that does version 4? |
| 14:16.00 | lindi- | jksa: version 4? |
| 14:16.24 | jksa | lindi-, there seems to be some kind of perhaps proprietary versioning scheme for mux'ers |
| 14:16.39 | jksa | lindi-, I have an implementation of version 3, but my unit rejects it - asking for version 4 |
| 14:16.49 | lindi- | jksa: what unit? |
| 14:17.15 | jksa | lindi-, Cinterion (Siemens) HC25 variant |
| 14:17.30 | lindi- | jksa: ok |
| 14:17.48 | jksa | Taking how hard it was to find a version 3 implementation, I thought openmoko guys would be the ones that knew the most about stuff like that |
| 14:20.38 | *** join/#openmoko johnsu01` (~user@fsf/staff/johnsu01) |
| 14:20.55 | lindi- | jksa: so you are issuing +CMUX=<mode>[,<subset>[, <port_speed>[,<N1>[,<T1> [,<N2>[,<T2>[,<T3> [,<k>]]]]]]]] ? |
| 14:21.15 | jksa | lindi-, yep |
| 14:21.17 | lindi- | "Test command returns the supported modes and parameters. The window size parameter <k> is only applicable for mode 4." |
| 14:21.23 | lindi- | so at least the standard knows about "mode 4" |
| 14:21.35 | lindi- | jksa: what do you get with the test command? |
| 14:22.44 | jksa | lindi-, I think you're mixing modes and versions together - it's not the same thing |
| 14:22.55 | lindi- | jksa: ok |
| 14:23.54 | jksa | lindi-, I can initiate gsm 07.10 with the at+cmux command just fine |
| 14:24.01 | jksa | lindi-, the unit only supports mode 0 |
| 14:24.13 | jksa | (which is also what the test command returns) |
| 14:24.27 | lindi- | jksa: how does it ask for version 4? |
| 14:25.10 | jksa | lindi-, basically it will return this text in the multiplexed channel: |
| 14:25.14 | jksa | "DO NOT USE MUX PROTOCOL <V4 IN THIS PRODUCT" |
| 14:25.17 | lindi- | ok |
| 14:25.30 | jksa | the manual also states that version 4 is required |
| 14:25.43 | lindi- | ok, I don't think I have much intel on that sorry :( |
| 14:25.50 | jksa | okay :-( |
| 14:26.00 | jksa | I'm afraid I have to implement it myself... a lot of work :-| |
| 14:26.07 | lindi- | jksa: have you found specs? |
| 14:26.39 | jksa | lindi-, yep |
| 14:26.53 | larsc | d~. |
| 14:27.00 | gena2x | larsc: just works, but no diff in consumption even seem ~+1mA. |
| 14:27.14 | lindi- | jksa: got some googleable search term? ;) |
| 14:27.17 | *** join/#openmoko naeg (~naeg@194.208.239.170) |
| 14:27.37 | jksa | lindi-, sorry, I haven't been able to find specs on google |
| 14:27.38 | larsc | gena2x: ok |
| 14:29.32 | lindi- | jksa: just give me one unique sentence so that if I find the specs through some other means I can recogonize them :) |
| 14:29.57 | jksa | lindi-, the document ID is: HC2x_Mux_Guide_v02n |
| 14:30.54 | lindi- | sounds vendor specific :) |
| 14:31.00 | *** join/#openmoko Orias_Korva (~atilla@dct27.wtb.tue.nl) |
| 14:31.21 | jksa | lindi-, I bet it is |
| 14:34.02 | lindi- | jksa: are you planning to contribute your code to linux, gsm0710muxd, ophono or ogsmd? ;) |
| 14:34.31 | jksa | lindi-, well, if I actually do implement it - yes |
| 14:34.36 | *** join/#openmoko dos11 (~dos@unaffiliated/dos1) |
| 14:34.48 | jksa | lindi-, however I'm not interesting in implementing the full thing from scratch... I rather want to build on something existing |
| 14:35.07 | jksa | lindi-, the only thing I could get to build was a program called gsmmux in alpha release 3 from 2009... :-( |
| 14:35.34 | jksa | I've downloaded cornucopia too, but I cannot get it to build on my platform |
| 14:35.58 | *** join/#openmoko Gabrys (~Gabrys@89.229.55.160) |
| 14:36.10 | gena2x | not bad, according to logs resume time is 1.5 sec, suspend .3 sec |
| 14:36.33 | lindi- | gena2x: now make it possible to resume via touchscreen and we can suspend instead of blanking :) |
| 14:36.53 | gena2x | noooooo |
| 14:37.08 | lindi- | jksa: ah cornucopia too. we have 5 implementations of 07.10 |
| 14:37.25 | lindi- | gena2x: why not? |
| 14:37.35 | gena2x | sound, wifi, ssh |
| 14:37.47 | jksa | lindi-, yeah, it's a jungle... how do I know which one is most current and maintained? |
| 14:37.51 | lindi- | gena2x: sure but it would be a great option |
| 14:38.03 | lindi- | jksa: linux is quite maintained :) |
| 14:38.07 | jksa | lindi-, if they're all maintained... which one has the least amount of dependencies on "weird stuff"? |
| 14:38.27 | jksa | lindi-, well, the mux implementation in linux is only available in 2.6.34 right? |
| 14:38.29 | gena2x | lindi-: may be we can just reduce IDLE power consumption somehow? |
| 14:38.36 | lindi- | jksa: i'm personally using gsm0710muxd since i was afraid of all the vala stuff in cornucopia |
| 14:38.46 | lindi- | gena2x: yeah that'd be cpufreq |
| 14:38.53 | jksa | lindi-, exactly - vala turned me off too |
| 14:39.05 | lindi- | jksa: something like 2.6.34 I think yes |
| 14:39.14 | jksa | lindi-, I've got to make it work on an existing platform that uses 2.6.33.. so I cannot use the in-kernel mux'er |
| 14:39.28 | lindi- | jksa: ok |
| 14:39.33 | gena2x | lindi-: no, we what about pushing memory to self-refresh while idle? |
| 14:39.44 | lindi- | jksa: I also do not have any experience on in-kernel muxers so I don't know if I can recommend them yet |
| 14:40.16 | jksa | lindi-, to me it sounds weird to have them in-kernel... they belong in user space ;-) |
| 14:40.18 | lindi- | gena2x: no idea, try if you know how |
| 14:40.43 | jksa | lindi-, gsm0710muxd... I'll take a look at that again... I just hate building stuff that requires all sorts of weird debian-style things |
| 14:40.56 | lindi- | jksa: what sort of debian style things? |
| 14:41.04 | *** join/#openmoko max_posedon (~max_posed@80.249.84.73) |
| 14:41.30 | jksa | lindi-, well, for me it couldn't build because it couldn't find glib 2.x (which is installed) - due to missing pkgconfig |
| 14:41.43 | jksa | or rather... missing pkgconfig configuration (or data files or whatever) |
| 14:41.48 | lindi- | jksa: ah |
| 14:42.10 | lindi- | jksa: have you checked if pyneo is still maintaining it? |
| 14:42.52 | jksa | not as such? |
| 14:43.13 | jksa | I've downloaded a seperate fork by some Neil guy.. let me check |
| 14:43.35 | jksa | I've checked the Pyneo web site earlier - but I left it shortly after it insulted me because of my choice of browser ;-) |
| 14:44.49 | jksa | lindi-, Neil Brown... there it was :-) |
| 14:45.09 | jksa | lindi-, http://neil.brown.name/git?p=gsm0710muxd;a=tree |
| 14:47.12 | gena2x | lindi-: our cpu has not only NORMAL IDLE and SUSPEND modes |
| 14:47.30 | gena2x | lindi-: it has also SLOW, STOP and Deep-STOp |
| 14:47.41 | lindi- | gena2x: does glamo work in those? |
| 14:48.17 | gena2x | lindi-: yes i think |
| 14:48.27 | gena2x | ah |
| 14:48.33 | gena2x | interesting |
| 14:48.44 | gena2x | need to think |
| 14:48.54 | gena2x | but why not |
| 14:50.10 | gena2x | i think glamo can 'work' in suspend too. why not? |
| 14:50.28 | lindi- | I don't know, I just recall reading about 100 MHz being minimum because of glamo |
| 14:50.37 | lindi- | it was in the cpufreq discussion iirc |
| 14:50.56 | gena2x | glamo need working memory bus? |
| 14:51.59 | lindi- | I haven't signed the glamo NDA sorry :) |
| 14:52.16 | gena2x | lindi-: np |
| 14:52.18 | gena2x | :) |
| 14:52.25 | Gabrys | lindi-: if you haven't you can actualy disclose stuff :-) |
| 14:55.20 | pabs3 | glamo works in suspend? |
| 14:56.43 | gena2x | pabs3: this were question |
| 14:57.07 | gena2x | pabs3: is this possible |
| 14:57.18 | pabs3 | oh, sorry |
| 14:57.36 | gena2x | and if it can, it can also work in STOP mode |
| 14:58.01 | gena2x | hm... should be not really hard to check... |
| 15:11.05 | *** join/#openmoko PBeck (~PBeck@unixboard/users/pbeck) |
| 15:11.15 | PBeck | hi |
| 15:24.14 | *** join/#openmoko zoff99 (chatzilla@chello080109110017.13.15.vie.surfer.at) |
| 15:34.04 | *** join/#openmoko Sup3rkiddo (~sudharsh@59.92.83.170) |
| 15:34.12 | *** join/#openmoko Sup3rkiddo (~sudharsh@unaffiliated/sudharsh) |
| 15:35.08 | *** join/#openmoko Orias_Korva (~atilla@dct27.wtb.tue.nl) |
| 15:36.36 | *** join/#openmoko pH5 (~ph5@e178217184.adsl.alicedsl.de) |
| 15:36.43 | *** join/#openmoko draioch (~draioch@93.107.25.95) |
| 15:43.36 | *** join/#openmoko cz_jc (~jc@88.146.126.102) |
| 15:52.08 | *** join/#openmoko amarsh04 (~amarsh04@ppp121-45-120-11.lns20.adl6.internode.on.net) |
| 15:57.16 | *** join/#openmoko Blu3 (~David@BlueLabs/Blu3) |
| 16:02.17 | *** join/#openmoko Judge_Gregg (~quassel@lib59-7-88-185-52-126.fbx.proxad.net) |
| 16:02.22 | *** join/#openmoko eolson (~eolson@maze.mcs.anl.gov) |
| 16:07.57 | PBeck | i searching for developer information for the wikireader |
| 16:08.18 | PBeck | is there no wiki or more then the wikireader info page? |
| 16:10.42 | SpeedEvil | DocScrutinizer is the droid you are looking for. |
| 16:12.49 | *** join/#openmoko gcwilson (~gcwilson@32.97.110.59) |
| 16:25.59 | *** join/#openmoko rooly (~chris@ip174-64-161-112.lf.br.cox.net) |
| 16:43.45 | *** join/#openmoko eolson (~eolson@maze.mcs.anl.gov) |
| 16:56.07 | *** join/#openmoko methril_work (~methril@201.35.65.90) |
| 17:26.13 | *** join/#openmoko Orias_Korva (~atilla@188.200.221.146) |
| 17:29.11 | PBeck | anybody owns a wikireader? |
| 17:47.16 | *** join/#openmoko jkyro (~jasu@dsl-hkibrasgw1-fe23f900-77.dhcp.inet.fi) |
| 17:51.17 | *** join/#openmoko Fish (~Fish@9fans.fr) |
| 17:51.35 | *** join/#openmoko ferluszt (~peter@p5DD28599.dip0.t-ipconnect.de) |
| 18:14.04 | Heinervdm | PBeck: have you asked in #openmoko-wikireader ? |
| 18:15.07 | PBeck | Heinervdm: oh i dont know about a channel for the wikireader, but - it's empty ;) |
| 18:15.59 | Heinervdm | PBeck: i'm having that channel from the topic :) |
| 18:16.55 | PBeck | Heinervdm: oh you are right :) |
| 18:23.46 | *** join/#openmoko Tupeco (tuomom@xob.kapsi.fi) |
| 18:24.15 | *** join/#openmoko radekp (~radek@63.120.broadband10.iol.cz) |
| 18:30.05 | *** join/#openmoko tjikkun (~tjikkun@amsn/developer/tjikkun) |
| 18:37.16 | *** join/#openmoko pa4wdh (~pa4wdh@lt30598-lnx.ipv6.pa4wdh.nl.eu.org) |
| 18:39.19 | *** join/#openmoko fsteinel (~fsteinel@fedora/fsteinel) |
| 18:43.34 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 18:44.32 | *** join/#openmoko TomaszD (~tom@Maemo/community/contributor/TomaszD) |
| 18:59.42 | *** join/#openmoko onen|openBmap (~quassel@vbo91-1-89-87-201-85.dsl.club-internet.fr) |
| 19:00.35 | *** join/#openmoko Kayin (mversteege@shell2.skyberate.net) |
| 19:10.06 | *** join/#openmoko LeRrA (~lerra@c-9b9872d5.029-136-73746f3.cust.bredbandsbolaget.se) |
| 19:19.25 | *** join/#openmoko kkb1101 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 19:31.24 | *** join/#openmoko naeg (~naeg@194.208.239.170) |
| 19:43.53 | *** join/#openmoko samgee (~samgee@fsf/member/samgee) |
| 19:46.14 | *** join/#openmoko geaaru (~geaaru@host216-168-dynamic.41-79-r.retail.telecomitalia.it) |
| 19:55.10 | *** join/#openmoko naught101 (~ned@c122-106-225-163.belrs3.nsw.optusnet.com.au) |
| 19:55.48 | samgee | I noticed that alarms don't wake up my freerunner in latest shr-u. Is this a known phenomenon and is there a workaround? |
| 20:05.28 | *** join/#openmoko TAsn (~tom@85-250-170-247.bb.netvision.net.il) |
| 20:07.29 | *** join/#openmoko Blu3 (~David@BlueLabs/Blu3) |
| 20:11.46 | *** join/#openmoko sfb_ (~sfb@88.130.187.0) |
| 20:20.26 | *** join/#openmoko dvermd (~david@ijo32-1-78-234-93-192.fbx.proxad.net) |
| 20:28.25 | *** join/#openmoko Gabrys (~Gabrys@89.229.55.160) |
| 20:43.56 | *** join/#openmoko Bane^ (bane@shelli.fi) |
| 20:53.40 | *** join/#openmoko geaaru (~geaaru@95.232.230.183) |
| 20:57.28 | *** join/#openmoko SpeedEvil (~user@tor/regular/SpeedEvil) |
| 21:04.00 | *** join/#openmoko tg (irc@tgbit.net) |
| 21:13.11 | *** join/#openmoko methril_work (~methril@201.35.65.90) |
| 21:16.15 | *** join/#openmoko playya_ (~playya@unaffiliated/playya) |
| 21:41.37 | *** join/#openmoko [Rui] (~Rui@a83-132-122-21.cpe.netcabo.pt) |
| 21:45.42 | *** join/#openmoko draioch (~draioch@93.107.25.95) |
| 21:55.18 | *** join/#openmoko Fox_Muldr (quakeman@frnk-4d01de5a.pool.mediaWays.net) |
| 21:59.25 | *** join/#openmoko SpeedEvil (1000@tor/regular/SpeedEvil) |
| 22:04.42 | *** join/#openmoko sicu (~sicu@ti0090a380-dhcp0506.bb.online.no) |
| 22:10.52 | *** join/#openmoko rabc (~draioch@93.107.25.95) |
| 22:12.09 | *** join/#openmoko cz_jc (~jc@88.146.126.102) |
| 22:13.43 | *** join/#openmoko eolson (~eolson@maze.mcs.anl.gov) |
| 22:17.12 | *** join/#openmoko Any_Key (~Any_Key@bzq-218-17-110.cablep.bezeqint.net) |
| 22:18.16 | *** join/#openmoko abram (~abram@78-153-84-122.soco-dsl.de) |
| 22:28.01 | *** join/#openmoko tg (irc@tgbit.net) |
| 22:50.49 | *** join/#openmoko GeneralError (~tuna@unaffiliated/t00na) |
| 23:16.07 | *** join/#openmoko draioch (~draioch@93.107.25.95) |
| 23:16.14 | *** join/#openmoko nslu2-log (~nslu2-log@limax.nslu2-linux.org) |