**** BEGIN LOGGING AT Wed Sep 15 02:59:57 2010
Sep 15 03:20:43 <brian> su
Sep 15 03:23:04 <brian> br549er
Sep 15 03:23:09 <brian> haha
Sep 15 03:23:45 <brian> "Doc"  any good hardware news?
Sep 15 05:27:51 <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.
Sep 15 05:28:03 <SparFux> And the manual is crap, I have to say.
Sep 15 09:27:04 <cosmos1> hello
Sep 15 09:27:29 <cosmos1> how to fix opengl glx on qtmokoV26?
Sep 15 09:27:59 <cosmos1> ...trying to run Gem on neoFR...
Sep 15 10:03:54 <gena2x> cosmos1: hi
Sep 15 10:04:07 <gena2x> cosmos1: i saw your message at #qtmoko
Sep 15 10:04:38 <gena2x> cosmos1: qtmoko has a bit special xserver (XGlamo)
Sep 15 10:05:34 <gena2x> cosmos1: anyway, no driver supporing glx (in hardware) exist at this moment
Sep 15 10:06:12 <gena2x> cosmos1: software rendering speed will be... below any usability.
Sep 15 10:06:17 <gena2x> cosmos1: why do you need it?
Sep 15 10:07:54 <gena2x> cosmos1: what is Gem?
Sep 15 11:17:48 <cosmos1> gena2x: Gem is a puredata extension for rendering and processing images, 3D objects and video.
Sep 15 11:19:03 <cosmos1> gena2x: and for pure data, see:
Sep 15 11:19:04 <cosmos1> http://puredata.info/
Sep 15 11:20:27 <cosmos1> gena2x: actually you can run puredata on qtmoko via qx (apt-get install puredata).
Sep 15 11:23:19 <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.
Sep 15 11:23:27 <gena2x> cosmos1: unfortunately, current Xglamo missing some important extensions and stock Xserver has vt switching bug.
Sep 15 11:24:16 <gena2x> cosmos1: may be it is possible to fix this problem by recompilation of Xglamo
Sep 15 11:24:35 <gena2x> cosmos1: but this is sure not a priority at this moment
Sep 15 11:25:51 <gena2x> cosmos1: contact radek__ if you want sources to investigate this problem at your own
Sep 15 11:26:37 <cosmos1> gena2x: ok, it would be nice in the future to run puredata + gem (why not pd-exdended) and Processing on the FR
Sep 15 11:27:52 <radek__> cosmos1: there is a plan to replace Xglamo with full xserver with glamo driver, but cant tell when it will be done...
Sep 15 11:27:54 <cosmos1> gena2x: Processing:
Sep 15 11:27:55 <cosmos1> http://processing.org/
Sep 15 11:28:15 <radekp> gena2x: btw any news about the power bug? :)
Sep 15 11:28:54 <gena2x> radekp: sure.
Sep 15 11:29:04 <cosmos1> radekp: you mean the recamping bug?
Sep 15 11:29:17 <gena2x> cosmos1: no
Sep 15 11:29:26 <radekp> cosmos1: nono, the bug with hugh current in suspend
Sep 15 11:29:37 <gena2x> radekp: i have patch
Sep 15 11:29:39 <cosmos1> gena2x: you mean the black screen?
Sep 15 11:29:53 <radekp> gena2x: nice, still stesting it?
Sep 15 11:29:55 <gena2x> cosmos1: http://docs.openmoko.org/trac/ticket/2349#comment:13
Sep 15 11:30:12 <gena2x> radekp: it works well
Sep 15 11:30:27 <gena2x> radekp: but seem something else is broken
Sep 15 11:30:38 <gena2x> radekp: not by this patch
Sep 15 11:31:10 <radekp> gena2x: what does it mean "something else"?
Sep 15 11:31:29 <gena2x> radekp: want full details? :)
Sep 15 11:32:05 <gena2x> no, really i mean if it is interesting, i can describe
Sep 15 11:32:11 <radekp> gena2x: sure :)
Sep 15 11:32:45 <radekp> yes it's very interesting for me, i would like to start using 2.6.34 kernel
Sep 15 11:33:52 <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.
Sep 15 11:34:16 <gena2x> regulator in question is cpu core 1.3v (DOWN1)
Sep 15 11:34:31 <gena2x> cpu has special signal to turn it on/off
Sep 15 11:35:24 <gena2x> (PWREN). so power off automagically while suspend and on on resume.
Sep 15 11:36:16 <gena2x> so, ENA register should just set GPIO and nobody should touch it. u-boot does exactly this.
Sep 15 11:36:38 <gena2x> but kernel has definitions for each register
Sep 15 11:37:06 <gena2x> and kernel regulator infrastructure tries to manage it
Sep 15 11:37:20 <gena2x> so it turns this on manually on boot
Sep 15 11:37:27 <gena2x> but do not turn off in suspend
Sep 15 11:37:50 <radekp> hmm interesting...
Sep 15 11:38:00 <gena2x> it has special field in platform structure with special field to turn it off in suspend.
Sep 15 11:38:14 <gena2x> and this seem worked in .29
Sep 15 11:38:40 <gena2x> so, now kernel _should_ turn it on/off while suspend/resume.
Sep 15 11:38:53 <gena2x> as far as i understand
Sep 15 11:39:03 <gena2x> so, two problems here
Sep 15 11:39:20 <gena2x> 1. why in hell it touches it at all
Sep 15 11:40:39 <gena2x> 2. why if it ordered to turn it off while suspend to ram it is actually not doing this.
Sep 15 11:41:02 <gena2x> that's all in fact.
Sep 15 11:41:17 <gena2x> now i am trying to answer this question
Sep 15 11:45:14 <gena2x> so, as regulator infrastucture if for manual managing
Sep 15 11:45:44 <gena2x> (contolling only 1 bit) i think it should just be set to off.
Sep 15 11:46:04 <gena2x> i mean set to never turn on this bit
Sep 15 11:46:15 <gena2x> this will fix (1)
Sep 15 11:46:32 <gena2x> but would be good to understand what happened with (2)
Sep 15 11:46:36 <gena2x> radekp: ok?
Sep 15 11:48:33 <radekp> gena2x: you i i think i understand
Sep 15 11:48:41 <radekp> s/you/yup
Sep 15 11:49:11 <radekp> gena2x: but this is not related to #2349? or is it?
Sep 15 11:49:38 <gena2x> seem you didn't understood :)
Sep 15 11:50:05 <gena2x> setting manually this bit to 1, enables DOWN1 output
Sep 15 11:50:35 <gena2x> so it stay enabled while suspend independently of PWREN
Sep 15 11:50:55 <gena2x> and eats that additional milliwats
Sep 15 11:52:57 <gena2x> by 'manually' i mean contolling it not via GPIO but intead via automatic linux regulator infrastructure
Sep 15 11:53:37 <gena2x> being more simple, if you disable that bit and not let regulators touch it, you'll get your 5mA.
Sep 15 11:54:30 <gena2x> now relation is clear?
Sep 15 11:59:47 <cosmos1> radekp: do you think that is actually possible to install Processing on the GTA2?
Sep 15 12:00:43 <radekp> gena2x: ahh oki, i think it's clear
Sep 15 12:00:55 <radekp> cosmos1: no idea...
Sep 15 12:02:03 <radekp> gena2x: so you have working patch, but you want to explore it more...
Sep 15 12:02:33 <gena2x> my personal kernel suspend still suffers from other problems
Sep 15 12:02:50 <gena2x> i mean GPS and GSM power_on/power_off things
Sep 15 12:03:04 <gena2x> i still have to do this
Sep 15 12:03:19 <gena2x> but strange enought, not on first boot
Sep 15 12:03:38 <gena2x> but overall current is now ok
Sep 15 12:03:47 <gena2x> i'll publish patch now
Sep 15 12:05:27 <gena2x> ah, i forgot i added script to check suspend which does power_on/power_off automagically
Sep 15 12:05:59 <gena2x> ah, i also forgot that you had some patches to fix gps/gsm issue
Sep 15 12:06:25 <gena2x> but i also should not that after powering on/off i have no need to issue any commands to modem
Sep 15 12:06:33 <gena2x> s/not/add/
Sep 15 12:06:34 <apt> gena2x meant: but i also should add that after powering on/off i have no need to issue any commands to modem
Sep 15 12:06:36 <larsc> radekp: do you know who is supposed to set reg 0x1f? the bootloader or the kernel?
Sep 15 12:08:11 <radekp> larsc: no idea, ask gena2x :)
Sep 15 12:08:19 <larsc> ok
Sep 15 12:09:31 <gena2x> larsc: did you read my description?
Sep 15 12:09:41 <gena2x> above
Sep 15 12:10:29 <lindi-> these pcf registers are available over i2c?
Sep 15 12:10:46 <gena2x> yes
Sep 15 12:10:51 <larsc> gena2x: not yet. will do now
Sep 15 12:18:50 <larsc> gena2x: what is your proposed fix?
Sep 15 12:19:35 <gena2x> larsc: adding it now to bug report
Sep 15 12:19:41 <gena2x> moment
Sep 15 12:20:20 <larsc> ok
Sep 15 12:36:02 <gena2x> larsc: ok, checked qi code and patch is http://www.bsdmn.com/openmoko/pr2349donot_manage_down1.diff
Sep 15 12:36:53 <larsc> well, thats the easy way. but yes it works
Sep 15 12:37:27 <gena2x> this is not only easy way but also only one which is right imo
Sep 15 12:37:48 <gena2x> idea how to do it in better way?
Sep 15 12:38:13 <gena2x> general ideas accepted too
Sep 15 12:38:15 <gena2x> :)
Sep 15 12:39:17 <larsc> nothing thats not overly complicated
Sep 15 12:41:20 <gena2x> i thing kernel should not touch that regulator
Sep 15 12:41:47 <gena2x> because no reason exist to touch it
Sep 15 12:42:11 <gena2x> as it should be managed by PWREN
Sep 15 12:43:00 <gena2x> i see no even complicated way to do it better
Sep 15 12:44:47 <gena2x> but all this leaves question (2) - why .state_mem.enable=0 is not working
Sep 15 12:46:11 <larsc> .state_mem is complicated
Sep 15 12:46:55 <larsc> a regultor driver needs special callbacks like set_suspend_{state,voltage,etc.} to apply state_mem
Sep 15 12:47:42 <larsc> furthermore the machine code needs to call regulator_set_suspend, when it suspends
Sep 15 12:47:53 <larsc> we have neither
Sep 15 12:48:27 <gena2x> hm. DOWN1 is not alone with .state_mem.enabled==0
Sep 15 12:49:26 <gena2x> may be this is cause of my gsm/gps problems..
Sep 15 12:49:40 <gena2x> may be i'll try to solve (2) too, but later
Sep 15 12:49:40 <larsc> i think we should drop the whole state_mem fields cause they are not used and might confuse someone who reads the code
Sep 15 12:49:59 <gena2x> really not used?
Sep 15 12:50:02 <larsc> yes
Sep 15 12:50:11 <gena2x> but worked in .29?
Sep 15 12:50:18 <larsc> don't think so
Sep 15 12:50:44 <gena2x> but regulators (non-pcf code) has support for this
Sep 15 12:51:19 <larsc> yes. but the machine code needs to call regulator_set_suspend
Sep 15 12:51:35 <larsc> otherwise the core will never look at those fields
Sep 15 12:52:12 <larsc> and the regulator driver needs to implement the set_suspend_{enabled,disabled} callbacks
Sep 15 12:53:45 <larsc> s,regulator_set_suspend,regulator_suspend_prepare,
Sep 15 12:54:56 <gena2x> gena@work:~/prg/openmoko/kernel5/linux-2.6/drivers/regulator$ global -rx regulator_suspend_prepare
Sep 15 12:54:56 <gena2x> regulator_suspend_prepare  183 ../../include/linux/regulator/machine.h int regulator_suspend_prepare(suspend_state_t state);
Sep 15 12:55:11 <gena2x> ops
Sep 15 12:55:14 <gena2x> wrong paste
Sep 15 12:55:32 <gena2x> ignore please
Sep 15 12:58:24 <gena2x> interesting, may be we are missing more power because of this.
Sep 15 12:59:55 <radekp> i wonder how much the current should really be - if my measuring was ok then modem takes like 3mA in deep sleep
Sep 15 13:00:27 <gena2x> i have 5mA
Sep 15 13:00:35 <larsc> just found this patch http://www.mail-archive.com/openmoko-kernel@lists.openmoko.org/msg05811.html
Sep 15 13:00:37 <gena2x> without modem i hope
Sep 15 13:03:16 * radekp will measure it
Sep 15 13:03:22 <gena2x> nice comment -                       /* Wow, when we are going into suspend, after pcf50633
Sep 15 13:03:22 <gena2x> -                        * runs its suspend (which happens real early since it
Sep 15 13:03:22 <gena2x> -                        * is an i2c device) we are running out of the 22uF cap
Sep 15 13:03:22 <gena2x> -                        * on core_1v3 rail !!!!
Sep 15 13:03:22 <gena2x> -                        */
Sep 15 13:04:28 <larsc> reading the follow-up comments it seems the patch is wrong
Sep 15 13:06:23 <gena2x> hm.. pmu has standby...
Sep 15 13:06:54 <gena2x> i didn't focus my attention to this fact
Sep 15 13:08:03 <larsc> when the pmu is in standby the system is off
Sep 15 13:12:12 * gena2x finished reading
Sep 15 13:13:30 <gena2x> anyway to remove mem structs we should review regulators with .enabled==0
Sep 15 13:14:27 <gena2x> and that callbacks should not be complicated
Sep 15 13:14:51 <gena2x> (i have no scheme in my head now)
Sep 15 13:16:00 <gena2x> if something may be disabled on suspend, it should be disabled.
Sep 15 13:16:18 <larsc> well, we would have to tell the driver what pin to use as a indicator whether the system is in suspend
Sep 15 13:17:15 <gena2x> and if state_mem.enabled==0 is only (nonhack) way to implement this disabling, it should be implemented
Sep 15 13:17:18 <larsc> and then in the set_suspend_{enabled,disabled} callback set the bit for that gpio
Sep 15 13:17:44 <larsc> enabled == 0 alone does nothing you also need disabled = 1
Sep 15 13:18:39 <larsc> DocScrutinizer: do you have any idea how memldo is wired up? It's not clear to me from the schematics
Sep 15 13:18:45 <gena2x> stop, stop. i lost you. 
Sep 15 13:19:13 <DocScrutinizer51> sorry, afk
Sep 15 13:19:31 <DocScrutinizer51> what's your precise Q?
Sep 15 13:19:50 <gena2x> we are speaking about state_mem for all regultors now?
Sep 15 13:20:06 <gena2x> ah
Sep 15 13:20:11 <gena2x> i got your idea
Sep 15 13:20:25 <larsc> DocScrutinizer: is it connected to the same consumers than down2?
Sep 15 13:20:29 <gena2x> use gpio pin instead of state_mem mechanism?
Sep 15 13:21:04 <DocScrutinizer51> what is memldo? a signal name?
Sep 15 13:21:28 <DocScrutinizer51> or the regulator in pcd50633?
Sep 15 13:21:36 <larsc> DocScrutinizer: the later
Sep 15 13:21:42 <DocScrutinizer51> mompl
Sep 15 13:22:00 <larsc> gena2x: combine them both.
Sep 15 13:22:33 <larsc> gena2x: for .state_mem to work you need some kind of indicator for the regulator whether the system is in suspend or not
Sep 15 13:22:55 <gena2x> such 'indicator' is callback, yes?
Sep 15 13:23:17 <larsc> the indicator would be the gpio pin
Sep 15 13:24:22 <DocScrutinizer> larsc: there's no memldo
Sep 15 13:24:42 <larsc> yes there is
Sep 15 13:25:39 <larsc> but i think i now have understood how it works.
Sep 15 13:25:41 <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
Sep 15 13:26:45 <larsc> i guess we would be turing the regulator of to early if we'd disable it directly from the callback
Sep 15 13:27:12 <gena2x> but if we'll made it GPIO driven (GPIO1 of pcf is active then cpu is not in suspend), it will work automagically
Sep 15 13:27:30 <gena2x> but we'll have to enable GPIO bit install of unconditional on.
Sep 15 13:27:36 <gena2x> s/install/instead/
Sep 15 13:27:36 <apt> gena2x meant: but we'll have to enable GPIO bit instead of unconditional on.
Sep 15 13:28:04 <DocScrutinizer> larsc: there's auto, down1/2, HCLDO, LDO1..6
Sep 15 13:28:12 <DocScrutinizer> no memldo
Sep 15 13:28:19 <gena2x> so we'll have no need in callbacks at all
Sep 15 13:29:06 <DocScrutinizer> sdram is powered via SDRAM_1V8 derived from IO_1V8
Sep 15 13:30:49 <DocScrutinizer> IO_1V8 is from DOWN2
Sep 15 13:30:58 <gena2x> but i do not understand why conbine this two methods :)
Sep 15 13:32:54 <larsc> DocScrutinizer: well the pcf50633 certainly has a memldo. but i guess it is not used?
Sep 15 13:33:16 <larsc> gena2x: i think the best solution right now is to keep your approch
Sep 15 13:33:29 <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)
Sep 15 13:33:59 <gena2x> DocScrutinizer: yes
Sep 15 13:34:12 <gena2x> DocScrutinizer: it has MEMLDO -> max current 1mA
Sep 15 13:34:31 <DocScrutinizer> gena2x: so what? read pcf50633 datasheet?
Sep 15 13:34:39 <gena2x> now reading!
Sep 15 13:35:09 <DocScrutinizer> iirc there's memldo in parallel to down2(?) to supply mem with VDD when system in syspend
Sep 15 13:35:15 <DocScrutinizer> suspend*
Sep 15 13:36:01 <gena2x> 'The volatile memory is intended to be supplied by DOWN2 in Active state and by MEMLDO in non-active states'
Sep 15 13:36:15 <larsc> DocScrutinizer: yes. that was the question, whether it actually is
Sep 15 13:36:34 <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
Sep 15 13:36:37 <larsc> cause right now I think DOWN2 is always on
Sep 15 13:37:24 <DocScrutinizer> depends on your system's power requirements on that VDD rail, during suspend
Sep 15 13:37:45 <DocScrutinizer> if it's too high for memldo you need to keep on down2
Sep 15 13:38:51 <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
Sep 15 13:39:12 <larsc> guessing from the numbers in the schematics the freerunner seems to need at least 2ma from down2/memldo
Sep 15 13:39:24 <gena2x> larsc: memldo == DOWN2FB pin, connected to DOWN2
Sep 15 13:39:33 <DocScrutinizer> that's probably the reason for memldo not being used then
Sep 15 13:39:40 <gena2x> DocScrutinizer: not really.
Sep 15 13:39:50 <gena2x> DocScrutinizer: i mean 'last first' thing
Sep 15 13:40:15 <DocScrutinizer> gena2x: ??
Sep 15 13:40:35 <gena2x> DocScrutinizer: we can kindly ask pcf to bind it to GPIO1
Sep 15 13:40:43 <DocScrutinizer> there *might* be other ever higher prio things to do
Sep 15 13:41:04 <gena2x> DocScrutinizer: so it will be put up as soon as cpu core resumes
Sep 15 13:41:08 <gena2x> and automagically
Sep 15 13:41:17 <DocScrutinizer> sounds nice, yes
Sep 15 13:41:39 <gena2x> hm... why not try now? :)
Sep 15 13:45:28 <gena2x> yeah, we sure not using it, as even voltage not set :)
Sep 15 13:47:36 <gena2x> hm. can this two be enabled at once?
Sep 15 13:48:19 <gena2x> DocScrutinizer: ^?
Sep 15 13:48:43 <larsc> gena2x: memldo will be automatically off if down2 is on
Sep 15 13:48:51 <DocScrutinizer51> gena2x: don't get it wrong (polarity aka logic/inverted logic), when core goes down you DISable down2 and ENable memld
Sep 15 13:49:08 <gena2x> thanks. seems missed this.
Sep 15 13:49:17 <larsc> so memldo should be set to always on
Sep 15 13:49:29 <larsc> and down2 to on when gpio1 is high
Sep 15 13:49:50 <gena2x> ok. i'll test how this affect suspend current
Sep 15 13:49:56 <DocScrutinizer51> memldo is largely irrelevant
Sep 15 13:50:23 <DocScrutinizer51> always on or dowwn2^-1
Sep 15 13:51:01 <DocScrutinizer51> anyway GPIO must switch OFF down2
Sep 15 13:52:39 <DocScrutinizer51> if it's really down2 (not checked)
Sep 15 13:53:03 <gena2x> ok, all clear. setting proper values now.
Sep 15 13:59:47 <DocScrutinizer> so I can close document /home/jr/Documents/OpenMoko/GTA02/GTA02-MB-A7_50-71481-01.pdf  ? :-D
Sep 15 14:00:35 <gena2x> i have no questions atm, thanks
Sep 15 14:00:40 <DocScrutinizer> yw
Sep 15 14:12:47 <pabs3> any OpenMoko folks planning on coming to LCA? http://mobilefoss.jamespurser.com.au/Call_For_Papers
Sep 15 14:19:30 <jksa> hi guys - anyone know of a gsm 07.10 (mux) implementation that does version 4?
Sep 15 14:20:11 <lindi-> jksa: version 4?
Sep 15 14:20:35 <jksa> lindi-, there seems to be some kind of perhaps proprietary versioning scheme for mux'ers
Sep 15 14:20:50 <jksa> lindi-, I have an implementation of version 3, but my unit rejects it - asking for version 4
Sep 15 14:20:59 <lindi-> jksa: what unit?
Sep 15 14:21:25 <jksa> lindi-, Cinterion (Siemens) HC25 variant
Sep 15 14:21:41 <lindi-> jksa: ok
Sep 15 14:21:58 <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
Sep 15 14:25:05 <lindi-> jksa: so you are issuing +CMUX=<mode>[,<subset>[,                      <port_speed>[,<N1>[,<T1>                      [,<N2>[,<T2>[,<T3>     [,<k>]]]]]]]]          ?
Sep 15 14:25:25 <jksa> lindi-, yep
Sep 15 14:25:27 <lindi-> "Test command returns the supported modes and  parameters.  The  window  size parameter <k> is only applicable for mode 4."
Sep 15 14:25:34 <lindi-> so at least the standard knows about "mode 4"
Sep 15 14:25:46 <lindi-> jksa: what do you get with the test command?
Sep 15 14:26:55 <jksa> lindi-, I think you're mixing modes and versions together - it's not the same thing
Sep 15 14:27:06 <lindi-> jksa: ok
Sep 15 14:28:05 <jksa> lindi-, I can initiate gsm 07.10 with the at+cmux command just fine
Sep 15 14:28:12 <jksa> lindi-, the unit only supports mode 0
Sep 15 14:28:24 <jksa> (which is also what the test command returns)
Sep 15 14:28:38 <lindi-> jksa: how does it ask for version 4?
Sep 15 14:29:21 <jksa> lindi-, basically it will return this text in the multiplexed channel:
Sep 15 14:29:24 <jksa> "DO NOT USE MUX PROTOCOL <V4 IN THIS PRODUCT"
Sep 15 14:29:28 <lindi-> ok
Sep 15 14:29:41 <jksa> the manual also states that version 4 is required
Sep 15 14:29:54 <lindi-> ok, I don't think I have much intel on that sorry :(
Sep 15 14:30:00 <jksa> okay :-(
Sep 15 14:30:10 <jksa> I'm afraid I have to implement it myself... a lot of work :-|
Sep 15 14:30:18 <lindi-> jksa: have you found specs?
Sep 15 14:30:50 <jksa> lindi-, yep
Sep 15 14:31:03 <larsc> d~.
Sep 15 14:31:10 <gena2x> larsc: just works, but no diff in consumption even seem ~+1mA.
Sep 15 14:31:25 <lindi-> jksa: got some googleable search term? ;)
Sep 15 14:31:47 <jksa> lindi-, sorry, I haven't been able to find specs on google
Sep 15 14:31:48 <larsc> gena2x: ok
Sep 15 14:33:43 <lindi-> jksa: just give me one unique sentence so that if I find the specs through some other means I can recogonize them :)
Sep 15 14:34:07 <jksa> lindi-, the document ID is: HC2x_Mux_Guide_v02n
Sep 15 14:35:05 <lindi-> sounds vendor specific :)
Sep 15 14:35:31 <jksa> lindi-, I bet it is
Sep 15 14:38:13 <lindi-> jksa: are you planning to contribute your code to linux, gsm0710muxd, ophono or ogsmd? ;)
Sep 15 14:38:41 <jksa> lindi-, well, if I actually do implement it - yes
Sep 15 14:38:58 <jksa> lindi-, however I'm not interesting in implementing the full thing from scratch... I rather want to build on something existing
Sep 15 14:39:17 <jksa> lindi-, the only thing I could get to build was a program called gsmmux in alpha release 3 from 2009... :-(
Sep 15 14:39:44 <jksa> I've downloaded cornucopia too, but I cannot get it to build on my platform
Sep 15 14:40:20 <gena2x> not bad, according to logs resume time is 1.5 sec, suspend .3 sec
Sep 15 14:40:44 <lindi-> gena2x: now make it possible to resume via touchscreen and we can suspend instead of blanking :)
Sep 15 14:41:03 <gena2x> noooooo
Sep 15 14:41:19 <lindi-> jksa: ah cornucopia too. we have 5 implementations of 07.10
Sep 15 14:41:36 <lindi-> gena2x: why not?
Sep 15 14:41:46 <gena2x> sound, wifi, ssh
Sep 15 14:41:57 <jksa> lindi-, yeah, it's a jungle... how do I know which one is most current and maintained?
Sep 15 14:42:02 <lindi-> gena2x: sure but it would be a great option
Sep 15 14:42:14 <lindi-> jksa: linux is quite maintained :)
Sep 15 14:42:17 <jksa> lindi-, if they're all maintained... which one has the least amount of dependencies on "weird stuff"?
Sep 15 14:42:38 <jksa> lindi-, well, the mux implementation in linux is only available in 2.6.34 right?
Sep 15 14:42:39 <gena2x> lindi-: may be we can just reduce IDLE power consumption somehow?
Sep 15 14:42:47 <lindi-> jksa: i'm personally using gsm0710muxd since i was afraid of all the vala stuff in cornucopia
Sep 15 14:42:57 <lindi-> gena2x: yeah that'd be cpufreq
Sep 15 14:43:03 <jksa> lindi-, exactly - vala turned me off too
Sep 15 14:43:16 <lindi-> jksa: something like 2.6.34 I think yes
Sep 15 14:43:25 <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
Sep 15 14:43:39 <lindi-> jksa: ok
Sep 15 14:43:43 <gena2x> lindi-: no, we what about pushing memory to self-refresh while idle?
Sep 15 14:43:55 <lindi-> jksa: I also do not have any experience on in-kernel muxers so I don't know if I can recommend them yet
Sep 15 14:44:26 <jksa> lindi-, to me it sounds weird to have them in-kernel... they belong in user space ;-)
Sep 15 14:44:29 <lindi-> gena2x: no idea, try if you know how
Sep 15 14:44:53 <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
Sep 15 14:45:07 <lindi-> jksa: what sort of debian style things?
Sep 15 14:45:41 <jksa> lindi-, well, for me it couldn't build because it couldn't find glib 2.x (which is installed) - due to missing pkgconfig
Sep 15 14:45:53 <jksa> or rather... missing pkgconfig configuration (or data files or whatever)
Sep 15 14:45:59 <lindi-> jksa: ah
Sep 15 14:46:21 <lindi-> jksa: have you checked if pyneo is still maintaining it?
Sep 15 14:47:03 <jksa> not as such?
Sep 15 14:47:23 <jksa> I've downloaded a seperate fork by some Neil guy.. let me check
Sep 15 14:47:46 <jksa> I've checked the Pyneo web site earlier - but I left it shortly after it insulted me because of my choice of browser ;-)
Sep 15 14:48:59 <jksa> lindi-, Neil Brown... there it was :-)
Sep 15 14:49:20 <jksa> lindi-, http://neil.brown.name/git?p=gsm0710muxd;a=tree
Sep 15 14:51:23 <gena2x> lindi-: our cpu has not only NORMAL IDLE and SUSPEND modes
Sep 15 14:51:40 <gena2x> lindi-: it has also SLOW, STOP and Deep-STOp
Sep 15 14:51:52 <lindi-> gena2x: does glamo work in those?
Sep 15 14:52:27 <gena2x> lindi-: yes i think
Sep 15 14:52:37 <gena2x> ah
Sep 15 14:52:43 <gena2x> interesting
Sep 15 14:52:54 <gena2x> need to think
Sep 15 14:53:05 <gena2x> but why not
Sep 15 14:54:20 <gena2x> i think glamo can 'work' in suspend too. why not?
Sep 15 14:54:39 <lindi-> I don't know, I just recall reading about 100 MHz being minimum because of glamo
Sep 15 14:54:48 <lindi-> it was in the cpufreq discussion iirc
Sep 15 14:55:07 <gena2x> glamo need working memory bus?
Sep 15 14:56:10 <lindi-> I haven't signed the glamo NDA sorry :)
Sep 15 14:56:26 <gena2x> lindi-: np
Sep 15 14:56:29 <gena2x> :)
Sep 15 14:56:36 <Gabrys> lindi-: if you haven't you can actualy disclose stuff :-)
Sep 15 14:59:31 <pabs3> glamo works in suspend?
Sep 15 15:00:53 <gena2x> pabs3: this were question
Sep 15 15:01:18 <gena2x> pabs3: is this possible
Sep 15 15:01:29 <pabs3> oh, sorry
Sep 15 15:01:47 <gena2x> and if it can, it can also work in STOP mode
Sep 15 15:02:12 <gena2x> hm... should be not really hard to check...
Sep 15 15:15:26 <PBeck> hi
Sep 15 16:12:08 <PBeck> i searching for developer information for the wikireader
Sep 15 16:12:28 <PBeck> is there no wiki or more then the wikireader info page?
Sep 15 16:14:53 <SpeedEvil> DocScrutinizer is the droid you are looking for.
Sep 15 17:33:22 <PBeck> anybody owns a wikireader?
Sep 15 18:18:16 <Heinervdm> PBeck: have you asked in #openmoko-wikireader ?
Sep 15 18:19:18 <PBeck> Heinervdm: oh i dont know about a channel for the wikireader, but - it's empty ;)
Sep 15 18:20:11 <Heinervdm> PBeck: i'm having that channel from the topic :)
Sep 15 18:21:07 <PBeck> Heinervdm: oh you are right :)
Sep 15 20:00:00 <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?
**** BEGIN LOGGING AT Wed Sep 15 23:16:14 2010
**** ENDING LOGGING AT Thu Sep 16 02:59:57 2010