**** BEGIN LOGGING AT Mon Dec 09 02:59:58 2013 Dec 09 08:52:09 jake42: that's nasty Dec 09 09:05:12 btw if anyone want to try QtMoko with 2.6.39 kernel, i can upload it - it's still a bit experimental, but should work quite well Dec 09 09:13:55 DocScrutinizer05: just on first boot and only if there are texts left on the sim Dec 09 09:14:13 shouldn't be to hard to fix Dec 09 09:22:10 radekp: re kernel, could you maybe /join #maemo-ssu and ping freemangordon? Dec 09 09:22:28 ^^^ also @ other kernel devels Dec 09 09:23:28 guys over there working on 3.12 kernel for OMAP3/GTA04/N900/Neo900 Dec 09 09:24:18 DocScrutinizer05: hi, ahh oki, sure i can try Dec 09 09:24:50 DocScrutinizer05: do they have any progress on GTA04/Neo900 kernel? Dec 09 09:25:02 thanks a lot, the lazy lad didn't join here but asked me if "we" will get help from openmoko community Dec 09 09:25:30 well, I think freemangordon made 3.12 boot and "work" on N900 Dec 09 09:25:40 == OMAP3430 Dec 09 09:25:57 nice Dec 09 09:26:00 basically it's all just glorified beagleboards ;-) Dec 09 09:27:09 iirc there been many problems with DT, and some issues with clock dividers for e.g. camera interface, prolly related Dec 09 09:29:02 i wonder i can help at all with kernel :) Dec 09 09:29:06 seems recently there also been issues with I2C Dec 09 09:29:40 anyways i have joined the channel and added it to my list, but busy now at work for any longer discussion Dec 09 09:30:07 np, just say "hi freemangordon, old sucker! :-)" Dec 09 09:30:10 ;-P Dec 09 09:30:23 he's busy too aiui Dec 09 09:30:27 right now Dec 09 10:15:47 PaulFertser: hi, i maybe found something interesting regarging power in suspend on gta02 Dec 09 10:16:25 PaulFertser: while i was trying to find which modules are needed for 2.6.39 i stepped on combination which has very low power in suspend Dec 09 10:16:32 PaulFertser: http://paste.debian.net/69937/ Dec 09 10:16:57 PaulFertser: with this one i get 6 or 7mA in suspend Dec 09 10:17:12 radekp: do you mean with some other combination you get more? :) Dec 09 10:17:13 radekp: hi Dec 09 10:17:19 PaulFertser: it used to be always ~12mA Dec 09 10:17:46 radekp: but do you know which module causes extra drain? Dec 09 10:18:04 PaulFertser: this one is using 12mA http://paste.debian.net/69939/ Dec 09 10:18:18 PaulFertser: it could be the lis302dl maybe Dec 09 10:18:28 PaulFertser: i can try uncomment and measure.. Dec 09 10:19:00 radekp: yes, lis302dl might Dec 09 10:19:07 it will take a few minutes... Dec 09 10:21:12 lis302 needs proper setup Dec 09 10:22:01 after all it's supposed to be able to wake CPU by assering IRQ line when internal trigger engine decided there's an event that should do Dec 09 10:22:37 that's the whole point of this smart accelerometer Dec 09 10:23:25 of course when lis302 stays busy and maybe even asserts IRQ line and CPU simply ignorest that, then there's something pretty fishy Dec 09 10:23:46 I don't use gmeters, can't use gps, don't have even edge connectivity, can't ramp up the earpiece volume high enough to hear the other side when I'm underground, have to use "links2 -g" as a browser, gtk-based stopwatch is slow and unusable etc etc. But I'm running Emacs, FSO and Xmonad, damn it. Dec 09 10:25:30 ooh btw. do NOT use the brainfscked upstream lis302 driver, it's made for joysticks only and knows shit about proper setup of IRQ Dec 09 10:26:15 I knew you'd say that :) Dec 09 10:27:05 PaulFertser: yup with lis302dl i get 13mA Dec 09 10:27:37 PaulFertser: need to repeat a few times, but i it's very likely that lis302dl is the ugly one Dec 09 10:27:37 prolly lis302 is in 400Hz mode, the only mode the mailine lis302 driver knows about Dec 09 10:29:06 it sets up the lis302 to spam the cpu with new data all the time, at a rate of 400 or 100 Hz Dec 09 10:29:37 which is pretty much NOT what we usually want to use Dec 09 10:29:56 all disclaimer: last time I checked Dec 09 10:31:55 PaulFertser: again 13mA Dec 09 10:31:59 what will we do? Dec 09 10:32:12 get a proper lis302 kernel driver Dec 09 10:32:14 radekp: deprecate gmeters and not load the module? Dec 09 10:32:20 What use of them anyway? Dec 09 10:32:43 i am using accels for QtMaze game and for rotating in browser and media player Dec 09 10:33:16 too bad Dec 09 10:33:22 :/ Dec 09 10:33:53 i could live without them, but it's kinda regression Dec 09 10:34:06 you at least should make sure the device node is closed on suspend, and the driver will stop the lis302 from spamming data then Dec 09 10:34:09 I guess lis302 driver might be missing the suspend routine, you can cross-check against the openmoko driver. Dec 09 10:34:43 hmm i am quite sure that the device nodes are closed Dec 09 10:34:47 when suspended Dec 09 10:35:12 yeah, but probably that stupid driver doesn't stop lis302 400Hz mode even then Dec 09 10:35:26 Right Dec 09 10:35:51 Too bad smart openmoko devs never pushed their driver upstream, if they did, lis302 wouldn't be accepted. Dec 09 10:35:52 it's about the most idiotic driver I ever seen Dec 09 10:36:45 maybe we can backport it from older openmoko kernel? Dec 09 10:37:03 It's likely to be an easy task, yes. Dec 09 10:39:03 on the other hand - 6mA in suspend rocks - 200hours in standby - show me other phone that can do it... Dec 09 10:39:11 i think i even saw 5mA Dec 09 10:40:14 radekp: how do you measure? reading current_now right after resume? Dec 09 10:40:25 jake42: no using charge_now Dec 09 10:40:47 makes sense Dec 09 10:41:26 2.6.39 kernel has it so it started finally working in qtmoko Dec 09 12:31:49 So sad that nobody have found this back in 2009. Bad hardware, bad hardware... Dec 09 12:36:41 true, sad thing Dec 09 12:37:12 but maybe another try: with neo900 Dec 09 12:37:31 s/but /but there/ Dec 09 12:37:33 jake42 meant: but theremaybe another try: with neo900 Dec 09 12:37:52 radekp_: what started working in qtmoko? Dec 09 12:38:40 fling: charge_now from battery driver, i guess Dec 09 12:41:35 oh! Dec 09 13:17:58 HUH? Dec 09 13:20:36 N900 does 200h standby, even without suspend Dec 09 13:24:15 I want the same for neo900! Dec 09 13:25:23 then you need to use the same OS Dec 09 13:25:37 with same optimized kernel Dec 09 13:26:10 or hope for other OS finally get their stuff sorted Dec 09 13:27:23 incl blacklisting all crappy apps that do busy wairs or way too frequent refresh or even polling Dec 09 13:27:31 waits* Dec 09 13:28:31 of course all app nuking doesn't help when already the kernel comes with crappy drivers, like the lis302 as of above Dec 09 13:32:26 alas for mainline kernel drivers it's still lke "it compiles, it obeys coding style guidelines, it works - it's in" - while often nobody cares about power management at all Dec 09 13:34:10 and when later on somebody else rewrites trhe driver completely since already the API is not appropriate to allow power-aware operation of the subsystem, then there's zero chance to replace the crappy mainline driver with a better one Dec 09 13:34:53 again, see lis302 Dec 09 13:38:49 the mainline driver honestly is meant for joysticks. Thus nobody even thought about power management since a joystick either is in use or the whole thing is unplugged or not used and off at least. And while it's in use you want a constant stream of input data for most accurate and real-time'ish operation Dec 09 13:40:11 while in a platform like FTA02 or N900 you want to keep the whole thing idle until you rotated the orientation of device at least 50° Dec 09 13:40:16 for example Dec 09 13:40:26 GTA02 even Dec 09 13:41:45 hmmm hmmmmm Dec 09 13:43:07 now when your SoC supports this and your LIS302 supports this (via very nifty IRQ trigger engine consisting of filters and thresholds and even a detector for double-clicks) but your mainline kernel driver has NFC even on API level about all that awesomeness in your hardware Dec 09 13:43:14 what you gonna do? Dec 09 13:43:22 cry! Dec 09 13:43:48 no, use your own non-mainline driver Dec 09 13:44:01 good :D Dec 09 13:45:59 btw probably pretty much the identical situation can be found for capacitive touchscreen drivers which you can use to unlock the device by doubleclick Dec 09 13:47:17 I mean the chip cna detect doubleclick, but I could figure how mainline driver ignores that and thus your standard debian get woken up on every touchscreen event even when touchscreen is locked, since the CPU needs to detect doubleclicks Dec 09 13:48:41 the chip manufs and EE provide all it needs to build awesome software on a decent platform, but the kernel devels often fail to make proper use of that Dec 09 13:49:53 that's the difference to other OS like android or windows, which do whatever it needs to make the system *work* - and only then they worry about policies in sw development and project management Dec 09 13:54:12 ~botsnack Dec 09 13:54:40 *sigh* Dec 09 14:26:48 hmm i wonder what i am missing now that wifi interface is missing on 2.6.39 Dec 09 14:27:13 i have ar6000 module - i thought that that's enough... Dec 09 14:29:31 wifi works for me with ar6000 Dec 09 14:29:59 is it shown in rfkill? Dec 09 14:31:23 ahh let me try Dec 09 14:39:22 JaMa: cool that's it, thanks a lot **** ENDING LOGGING AT Tue Dec 10 02:59:58 2013