**** BEGIN LOGGING AT Wed Nov 03 02:59:57 2010
Nov 03 05:04:31 <TAsn> mrmoku, is NOTE: Tasks Summary: Attempted 8998 tasks of which 220 didn't need to be rerun and 0 failed.
Nov 03 05:04:31 <TAsn> make: *** [image] Error 1
Nov 03 05:04:31 <TAsn> "
Nov 03 05:04:37 <TAsn> a good thing or a bad thing?
Nov 03 06:12:05 <vanous> PaulFertser: good morning
Nov 03 06:12:31 <vanous> i have noted some of your comments about gsm instability
Nov 03 06:13:21 <vanous> well, last weeks shr-u still played some gsm issues on me, basically lost gsm after some time 
Nov 03 06:14:06 <vanous> can i be of any help with placing test calls and collecting logs?
Nov 03 06:14:12 <vanous> please let me know
Nov 03 06:54:40 <PaulFertser> vanous: morning
Nov 03 06:54:55 <PaulFertser> vanous: i'm afraid, no.
Nov 03 06:55:35 <PaulFertser> vanous: the problem is that basically some gsm commands sometimes fail (especially during suspend/resume) and after that fsogsmd closes the modem and it stays so until i notice and restart it. 
Nov 03 06:55:56 <PaulFertser> I also usually need to restart fsousaged if it's stuck in SUSPENDING or RESUMING state.
Nov 03 06:56:01 <PaulFertser> mickeyl: ^^^
Nov 03 07:00:42 <vanous> i see
Nov 03 07:53:47 <mrmoku> TAsn: hmm... rootfs.log?
Nov 03 09:07:18 <mrmoku> TAsn: 09:17 < khem> 06:12:30> mrmoku: armv6j should work well with gcc 4.5 and eglibc yes I dont know of any issues 
Nov 03 09:07:29 <mrmoku> see :P
Nov 03 11:41:47 <JaMa> [Rui]: I know that raster is busy.. that's why I'm trying to revert it here first to be sure it's after this patch
Nov 03 11:42:25 <[Rui]> JaMa: ok
Nov 03 11:42:26 <JaMa> [Rui]: and maybe in the end we're maybe just missing ELM_LIST_COMPRESS somewhere
Nov 03 13:32:05 <JaMa> playya_: ping
Nov 03 13:32:13 <playya_> pong
Nov 03 13:33:33 <JaMa> noticed that you have efl R/W for vala bindings
Nov 03 13:33:39 <JaMa> http://www.mail-archive.com/shr-devel@lists.shr-project.org/msg03049.html
Nov 03 13:33:59 <playya_> yes
Nov 03 13:34:04 <JaMa> if you have patch for elm_toolbar_scrollable_set api change, please notify lukasz :)
Nov 03 13:34:29 <playya_> just build efl to fix "everythingt"
Nov 03 13:34:36 <playya_> OK
Nov 03 13:34:55 <JaMa> ?
Nov 03 13:35:35 <playya_> i start working on it now
Nov 03 13:36:05 <JaMa> ok :) I didn't understand what you mean by "just build efl to fix "everythingt"" :)
Nov 03 13:36:18 <JaMa> as there wasn't any new commit in BINDINGS/vala :)
Nov 03 13:38:44 <playya_> yes
Nov 03 13:39:14 <playya_> i had to build EFL because it did not install it on this PC
Nov 03 13:40:21 <daniele_athome> greetings
Nov 03 13:40:33 <JaMa> jo
Nov 03 13:40:34 <daniele_athome> is it just me or usb connection with FR is not working anymore?
Nov 03 13:40:48 <JaMa> here it does
Nov 03 13:40:54 <daniele_athome> JaMa, latest shr-u kernel
Nov 03 13:42:48 <playya_> i start to update the bindings for eina and then go up to elementary etc.
Nov 03 13:42:53 <playya_> daniele_athome, hi
Nov 03 13:43:08 <daniele_athome> hi playya_ 
Nov 03 13:43:19 <playya_> do you know bamf for application/window identification?
Nov 03 13:43:41 <playya_> https://launchpad.net/bamf
Nov 03 13:44:17 <daniele_athome> playya_, heard of it but never tried
Nov 03 13:44:24 <playya_> ok
Nov 03 13:44:54 <playya_> i thought it might be useful for and only want to tell you that it exists
Nov 03 13:45:11 <daniele_athome> sure, for the application lifecycle things ;)
Nov 03 13:45:17 <daniele_athome> s/things/stuff/
Nov 03 13:45:18 <apt> daniele_athome meant: sure, for the application lifecycle stuff ;)
Nov 03 13:47:41 <daniele_athome> JaMa, the strange thing is that it doesn't even show on lsusb on the host
Nov 03 13:47:49 <daniele_athome> and no messages in dmesg
Nov 03 13:47:52 <daniele_athome> nothing :(
Nov 03 14:00:58 <daniele_athome> noooo
Nov 03 14:01:00 <daniele_athome> i don't believe it
Nov 03 14:01:01 <daniele_athome> [ 1501.329642] mmcblk0: error -110 transferring data, sector 1997984, nr 104, card status 0x80900
Nov 03 14:01:03 <daniele_athome> :S :S :S
Nov 03 14:12:54 <JaMa> daniele_athome: usb0 also doesn't work ok, when fsodeviced doesn't work
Nov 03 14:13:28 <JaMa> daniele_athome: and yes I usually have latest shr-u kernel (or newer :))
Nov 03 14:13:39 <JaMa> daniele_athome: last change was only better ts patch
Nov 03 14:15:00 <daniele_athome> i see :(
Nov 03 14:16:03 <daniele_athome> JaMa, damage in usd is only in second (data) partition
Nov 03 14:16:09 <daniele_athome> system partition is ok
Nov 03 14:29:02 <gena2x> Hi. Anyone can help me with serials? I am out of ideas. Trying to find out what is problem with GPS serial after resume. s3c setup seem fine - baud rate, clock source, port setup - all same to state before suspend. power is ok. but controller getting nothing in FIFO.
Nov 03 14:30:22 <gena2x> any ideas welcome!
Nov 03 14:43:24 <gena2x> serial port itself working well in loopback mode
Nov 03 14:43:53 <gena2x> so probably problem is in gps chip
Nov 03 14:49:23 <lindi-> gena2x: hmm
Nov 03 14:49:35 <lindi-> gena2x: when did this start to happen?
Nov 03 14:50:21 <gena2x> lindi-: it's know issue if u-boot ised as bootloader. now i am trying to understand why it is not working
Nov 03 14:50:31 <gena2x> s/ised/used/
Nov 03 14:50:32 <apt> gena2x meant: lindi-: it's know issue if u-boot used as bootloader. now i am trying to understand why it is not working
Nov 03 14:50:46 <lindi-> gena2x: gps works here with u-boot
Nov 03 14:50:53 <lindi-> gena2x: what's the bug report number?
Nov 03 14:50:58 <JaMa> iirc first reports of this behavior were after switching to 2.6.32..
Nov 03 14:52:00 <gena2x> lindi-: no bug report atm, sorry. only some description in maillists.
Nov 03 14:52:27 <lindi-> start by filing one :)
Nov 03 14:52:44 <lindi-> I think I'm going to look at my alsa setup soon so that I can seriously test 2.6.34
Nov 03 14:54:37 <gena2x> lindi-: good idea. here, in qtmoko it works really good. really, for the first time it's pleasure to use qtmoko as a phone.
Nov 03 14:55:01 <lindi-> gena2x: I think I need to hunt the ts jitter patches and try those
Nov 03 14:55:17 <lindi-> and maybe push my branch to github/gitorius
Nov 03 14:55:31 <lindi-> previously I just sent a link to radekp
Nov 03 14:55:43 <gena2x> lindi-: radek's branch working well.
Nov 03 14:56:12 <lindi-> gena2x: qtmoko29 or something? I think I branched from qtmoko27
Nov 03 14:58:21 <DocScrutinizer> gena2x: maybe GPS tty FIFO locks up when GPS tries to send data while system is suspended
Nov 03 14:58:52 <lindi-> should be easy to test by disabling gps output
Nov 03 14:59:13 <gena2x> lindi-: yes, this one: https://github.com/radekp/linux-2.6/commits/qtmoko-v29, i only added my latest ts patch
Nov 03 15:01:09 <DocScrutinizer> lindi-: radekp: ever tried to trigger the ts AD in sync with VSYNC. It's probably not necessary to mess around with pixelclock. The whole jitter is a mere aliasing between td AD and the LCD refresh. What I mean to say is: do AD always same point in time relative to LCD refresh, to get jitter free results
Nov 03 15:01:37 <gena2x> DocScrutinizer: hm. should be easy to check... 
Nov 03 15:01:47 <gena2x> DocScrutinizer: i mean about FIFO lockup
Nov 03 15:02:53 <gena2x> DocScrutinizer: nice idea, only need to wait for VSYNC and ensure that adc will last only while VSYNC is active.
Nov 03 15:02:56 <DocScrutinizer> I.E do ts AD conversion during VSYNC blackburst, when there's no refresh happening on LCD
Nov 03 15:03:09 <DocScrutinizer> exactly
Nov 03 15:03:21 <gena2x> but in general, my ts patch implements something very similar
Nov 03 15:03:21 <DocScrutinizer> AD is fast, should be no problem
Nov 03 15:04:04 <DocScrutinizer> aiui you patch implements a temporary stopclock for pixelclock
Nov 03 15:04:23 <gena2x> and also, i am not really sure about this theory (that with fast pixclock in VSYNC data will be ok)
Nov 03 15:04:40 <DocScrutinizer> which is both nasty and prone to induce side effects
Nov 03 15:04:44 <gena2x> this theory need checking
Nov 03 15:05:18 <gena2x> my ts patch is just about changing divider, so it should not really intoduce anything terrible
Nov 03 15:05:25 <daniele_athome> JaMa, i want to permanently store logs
Nov 03 15:05:33 <daniele_athome> is it enough to comment out volatile row in fstab?
Nov 03 15:06:12 <DocScrutinizer> gena2x: the ts controller has PLLs to sync to the signal from SoC video out
Nov 03 15:06:27 <DocScrutinizer> aiui
Nov 03 15:06:57 <daniele_athome> no...
Nov 03 15:07:18 <gena2x> DocScrutinizer: yes, it has possibility to 'delay' measurement
Nov 03 15:07:59 <JaMa> daniele_athome: nope see /etc/init.d/populate-volatile.sh
Nov 03 15:08:00 <gena2x> unsure about what is clock source... but delay is possible
Nov 03 15:08:11 <daniele_athome> JaMa, just read ;)
Nov 03 15:08:14 <daniele_athome> commented out mount too
Nov 03 15:09:17 <gena2x> you right, probably jitterless ts may be done better, but way works really well too.
Nov 03 15:09:28 <gena2x> s/way/this way/
Nov 03 15:09:29 <apt> gena2x meant: you right, probably jitterless ts may be done better, but this way works really well too.
Nov 03 15:10:15 <gena2x> and other way need more research. really unsure that while vsync data will be correct.
Nov 03 15:10:23 <DocScrutinizer> gena2x: probably, nah likely, the ADs have a S/H stage so it's mostly irrelevant how long actual AD conversion takes. Just he exact point to sample and hold the input value to the local buffer capacitor is interesting
Nov 03 15:11:50 <DocScrutinizer> meh
Nov 03 15:11:56 <gena2x> hm... i didn't know such internals
Nov 03 15:11:57 <lindi-> gena2x: btw, you hacked on u-boot. how would you feel about having u-boot start watchdog early on resume?
Nov 03 15:11:59 <DocScrutinizer> I'm just suggesting
Nov 03 15:12:52 <DocScrutinizer> lindi-: umpf, why?
Nov 03 15:13:44 <lindi-> DocScrutinizer: due to hang http://docs.openmoko.org/trac/ticket//2309
Nov 03 15:15:04 <daniele_athome> JaMa: http://pastebin.com/fe5s0sWZ
Nov 03 15:15:13 <daniele_athome> notice the error on usb_mode 
Nov 03 15:16:26 <gena2x> DocScrutinizer: the form of jitters really makes me very unsure that measuring in VSYNC will be clean. jitters has spiked - slower pixclock, less spikes, but also it has 'background buzz'. this need really much more time to understand what is real source of jitter. why y jitter is more than x for example? and etc.
Nov 03 15:17:10 <JaMa> daniele_athome: modprobe ohci_hcd ?
Nov 03 15:17:21 <JaMa> daniele_athome: or what do you have in lsmod?
Nov 03 15:17:23 <daniele_athome> JaMa, but why now
Nov 03 15:17:38 <JaMa> daniele_athome: maybe missing depmod call?
Nov 03 15:17:54 <JaMa> daniele_athome: depends from which kernel version you've upgraded and how
Nov 03 15:18:03 <daniele_athome> JaMa, latest shr-unstable with normal opkg
Nov 03 15:18:24 <daniele_athome> you think a depmod -a is enough?
Nov 03 15:18:37 <JaMa> yes
Nov 03 15:18:45 <JaMa> what do you have in lsmod?
Nov 03 15:19:00 <gena2x> DocScrutinizer: also think, I tried to do that in VSYNC (slow down pixlock while VSYNC), but that did not produce complete jitterless data.
Nov 03 15:19:48 <JaMa> daniele_athome: every kernel module upgrade from opkg calls depmod -a ${PV} so it should be ok.. but if you don't have any module loaded then it could be it
Nov 03 15:20:16 <daniele_athome> ok rebooting inside FR
Nov 03 15:20:18 <daniele_athome> and checking mods
Nov 03 15:20:28 <daniele_athome> mmm...
Nov 03 15:20:28 <gena2x> DocScrutinizer: but sure, it may be worth to do some more experiments. but current version works from very well from any point of view (performance, latency, complexity, stabily is ok)
Nov 03 15:21:07 <gena2x> lindi-: i think it is's better to fix #3
Nov 03 15:21:13 <gena2x> lindi-: i think it is's better to fix #2309
Nov 03 15:21:21 <DocScrutinizer> gena2x: I can explain to you every single one of your observations regarding jitter
Nov 03 15:23:37 <lindi-> gena2x: well this is a way to debug it
Nov 03 15:24:05 <DocScrutinizer> I agree with gena2x on better fixing the bug than starting a watchdog that only could reboot the device anyway, and will add complexity and problems to bootup/resume of *every* system flavour
Nov 03 15:25:24 <gena2x> lindi-: debug? do does it better than removing battery? or attaching debugging board?
Nov 03 15:26:04 <DocScrutinizer> see friggin bootloop problems with maemo, where they do exactly that watchdog start in NOLO BL, unless R&D mode enabled
Nov 03 15:26:23 <lindi-> gena2x: yes I don't currently have any idea if the cpu is even executing instructions or not
Nov 03 15:26:55 <lindi-> gena2x: if watchdog started at u-boot resume path is able to restart this then I can start moving the wd startup further up in the resume path
Nov 03 15:26:57 <daniele_athome> mmm...
Nov 03 15:27:02 <daniele_athome> JaMa, no modules in loaded in fact
Nov 03 15:27:06 <daniele_athome> but depmod -a didn't work
Nov 03 15:27:24 <gena2x> lindi-: why not jsut attach dboard and just look to backtrace?
Nov 03 15:27:30 <DocScrutinizer> I'm quite convinced we see a lot of such problems from age old idiocy to have level-triggered IRQ rather than edge triggered
Nov 03 15:27:37 <daniele_athome> mmm
Nov 03 15:27:48 <daniele_athome> JaMa, seems that modules files are not here
Nov 03 15:28:28 <gena2x> lindi-: if i had one... this would be my first action
Nov 03 15:28:37 <DocScrutinizer> or was it other way round? anyway IRQ handling is FUBAR
Nov 03 15:29:37 <lindi-> gena2x: I don't think I had one when I reported it originally and nobody suggested it :)
Nov 03 15:29:46 <daniele_athome> ehm :S
Nov 03 15:29:56 <lindi-> gena2x: and also when it crashes I'm usually not near the debug board
Nov 03 15:30:00 <DocScrutinizer> I wrapped my head around this several times, and even Andy agreed it's not like it *should* be, but he claimed "doing it the right way yielded bad results for unknown reasons, so I decided to keep it this way"
Nov 03 15:31:16 <DocScrutinizer> another bug fixed as WFM/WONTFIX
Nov 03 15:31:27 <daniele_athome> JaMa, every usb module is vanished :S
Nov 03 15:31:38 <gena2x> hehe 'even Andy agreed' :)
Nov 03 15:32:56 <DocScrutinizer> basically it seems none of the SW devels really got a clear idea on how IRQ hw works and how to handle it correctly
Nov 03 15:33:33 <DocScrutinizer> and lots of race windows left open
Nov 03 15:33:48 <gena2x> waaait, we seem started to discuss 100 issues in parallel
Nov 03 15:34:01 <DocScrutinizer> age old rule: leave a window for a race and it will bite you eventually
Nov 03 15:34:43 <DocScrutinizer> nah, I'm out again. couldn't bother anymore about it
Nov 03 15:34:50 <daniele_athome> JaMa, booting with emergency 2.6.34 
Nov 03 15:34:58 <daniele_athome> JaMa, a quick way to reinstall all kernel packages?
Nov 03 15:35:06 <gena2x> DocScrutinizer: ah... thanks for idea about gps anyway
Nov 03 15:35:41 <DocScrutinizer> I investigated jitter, and IRQ, and whatnot, some 2..3 yers ago. It's off my table now
Nov 03 15:36:19 <gena2x> DocScrutinizer: why nobody written jitterless driver at that time?
Nov 03 15:36:42 <DocScrutinizer> busy with 'more mportant things'?
Nov 03 15:36:58 <gena2x> i don't know :)
Nov 03 15:37:43 <gena2x> but filtering is really more complicated that jitterless driver.
Nov 03 15:39:34 <DocScrutinizer> look at how this tp works, then you'll easily understand why one axis has more jitter from LCD refresh, while other axis has more ambient hum. Also you understand what can and what can't be done by the different sw methods and syncing methods
Nov 03 15:40:29 <DocScrutinizer> there's just so much that can be done about ambient hum
Nov 03 15:41:03 <DocScrutinizer> but LCD refresh coubling to lower plane of tp is quite under our control and well understood
Nov 03 15:41:13 <DocScrutinizer> coupling*
Nov 03 15:42:36 <DocScrutinizer> and quite obciously capacitive interference from LCD to tp is worse when lower plane is sensing plane than when lower plane is drivven gradient plane
Nov 03 15:42:46 <DocScrutinizer> driven*
Nov 03 15:42:59 <gena2x> DocScrutinizer: it would be nice to hear explanations, but i think i am unsure now about all experimental data.
Nov 03 15:43:14 <gena2x> DocScrutinizer: ok, this is x/y diff.
Nov 03 15:43:24 <DocScrutinizer> And I'm unsure about my mood and motivation to explain
Nov 03 15:44:28 <gena2x> DocScrutinizer: my reason is that i did measurements 3 month ago, so i just now unsure about details :(
Nov 03 15:45:02 <daniele_athome> JaMa, ehm... what is the latest shr-u kernel version?
Nov 03 15:45:06 <daniele_athome> guys anyone you know?
Nov 03 15:45:11 <DocScrutinizer> I did meassurements 3 years ago, but I still remember the obvious conclusions
Nov 03 15:45:22 <daniele_athome> bozza
Nov 03 15:45:31 <daniele_athome> 2.6.34.7
Nov 03 15:45:38 <daniele_athome> ok my fault JaMa, i'm sorry :(
Nov 03 15:46:20 <DocScrutinizer> EE messed it up by omitting any filters (esp lp) in tp driving hw
Nov 03 15:47:07 <DocScrutinizer> so the tp catches up ambient noise, which is LCD refresh from below and 50Hz humm and RF from the 'outside'
Nov 03 15:47:25 <DocScrutinizer> both should have been filtered out in hw, but OM EE didn't
Nov 03 15:48:19 <DocScrutinizer> a first order R/C lowpass with a -3dB @20Hz would have done the trick I guess
Nov 03 15:48:30 <gena2x> DocScrutinizer: may be this is because you had explanation, while i am not hw engineer, and in the end i had no clean idea what is source of jitter, only idea how to avoid it.
Nov 03 15:49:35 <gena2x> DocScrutinizer: based on input data that with glamo turned off ts has no jitter.
Nov 03 15:50:39 <DocScrutinizer> ...as long as you're not in a highly 50Hz or RF contaminated environment, yes.
Nov 03 15:50:55 <DocScrutinizer> GSM = RF too, btw
Nov 03 15:51:13 <DocScrutinizer> so don't expect jitter free during calls or GPRS
Nov 03 15:51:36 <gena2x> DocScrutinizer: hm. easy to test :)
Nov 03 15:53:04 <DocScrutinizer> of course GSM is way too high frequency to introduce any jitter on carrier interference, but we seen with buzz issue there's lots of occasions where RF->LF
Nov 03 15:54:01 <DocScrutinizer> A nearby 150kHz braodcast transmitter though will surely interfere directly with ts AD
Nov 03 15:55:27 <DocScrutinizer> anyway, have fun, kids!
Nov 03 15:55:34 <DocScrutinizer> o/
Nov 03 15:55:35 <gena2x> DocScrutinizer: Main problem for me while my investigation, that i were unable to find any unformity in ts jitter.
Nov 03 15:55:36 <JaMa> daniele_athome: what did you wrong? :)
Nov 03 15:55:54 <daniele_athome> JaMa, uImage was still linked to 2.6.32
Nov 03 15:55:57 <daniele_athome> don't know why
Nov 03 15:57:16 <DocScrutinizer> gena2x: aliasing on a >1:100 rate, and even one of the waves not being anything near sinusoidal, is not likely to show any recognizable pattern
Nov 03 15:58:05 <DocScrutinizer> you're basically sampling picture brightness at random points of screen
Nov 03 15:58:33 <DocScrutinizer> (extremely simplified figure)
Nov 03 15:58:47 <gena2x> DocScrutinizer: ah
Nov 03 15:58:54 <gena2x> DocScrutinizer: i tested this :)
Nov 03 15:59:15 <gena2x> DocScrutinizer: problem is that black and white screen has same jitter
Nov 03 16:00:20 <DocScrutinizer> yes, because the refresh is running across the screen panel at high freq. Remember the black and white bars runing down or up videaos of CRT TV screens?
Nov 03 16:00:31 <DocScrutinizer> you're running into a similar effect
Nov 03 16:01:29 <gena2x> DocScrutinizer: no, our screen seem working in other way... someone even made video now does it look like in low refresh.
Nov 03 16:01:39 <gena2x> DocScrutinizer: let me find it...
Nov 03 16:01:57 <DocScrutinizer> now you're sampling "picture brightness" of a single point of that video'ed screen, at a random point n time
Nov 03 16:03:02 <DocScrutinizer> what I suggest is not to switch off the CRT during sampling, but to do sampling only when the black bar has just hit bottom of CRT piscture
Nov 03 16:03:21 <gena2x> DocScrutinizer: wait a bit for video...
Nov 03 16:04:15 <gena2x> DocScrutinizer: http://death-head.ch/blog/2010/10/strange-effects-on-my-openmoko-display-with-qtmoko-v28-and-jitterless-kernel/
Nov 03 16:04:22 <DocScrutinizer> you still get a error factor itroduced by the picture content of the CRT, but it's not jittering anymore
Nov 03 16:04:52 <DocScrutinizer> sorry, no time for that. cya
Nov 03 16:05:09 <gena2x> DocScrutinizer: ah. ok, gl.
Nov 03 16:05:26 <daniele_athome> goodnight! :)
Nov 03 16:06:03 <JaMa> daniele_athome: uImage link is adjusted by u-a, and it's using last part of version as priority so (2.6.32 -> 32, 2.6.34.7 -> 7)
Nov 03 16:08:16 <DocScrutinizer> one last comment: gena2x, I recall I mentioned exactly all the points you're doing now, when arguing quite some months or even a year ago about why ts jitter filtering MUST go into kernel and can't be done in a lib
Nov 03 16:09:26 <DocScrutinizer> my exact words were something like "imagine we find we have to do AD on a certain monent in time synced to LCD refresh, or even need to switch some of the LCD parameters for one frame. How to do that by a lib in userland?"
Nov 03 16:10:07 <DocScrutinizer> nobody listened, so MEH
Nov 03 16:10:10 <gena2x> DocScrutinizer: i agree with you that filtering should not be done in userspace
Nov 03 16:11:14 <gena2x> DocScrutinizer: heh, only way to draw attention this topic were to write patch :)
Nov 03 16:11:44 <gena2x> DocScrutinizer: i mean anyway it should be done in kernel.
Nov 03 16:12:56 <gena2x> DocScrutinizer: but if you still here, few words about video :). As you can see, video shows glamo with slow refresh rate. you can see that in 1fps, lcd _slowly_ fades back to white.
Nov 03 16:16:27 <gena2x> DocScrutinizer: So, if i understood your theory correctly, we should see almost same buzz with such pixclock rate? we have white areas, black areas and if we are measuring adc at one location we should get exactly same range or noise.
Nov 03 16:17:15 <DocScrutinizer> nope, as the coupling from LCD to TP is capacitive, effectively implementing a highpass
Nov 03 16:17:56 <DocScrutinizer> 50 times lower pixel clock is 50 times looser coubling from refresh to touchpanel
Nov 03 16:18:14 <DocScrutinizer> coupling, wtf wring with my fingers?
Nov 03 16:19:29 <gena2x> DocScrutinizer: sorry, seem my knowledge and expierence in such low-level things prevents me from understanding all your theory :(
Nov 03 16:19:53 <gena2x> DocScrutinizer: but anyway, now we have jitterless touchscreen driver.
Nov 03 16:21:57 <gena2x> DocScrutinizer: so, in fact, where is no need to work on this topic anymore.
Nov 03 16:29:54 <DocScrutinizer> gena2x: lemme try once more... You got a tp with two panels. one has a plus and minus side and current flowing across, such building up a voltage gradient. That's the driven gradient plane. in 90° to it there's a 2nD similar plane that touches first plane at touchpoint and whole plane gets voltage of the gradient at that point. this voltage is detected then by AD. (for the other axis gradient and sense plane switch roles) No 
Nov 03 16:29:55 <DocScrutinizer> think of the sense plane in close contact to LCD. LCD has rows which get some 5..30V to drive pixels. LCD controller sweeps over the whole 800 rows for one refresh. These voltage jumps on the rows couple to the tp sense plane like in a capacitor. Depending on current state of refresh while AD takes place, and location of touchpoint, you see different erratic voltage induced into sense plane and spoiling the true voltage value from 
Nov 03 16:29:57 <DocScrutinizer> gradient. If the plane next to LCD is the gradient plane, situation is similar, but a bit different level. that's why you see different jitter for X and Y. If you reduce pixel clock then the frequency of the AC in LCD is lowered and thus less of it couples to the tp planes, as in basic capacitor properties. That's why reducing pixclck by 50 also reduces jitter by 50. Anyway if you'd manage to AD *always* *only* when LCD has 
Nov 03 16:29:58 <DocScrutinizer> finished one sweep and before it sterts next sweep, you should get least jitter possible
Nov 03 16:35:12 <DocScrutinizer> that's why I suggest to do AD during HSYNC, as that's the moment where none of the rows (or cols, whatever is the outmost) is driven to high voltage, so nothing spoils the gradient voltage in TP
Nov 03 16:36:46 <DocScrutinizer> plus, additional benefit: you don't need to do nasty tricks to pixclck which are prone to cause all kinds of side effects to LCD controller (the chip inside LCD)
Nov 03 16:37:31 <DocScrutinizer> plus you don't need to mess with glamo, which is a mega fine thing in itself
Nov 03 16:38:14 <gena2x> DocScrutinizer: [about touchscreen structure] -> touchscreen has 4 inputs XM, XP, YM, YP. i guess it should have 4 planes, 2 for each axis?
Nov 03 16:38:15 <DocScrutinizer> all you need to do is wait for HSYNC and then trigger an AD
Nov 03 16:38:46 <DocScrutinizer> nope, these are Plus and Minus for each of X and Y
Nov 03 16:40:45 <DocScrutinizer> you apply GND to XM and 3V to XP, then sense voltage on eithe YM or YP which both are virtually unconnected at that time. Then you apply 3V and GND to YP & YM and sense voltage on either XP or XM, for other (Y) axis
Nov 03 16:42:12 <DocScrutinizer> that's how FR 4 wire resistive touchpanel works
Nov 03 16:43:06 <DocScrutinizer> obviously the sensing plane is more prone to catch noise than the driven gradient plane
Nov 03 16:44:09 <DocScrutinizer> as planes switch roles for X and Y, you see more noise from LCD when plane next to LCD has role of sensing plane, than you do when that plane is the driven gradient plane
Nov 03 16:45:48 <DocScrutinizer> which means, for one of the axis you have strong jitter independent of touchpoint, while for the other axis you get less jitter and it even get less when touchpoint is near to eithe P or M connection side
Nov 03 16:46:37 <lindi-> gena2x: I think I tried connecting the debug board while the fr was stuck but did not mention it in the bug report it seems
Nov 03 16:47:09 <gena2x> DocScrutinizer: [reducing pixclock by 50 reduces jitter by 50] -> unfortunately, not actually, it is reduced may be ~5-10 times while refresh reduced i >50 times.
Nov 03 16:48:26 <DocScrutinizer> hmm, this was a simplified picture, as LCD refresh is not a sinus signal, which menas reducing pxclck doesn't reduce noise signal frequency in exactly same amount
Nov 03 16:49:05 <DocScrutinizer> during VSYNC your resilts should be same like with suspended LCD
Nov 03 16:49:17 <gena2x> DocScrutinizer: [don't need to mess with glamo] -> you have to wait for H/V SYNC somehow, so you have to anyway talk to glamo. sure, reading is better
Nov 03 16:49:46 <DocScrutinizer> well, now for real: cya, guys
Nov 03 16:50:36 <gena2x> DocScrutinizer: really, thank you much for explanation. I promise to check your thoery soon! it is really easy - my driver can wait for VSYNC, and i can get the data.
Nov 03 16:52:09 <gena2x> gena2x: while we in 'VSYNC' (virtual of course as this is LCD) state. I'll just slow down pixclock and perform ADC while in VSYNC. and if it will have 0 jitter, you theory is right.
Nov 03 16:52:21 <gena2x> DocScrutinizer: i'll share results sooner or later :)
Nov 03 16:53:49 <gena2x> DocScrutinizer: and thanks again for explanations, i am a but slow that it comes to analog devices, but i always likes physics :)
Nov 03 16:53:57 <gena2x> s/but/bit/
Nov 03 16:53:57 <apt> gena2x meant: DocScrutinizer: and thanks again for explanations, i am a bit slow that it comes to analog devices, but i always likes physics :)
Nov 03 17:01:18 <gena2x> lindi-: [back to your GSTATUS pr] so, backtrace may help greatly with handling issue. But anyway i can't understand how do you want to arm watchdog in bootloader. who will 'watch' watchdog while suspended? if you really want, you can arm watchdog somehow very early on resume, but i am really in doudbt if this will be useful
Nov 03 17:01:52 <lindi-> gena2x: yes I was thinking about having it watch the resume process
Nov 03 17:01:56 <lindi-> gena2x: not during suspend
Nov 03 17:02:05 <lindi-> since the maximum period with 50 MHz PCLK is only 42 seconds
Nov 03 17:02:26 <lindi-> if I could set watchdog period to a few minutes it might be ok to periodically wake with rtc to keep watchdog happy
Nov 03 17:03:46 <DocScrutinizer51> completely useless
Nov 03 17:05:39 <lindi-> gena2x: that way it'd increase my chances of being able to answer calls just a bit :)
Nov 03 17:05:50 <DocScrutinizer51> either uboot gets invoked on suspend, then you have a bug to fix why kernel doesn't resume. Or you are screwed on cpu even resuming to uboot, then how in earth could a wd help? resuming on RTC alarm to tickle wd is definitlely a nogo
Nov 03 17:06:21 <lindi-> DocScrutinizer51: well it'd improve the current situation
Nov 03 17:07:11 <DocScrutinizer51> hmm I don't see how uBoot is involved in that
Nov 03 17:07:52 <DocScrutinizer51> you as well can keep wd alive during suspend without messing with uboot
Nov 03 17:08:08 <lindi-> DocScrutinizer51: yes there are two possible strategies
Nov 03 17:08:16 <lindi-> DocScrutinizer51: 1) start wd in u-boot during resume
Nov 03 17:08:24 <lindi-> DocScrutinizer51: or 2) keep wd running all the time
Nov 03 17:08:30 <lindi-> 1) helps me to narrow down the problem
Nov 03 17:08:35 <gena2x> stoood
Nov 03 17:08:39 <DocScrutinizer51> wtf? why start wd on resume???
Nov 03 17:08:51 <gena2x> 'u-boot during resume'?
Nov 03 17:08:56 <lindi-> DocScrutinizer51: that'd give me more information
Nov 03 17:09:13 <gena2x> ^^^^ how u-boot related to resume?
Nov 03 17:09:30 <lindi-> gena2x: cpu/arm920t/start.S is run on resume
Nov 03 17:09:38 <DocScrutinizer51> bs, switching on blue LED does same for that purpose
Nov 03 17:10:10 <lindi-> DocScrutinizer51: I guess expect if the battery runs out
Nov 03 17:10:13 <lindi-> before I notice
Nov 03 17:10:22 <lindi-> gena2x: "/* is this resume from power down */ /* well, if it was, we are going to jump to  * whatever address we stashed in gstatus3,  * and gstatus4 will hold the wake interrupt  * source for the OS to look at  */"
Nov 03 17:11:23 <DocScrutinizer51> lindi-: and that doesn't apply to the much more likely case if hardware ignoring wake IRQ due to misconfig?
Nov 03 17:12:15 <lindi-> DocScrutinizer51: well it could narrow it down to that
Nov 03 17:12:33 <lindi-> by essentially proving that cpu executes no code
Nov 03 17:12:46 <lindi-> DocScrutinizer51: however, since consumption is larger than normally we either have partial resume or partial suspend
Nov 03 17:13:10 <DocScrutinizer51> how's watchdog helping on that, while LED doesn't
Nov 03 17:13:12 <gena2x> lindi-: bootloader code should not be executed on resume! i do not believe!
Nov 03 17:13:23 <lindi-> DocScrutinizer51: it won't run the battery out :)
Nov 03 17:13:30 <lindi-> gena2x: read the source :)
Nov 03 17:13:48 <lindi-> gena2x: it's both in u-boot and qi
Nov 03 17:14:02 <gena2x> lindi-: you should get resume with reason 'battery low' from PMU in case if your battery is low
Nov 03 17:14:12 * DocScrutinizer51 shakes head
Nov 03 17:16:19 <gena2x> lindi-: resume from ___POWER DOWN___
Nov 03 17:16:31 <lindi-> gena2x: but it does not go to powe down
Nov 03 17:16:34 <DocScrutinizer51> lindi-: watch you logs. isn't there clearly gstatus3/4 mentioned? So obviously you got some code executed that prints these lines. you should find out about and fix the bug
Nov 03 17:16:44 <lindi-> gena2x: it is in this weird state that consumes energy more than normal suspend
Nov 03 17:17:02 <lindi-> gena2x: it does not wake even if I remove the battery which normally generates battery low interrupt
Nov 03 17:17:22 <lindi-> DocScrutinizer51: the code is in suspend path
Nov 03 17:18:11 <gena2x> lindi-: so, it can't suspend properly.
Nov 03 17:18:26 <lindi-> gena2x: that is one possibility yes
Nov 03 17:18:59 <gena2x> lindi-: if it consumes more energy than usual means that it didn't suspend properly
Nov 03 17:19:15 <lindi-> gena2x: or it resumed partially and crashed?
Nov 03 17:19:44 <gena2x> lindi-: does it enter proper suspended state?
Nov 03 17:19:54 <gena2x> lindi-: with proper power consumption?
Nov 03 17:20:09 <lindi-> gena2x: how can I know?
Nov 03 17:20:19 <lindi-> gena2x: this occurs only once every few weeks
Nov 03 17:20:27 <gena2x> lindi-: ah.
Nov 03 17:21:03 <gena2x> lindi-: ok. let it be my next puzzle, but now i want to fix my gps!
Nov 03 17:21:41 <lindi-> gena2x: heh :)
Nov 03 17:21:46 <gena2x> lindi-: i can try to help with this gstatus thing. would be nice if you get backtrace somehow.
Nov 03 17:29:06 <DocScrutinizer51> lindi-: report bq27k values to a file during suspend. if resume hangs you compare  the actual values to those from suspend
Nov 03 17:29:50 <lindi-> DocScrutinizer51: I don't have the hardware to do that
Nov 03 17:30:04 <DocScrutinizer51> I bet on suspend fucked up due to a race
Nov 03 17:30:23 <DocScrutinizer51> err, no hw?
Nov 03 17:30:43 <gena2x> sure, if it sometimes suspend sometimes not, probably this is race :)
Nov 03 17:31:22 <lindi-> DocScrutinizer51: how would you talk to bq27k during suspend?
Nov 03 17:31:23 <DocScrutinizer51> I even know which one: resume IRQ pending during suspend
Nov 03 17:32:16 <gena2x> heh, we'll see... after my serial port be fixed! :)
Nov 03 17:32:21 <DocScrutinizer51> lindi-: not during suspended state, you write to file ON entereing suspend, I.E directly before suspending
Nov 03 17:33:00 <DocScrutinizer51> and after noticing resume hangs you don't charge bat, instead read out again immediately
Nov 03 17:34:23 <lindi-> DocScrutinizer51: I need to take the battery out to reboot?
Nov 03 17:34:24 <DocScrutinizer51> this obviously should give you an idea if it was suspended or not most of the time
Nov 03 17:34:34 <DocScrutinizer51> so what?
Nov 03 17:35:00 <DocScrutinizer51> battery has bq27000 which will keep the values
Nov 03 17:35:05 <lindi-> hmm
Nov 03 17:35:37 <lindi-> DocScrutinizer51: the trouble is that I have periodic rtc wakeups. if it hits one of those it'll be in this odd state for quite a while before I notice
Nov 03 17:35:49 <lindi-> DocScrutinizer51: but your idea would work if I always used power button to resume
Nov 03 17:39:23 <DocScrutinizer51> anyway I'm rather sure I remember to have spotted a race window on suspend code, when resume IRQ is pending or hitting during suspend
Nov 03 17:40:04 <DocScrutinizer51> a edge vs level IRQ trigger problem
Nov 03 17:40:08 <DocScrutinizer51> once again
Nov 03 17:41:05 <lindi-> DocScrutinizer51: can you think of a way to verify that?
Nov 03 17:41:22 <DocScrutinizer51> yeah, JTAG
Nov 03 17:41:30 <lindi-> DocScrutinizer51: I think I tried that and it doesn't work in suspend
Nov 03 17:41:34 <lindi-> I can try again
Nov 03 17:42:23 <DocScrutinizer51> aiui you aren't in suspend. but then otoh you'd expect the wake IRQ to be set anyway when issie hits
Nov 03 17:43:23 <lindi-> DocScrutinizer51: so your hypothesis is that it never reaches sleep.S in kernel?
Nov 03 17:43:36 <DocScrutinizer51> see, if the wake IRQs are edge and asserted while suspending then noting will ever resume the SXoC
Nov 03 17:44:07 <lindi-> DocScrutinizer51: but that'd require all wake IRQs to be asserted?
Nov 03 17:45:11 <DocScrutinizer51> otoh if suspend code doesn't cope nicely with pending level triggered IRQ you will see a aborted suspend and device doesn't recover from that
Nov 03 18:02:34 <lindi-> gena2x:   cat /sys/devices/platform/s3c2440-uart.1/clock_source    causes oops here with 2.6.4
Nov 03 18:02:37 <lindi-> gena2x:   cat /sys/devices/platform/s3c2440-uart.1/clock_source    causes oops here with 2.6.34
Nov 03 18:02:40 <lindi-> gena2x: does it work for you
Nov 03 18:06:56 <gena2x> lindi-: hm!
Nov 03 18:07:07 <gena2x> lindi-: yes. but only _before suspend_!
Nov 03 18:07:53 <gena2x> lindi-: this may be somehow related to my problems with gps
Nov 03 18:07:58 <anarsoul> gena2x: I think this issue is fixed in 2.6.37
Nov 03 18:08:01 <anarsoul> :)
Nov 03 18:08:26 <gena2x> anarsoul: what? someone ported .37 for freerunner?
Nov 03 18:08:41 <anarsoul> gena2x: nope, uart issue is common for all s3c24xx-devices
Nov 03 18:08:44 <anarsoul> http://www.spinics.net/lists/linux-serial/msg02683.html
Nov 03 18:08:55 <anarsoul> try this patch
Nov 03 18:09:11 <anarsoul> gena2x: generic symptom is uart not working after suspend
Nov 03 18:09:14 <anarsoul> :)
Nov 03 18:09:18 <lindi-> anarsoul: gena2x: please put these to the bug report
Nov 03 18:09:37 <anarsoul> lindi-: I'm not registered on your bugzilla
Nov 03 18:09:45 <gena2x> anarsoul: omg, thank you for reading this echo. gena2x gone to read it.
Nov 03 18:12:19 <gena2x> lindi-: and oops happens only with gps uart
Nov 03 18:13:59 <gena2x> anarsoul: but sad, this is not my case anyway. i can control port setup via registers on cpu
Nov 03 18:14:10 <gena2x> anarsoul: and port is functional
Nov 03 18:14:30 <gena2x> anarsoul: i can even do loopback test without problems.
Nov 03 18:14:40 <gena2x> anarsoul: so, here is something else...
Nov 03 18:16:24 <anarsoul> ok
Nov 03 18:24:47 <gena2x> lindi-: hm... and now it works...
Nov 03 18:26:36 <anarsoul> gena2x: without any changes?
Nov 03 18:27:29 <gena2x> [reading clock_sources] aha, i got idea. clock_source fails (here) then and only then serial is not configured.
Nov 03 18:27:53 <gena2x> i mean, neo:~# cat /sys/devices/platform/s3c2440-uart.1/clock_source 
Nov 03 18:27:53 <gena2x> Segmentation fault
Nov 03 18:27:53 <gena2x> neo:~# cat /dev/ttySAC1 ... neo:~# cat /sys/devices/platform/s3c2440-uart.1/clock_source 
Nov 03 18:27:53 <gena2x> * pclk
Nov 03 18:28:18 <gena2x> and after that it works, i'll add this to tracker....
Nov 03 18:39:12 <gena2x> no, power-down-before-suspend idea is not working.
Nov 03 18:44:50 <gena2x> it really should be possible to bring up gps chip somehow
Nov 03 18:45:04 <gena2x> reset or so
Nov 03 19:21:35 <gena2x> ok, i am high grade idiot. gpios were not setup properly for my port...
Nov 03 19:22:14 <gena2x> interesting, how it is working in qi.
Nov 03 19:35:14 <vanous> lindi-: on debian, what package is providing tc?
Nov 03 19:35:37 <lindi-> vanous: apt-file search bin/tc
Nov 03 19:36:15 <gena2x> bugs, bugs, bugs. kernel decided not to configure RX pin.
Nov 03 19:36:27 <gena2x> of my gps
Nov 03 19:37:20 <vanous> lindi-: thanks, installed apt-file and am generating search cache :)
Nov 03 19:38:04 <gena2x> lindi-: are you using qi? gps really work after resume?
Nov 03 19:39:11 <gena2x> lindi-: can i ask you to do 5 minutes test for me?
Nov 03 19:51:35 <vanous> gena2x: can an ordinary person do the test or is kernel hacker required? :)
Nov 03 19:52:15 <gena2x> vanous: thanks for offer! yes.
Nov 03 19:52:29 <gena2x> vanous: are you using qi and 34 kernel?
Nov 03 19:52:37 <vanous> yup
Nov 03 19:54:09 <gena2x> vanous: ok, i am preparing exact steps
Nov 03 19:54:18 <vanous> ok
Nov 03 19:54:25 <vanous> will i need a sim card?
Nov 03 19:54:36 <gena2x> vanous: nope, only 1 reboot
Nov 03 19:54:39 <vanous> ok
Nov 03 19:54:44 <vanous> np, am here then
Nov 03 20:01:06 <gena2x> vanous: http://www.bsdmn.com/openmoko/gpio/testgpio
Nov 03 20:01:38 <gena2x> vanous: just can&paste it to terminal and tell me output
Nov 03 20:02:08 <vanous> gena2x: need to be outside or on satellites' reach?
Nov 03 20:02:15 <gena2x> vanous: nono
Nov 03 20:02:20 <vanous> ok
Nov 03 20:02:24 <vanous> halting now
Nov 03 20:02:38 <gena2x> vanous: this is just serial setup test.
Nov 03 20:02:52 <vanous> ok
Nov 03 20:08:08 <vanous> gena2x: sorry took longer, had to find memwrite
Nov 03 20:08:12 <vanous> first dump:
Nov 03 20:08:14 <vanous> addr[560001A8]=0xAA 0xA9 0x1A 0x00
Nov 03 20:08:52 <vanous> second:
Nov 03 20:08:54 <vanous> addr[560001A8]=0xAA 0xAA 0x1A 0x00
Nov 03 20:09:01 <gena2x> vanous: ah, i didn't told, i put it to same dir,  http://www.bsdmn.com/openmoko/gpio/memwrite...
Nov 03 20:09:13 <vanous> nvm, have it
Nov 03 20:09:35 <vanous> now suspend
Nov 03 20:09:39 <vanous> how long?
Nov 03 20:10:11 <gena2x> no matter
Nov 03 20:10:16 <gena2x> just suspend and resume
Nov 03 20:10:23 <vanous> after suspend
Nov 03 20:10:24 <vanous> addr[560001A8]=0xAA 0xAA 0x1A 0x00
Nov 03 20:10:53 <gena2x> ok, last test is not need
Nov 03 20:10:58 <vanous> and the last from point 5 addr[560001A8]=0xAA 0xAA 0x1A 0x00
Nov 03 20:11:04 <vanous> ok
Nov 03 20:11:09 <gena2x> thank you much.
Nov 03 20:11:13 <gena2x> you have shr kernel?
Nov 03 20:11:31 <vanous> yes Linux om-gta02 2.6.34.7 #1 Sun Oct 31 20:28:57 CET 2010 armv4tl GNU/Linux
Nov 03 20:12:16 <gena2x> ok, look like your kernel remembers the state of gps and restore it on resume (or just do not reset).
Nov 03 20:13:10 <gena2x> and it is on by the way.
Nov 03 20:13:20 <gena2x> ah, we tested it on.
Nov 03 20:13:22 <gena2x> so ok
Nov 03 20:19:03 <vanous> ok, gn
Nov 03 20:21:26 <gena2x> vanous: night, and thanks again
Nov 03 20:21:36 <vanous> np
Nov 03 20:23:47 <lindi-> gena2x: actually just switched to u-boot :)
Nov 03 20:24:48 <TAsn> mrmoku, ready or not, here I go.
Nov 03 20:25:30 <gena2x> lindi-: heh. so you'll be interested in this fix :)
Nov 03 20:32:36 <mrmoku> TAsn: still waiting...
Nov 03 20:32:56 <TAsn> mrmoku, sec, preparing sd... :P
Nov 03 20:37:16 <TAsn> mrmoku, the kernel in the rootfs is the same kernel in the deploy dir, right?
Nov 03 20:39:14 <mrmoku> TAsn: should be... on n900 there is a gta01 kernel in rootfs though
Nov 03 20:40:26 <TAsn> lol?
Nov 03 20:41:18 <mrmoku> better check ;)
Nov 03 20:43:23 <TAsn> [Rui], ping.
Nov 03 20:43:33 <[Rui]> TAsn: pong.
Nov 03 20:43:54 <TAsn> [Rui], how do you boot qi?
Nov 03 20:43:57 <TAsn> what key combination?
Nov 03 20:43:58 <[Rui]> TAsn: still feeling quite depressed
Nov 03 20:44:06 <TAsn> you should :|
Nov 03 20:44:27 <[Rui]> TAsn: huh... I don't know if it's the same on smartqv7
Nov 03 20:44:56 <TAsn> is it the same combination as "flashing" ?
Nov 03 20:45:24 <GNUtoo|laptop> hi mickeyl 
Nov 03 20:45:40 <GNUtoo|laptop> Unsupported type v
Nov 03 20:45:46 <GNUtoo|laptop> is v supported in mdbus2?
Nov 03 20:45:51 <[Rui]> TAsn: I think it was
Nov 03 20:45:53 <GNUtoo|laptop> or is the syntaz wrong
Nov 03 20:46:02 <[Rui]> qi had to be installed on the sd
Nov 03 20:46:07 <[Rui]> there was a script IIRC
Nov 03 20:46:10 <TAsn> yeah
Nov 03 20:46:12 <TAsn> installed it
Nov 03 20:46:18 <TAsn> and I get something in chinese
Nov 03 20:46:21 <TAsn> and the word SD
Nov 03 20:46:23 <TAsn> and a !
Nov 03 20:46:32 <TAsn> after a nice flash saying "Flashing"
Nov 03 20:46:34 <[Rui]> sounds familiar
Nov 03 20:46:38 <[Rui]> oh wait
Nov 03 20:46:41 <[Rui]> it's not the same as flashing
Nov 03 20:46:50 <JaMa|Off> mrmoku: I don't have gta01 kernel in my n900 images..
Nov 03 20:48:08 <TAsn> [Rui], :P
Nov 03 20:48:19 <[Rui]> TAsn: my post office has a 30 day SLA for complaints
Nov 03 20:48:31 * [Rui] gulps another litre of vodka
Nov 03 20:49:03 <GNUtoo|laptop> mdbus2 -s org.bluez  /org/bluez/1445/hci0 org.bluez.Adapter.SetProperty "Discoverable" b:True => Unsupported type v
Nov 03 20:49:09 <[Rui]> only thing I can do is try to see if it works on the old device, but I'll need to get a bluetooth kbd+mouse
Nov 03 20:49:15 <[Rui]> or usb
Nov 03 20:49:21 <[Rui]> usb's cheaper
Nov 03 20:49:41 <GNUtoo|laptop> JaMa, hi, sorry I wasn't able to look to the oe issue, I got internet issues, basically I was without internet one day
Nov 03 20:49:57 <GNUtoo|laptop> as SHR used autorev....
Nov 03 20:50:02 <TAsn> [Rui], but you don't remember how to boot qi? :(
Nov 03 20:50:14 <[Rui]> it's in a maemo page
Nov 03 20:50:39 <[Rui]> there was http://gitorious.org/qi-smartq
Nov 03 20:50:40 <[Rui]> and 
Nov 03 20:50:49 <mrmoku> JaMa: no?
Nov 03 20:50:59 <mrmoku> hmm
Nov 03 20:51:13 <JaMa> mrmoku: you mean in /boot right?
Nov 03 20:51:49 <[Rui]> TAsn: this has it, IIRC
Nov 03 20:51:52 <[Rui]> http://wiki.maemo.org/Mer/Documentation/Installation#SmartQ
Nov 03 20:52:00 <TAsn> thanks.
Nov 03 20:52:09 <mrmoku> JaMa: http://build.shr-project.org/shr-unstable/images/nokia900/shr-lite-eglibc-ipk--20101101-nokia900-testlab/files-in-image.txt
Nov 03 20:52:25 <mrmoku> has gta01 kernel in /boot and n900 kernel in /boot/boot
Nov 03 20:52:26 <JaMa> http://jama.dyndns-home.com/org.openembedded.shr.images/nokia900/shr-full-eglibc-ipk--20101101-nokia900-testlab/files-in-image.txt
Nov 03 20:52:39 <[Rui]> TAsn: check for: [edit] Booting from SD card 
Nov 03 20:53:03 <JaMa> mrmoku: hmm I remember you reporting it, but then it was ok in next image, strange
Nov 03 20:53:27 <pespin_> GNUtoo|laptop, you can use emtooth for that :)
Nov 03 20:53:27 <[Rui]> TAsn: you have a tar.gz of your image somewhere I can download?
Nov 03 20:53:38 <JaMa> mrmoku: ah I know why :)
Nov 03 20:53:39 <TAsn> [Rui], nope, can upload somewhere though.
Nov 03 20:53:44 <GNUtoo|laptop> pespin_, it's on a console-image
Nov 03 20:53:47 <mrmoku> JaMa: needs some cleaning on buildhost?
Nov 03 20:53:53 <pespin_> GNUtoo|laptop, oh ok :P
Nov 03 20:53:58 <[Rui]> pespin_: does it work? last I tried nothing worked with emtooth (couple of weeks ago)
Nov 03 20:53:59 <JaMa> mrmoku: shr-image.inc is removing /boot form jffs2/ubi images in IMAGE_CMD_jffs2
Nov 03 20:54:01 <GNUtoo|laptop> pespin_, but I'll install emtooth on my phones devices
Nov 03 20:54:02 <[Rui]> TAsn: hms...
Nov 03 20:54:07 <TAsn> [Rui], can you try booting a kernel
Nov 03 20:54:11 <TAsn> just to see if we find out how?
Nov 03 20:54:14 <[Rui]> TAsn: can you do a nc -nv IP PORT < file.tar.gz ?
Nov 03 20:54:41 <TAsn> yeah, sure.
Nov 03 20:54:48 <[Rui]> TAsn: if I find my old device, I though it was here by the side of the sofa but I can't find it, just hope I didn't sent it for recycling
Nov 03 20:54:52 <JaMa> mrmoku: and because ubi images are too big for gta01 then it fails in mkfs.ubifs (with double free error in dmesg - I've already reported it to ubi devs still without patch :/)
Nov 03 20:55:04 <JaMa> mrmoku: so whatever image is built after gta01 gets wrong /boot in it
Nov 03 20:56:47 <mrmoku> heh, ok :P
Nov 03 20:57:24 <TAsn> [Rui], thanks, found how to boot in maemo
Nov 03 20:57:29 <TAsn> but it still doesn't...
Nov 03 20:57:43 <TAsn> oh
Nov 03 20:57:47 <TAsn> maybe no symbolic links
Nov 03 20:57:48 <TAsn> mmnt
Nov 03 20:57:52 <[Rui]> kernel is called /boot/linux-SMDK6410.bin  ?
Nov 03 20:57:54 <pespin_> [Rui], it's due to missing udev
Nov 03 20:58:08 <pespin_> [Rui], bluetoothd is not run on bluetooth powerup
Nov 03 20:58:21 <pespin_> [Rui], if you run it manually before emtooth, it should run afaik
Nov 03 20:59:00 <[Rui]> pespin_: ah... shouldn't FSO handle that adequately?
Nov 03 20:59:09 <[Rui]> how's it being done with wifi?
Nov 03 20:59:32 <pespin_> [Rui], yes, there's a bug filled already ;)
Nov 03 20:59:39 <pespin_> *bug report
Nov 03 21:00:55 <JaMa> mrmoku: I have patch for it now and I'll put /boot back on gta02 (for qi-bootmenu)
Nov 03 21:00:59 <pespin_> [Rui], http://trac.freesmartphone.org/ticket/499
Nov 03 21:02:25 <pespin_> [Rui], ah no sorry, that's another one I reported (has some relation thought)
Nov 03 21:02:46 <pespin_> so in fact there are 2 bugs, but both could be solved at the same time implementing a fix correctly
Nov 03 21:02:57 <TAsn> [Rui], still not booting.
Nov 03 21:03:03 <TAsn> nothing at all.
Nov 03 21:03:18 <GNUtoo|laptop> does someone know how to use that with mdbus2:
Nov 03 21:03:39 <TAsn> [Rui], although it is "getting stuck" in booting from sd
Nov 03 21:03:39 <pespin_> afaik mdbus doesn't support variants
Nov 03 21:03:40 <GNUtoo|laptop> [METHOD]    org.bluez.Adapter.SetProperty( s:none, v:none ) -> ()
Nov 03 21:03:48 <[Rui]> TAsn: ah!
Nov 03 21:03:50 <TAsn> i.e the charging red light is off.
Nov 03 21:05:30 <GNUtoo|laptop> pespin_, ah ok thanks a lot!!!! really because I spent a lot of time on it, trying every possible syntax,reading the source code etc...
Nov 03 21:06:16 <pespin_> [Rui], about the bug in tracker, I use a workaround in code, but udev thing... I prefer just waiting for someone to implement a good way to handle all this, as I don't have time now
Nov 03 21:06:40 <pespin_> GNUtoo|laptop, I'm not sure thought, but just afair
Nov 03 21:06:48 <GNUtoo|laptop> ok
Nov 03 21:06:58 <pespin_> GNUtoo|laptop, you could look at bluez site for some python scripts though :)
Nov 03 21:07:08 <pespin_> which does things like you are looking for
Nov 03 21:07:12 <GNUtoo|laptop> I've some example with dbus-send
Nov 03 21:08:02 <pespin_> ok :) dinner time!
Nov 03 21:09:05 <TAsn> [Rui], nothing.
Nov 03 21:13:02 <TAsn> trying with ext2
Nov 03 21:15:30 <[Rui]> TAsn: sry, baby holding while wife had dinner, now I'm having it.
Nov 03 21:15:40 <TAsn> having what?
Nov 03 21:17:55 <TAsn> ffs it's not booting.
Nov 03 21:18:02 <TAsn> nothing about lights
Nov 03 21:18:03 <TAsn> or whatever
Nov 03 21:18:05 <TAsn> promised
Nov 03 21:18:14 <TAsn> in the qi guide :|
Nov 03 21:20:35 <[Rui]> dinner
Nov 03 21:24:44 * JaMa finally found patch causing only 1 column of icons! :)
Nov 03 21:26:23 <[Rui]> JaMa: was it that one?
Nov 03 21:27:13 <JaMa> 53042
Nov 03 21:28:29 <mrmoku> JaMa: oooohh :D
Nov 03 21:34:00 <[Rui]> JaMa: ouch, biggie
Nov 03 21:38:09 <lindi-> gena2x: DocScrutinizer: now I modified u-boot to turn all leds and vibrator on during boot and resume :)
Nov 03 21:38:27 <lindi-> if it hangs during resume those should stay on
Nov 03 21:39:18 <gena2x> lindi-: i still can't believe that bootloader contains resume code. have you verified it actually works?
Nov 03 21:39:34 <lindi-> gena2x: yes
Nov 03 21:40:02 <lindi-> gena2x: http://paste.debian.net/98964/ causes leds and vibrator to turn on briefly on resume
Nov 03 21:40:19 <lindi-> gena2x: linux then of course disables them shortly after
Nov 03 21:40:41 <gena2x> lindi-: interesting...
Nov 03 21:40:44 <lindi-> gena2x: test for yourself if you don't believe me :)
Nov 03 21:41:03 <gena2x> lindi-: if you told you tested, i now believe :)
Nov 03 21:41:26 <lindi-> anyways, i need something similar for the suspend path
Nov 03 21:43:07 <mrmoku> JaMa: 128 --> 28 ?
Nov 03 21:43:29 <JaMa> mrmoku: discomfitor is already looking to it
Nov 03 21:44:02 <JaMa> mrmoku: this was strange, but I guess it would be oposite problem
Nov 03 21:44:14 <[Rui]> TAsn: ok, I got your file (stopped growing, at least).
Nov 03 21:44:15 <JaMa> mrmoku: the main reason is no ellipsis for icon labels
Nov 03 21:44:23 <TAsn> md5 it
Nov 03 21:44:39 <mrmoku> JaMa: IIRC I had ellipsis when changing icon size to something smaller
Nov 03 21:44:41 <[Rui]> TAsn: also found my SmartQ7, I'll need to find a free SD card
Nov 03 21:44:58 <[Rui]> TAsn: 0eece730c907efd1784dd925af360d5b
Nov 03 21:45:17 <JaMa> mrmoku: I have still full names even with smallest icons
Nov 03 21:45:32 <JaMa> mrmoku: from my desktop :) http://jama.dyndns-home.com/trash/2010-11-03/illume.good.53041.png http://jama.dyndns-home.com/trash/2010-11-03/illume.bad.53042.png
Nov 03 21:45:36 <TAsn> [Rui], yep.
Nov 03 21:46:16 <mrmoku> hmm
Nov 03 21:48:28 <mrmoku> JaMa: maybe it was on n900... I'm quite sure though
Nov 03 21:53:48 <mrmoku> anyway... good work JaMa
Nov 03 21:53:54 <mrmoku> and good night :-)
Nov 03 21:54:14 <JaMa> gnight :)
Nov 03 21:54:42 <JaMa> mrmoku: this one was easy :) crashing Xorg is damn strange :/
Nov 03 21:55:04 <JaMa> with all libs downgraded to really old versions I can still crash it with modified orrery
Nov 03 21:55:07 <TAsn> [Rui], well, any progress?
Nov 03 21:55:28 <[Rui]> TAsn: no free SD around
Nov 03 21:55:38 <[Rui]> I know I have one, I just can't find it
Nov 03 21:56:01 <TAsn> take the one from the moko :P
Nov 03 21:58:06 <[Rui]> TAsn: nay!
Nov 03 21:58:25 <TAsn> :|
Nov 03 21:58:31 <TAsn> I just tried another sd
Nov 03 21:58:32 <TAsn> no go.
Nov 03 22:00:57 <lindi-> hmm, what's the place in linux that turns leds off when you suspend?
Nov 03 22:02:51 <TAsn> brb
Nov 03 22:10:01 <TAsn> [Rui], damn you, get it to work already :P
Nov 03 22:17:57 <[Rui]> TAsn: I will get a cheap 2G sd tomorrow
Nov 03 22:18:32 <TAsn> Grr.
Nov 03 22:21:53 <TAsn> [Rui], anyhow, looks like it either doesn't boot qi
Nov 03 22:22:09 <TAsn> or qi is severely broken
Nov 03 22:22:10 <TAsn> either way
Nov 03 22:22:18 <TAsn> it looks like qi isn't loaded.
Nov 03 22:22:21 <TAsn> *getting
Nov 03 22:22:23 <[Rui]> TAsn: that's very bad, did you do all those partitioning weirdies it needed?
Nov 03 22:22:32 <TAsn> needs nothing
Nov 03 22:22:34 <TAsn> just 1 partition
Nov 03 22:22:36 <TAsn> and free space
Nov 03 22:22:38 <TAsn> in the end
Nov 03 22:22:45 <TAsn> of the sd
Nov 03 22:25:15 <TAsn> <[Rui]> TAsn: that's very bad, did you do all those partitioning weirdies it needed?
Nov 03 22:25:15 <TAsn> <TAsn> needs nothing
Nov 03 22:25:15 <TAsn> <TAsn> just 1 partition
Nov 03 22:25:15 <TAsn> <TAsn> and free space
Nov 03 22:25:17 <TAsn> <TAsn> in the end
Nov 03 22:25:19 <TAsn> <TAsn> of the sd
Nov 03 22:29:59 <gena2x> lindi-: interesting, kernel code will not turn off gps supply on suspend and will not turn on on resume. gena2x wonders much how it working with qi.
Nov 03 22:31:21 <lindi-> gena2x: om gps keep-on-in-suspend controls this
Nov 03 22:31:40 <gena2x> keep-on-in-suspend is other story
Nov 03 22:32:42 <gena2x> i just see that gta02_pm_gps_suspend and gta02_pm_gps_resume are not touching regulators of gps
Nov 03 22:33:54 <gena2x> and suspend construction is completely beautiful "if (!gta02_gps.keep_on_in_suspend ||
Nov 03 22:33:54 <gena2x>                 !gta02_gps.power_was_on)
Nov 03 22:33:54 <gena2x>                 gps_pwron_set(0);
Nov 03 22:33:54 <gena2x> "
Nov 03 22:34:19 <gena2x> while resume lacks of one ! ;)
Nov 03 22:34:25 <gena2x>         if (!gta02_gps.keep_on_in_suspend && gta02_gps.power_was_on)
Nov 03 22:34:25 <gena2x>                 gps_pwron_set(1);
Nov 03 22:37:59 <gena2x> according to regulators setup (non-working), it should be kept in suspend: .state_mem = {
Nov 03 22:37:59 <gena2x>                                         .enabled = 1,
Nov 03 22:37:59 <gena2x>                                 },
Nov 03 22:38:24 <gena2x> i thought this should be simple, just something wrong with u-boot...
Nov 03 22:39:54 <larsc> .state_mem is not used
Nov 03 22:40:22 <gena2x> larsc: yeah, that's why i wrote 'non-working' :)
Nov 03 22:47:58 <gena2x> night all
Nov 03 22:55:13 <gena2x> ah, my bad. suspend code ok. but resume still will not power it on :)
Nov 03 22:55:27 * gena2x really gone
Nov 03 23:01:53 <JaMa> larsc: hi :), I remember some email from you that you have om patches rebased for 2.6.36, do you plan to push again 2.6.36 branches to git.om.org? please..
Nov 04 00:11:26 <PaulFertser> JaMa: uberfix, i bet it wasn't easy to track that one.
Nov 04 00:19:23 <JaMa> PaulFertser: which one? /boot or e-wm? :)
Nov 04 00:20:53 <JaMa> both were very easy actually :)
Nov 04 00:21:16 <[Rui]> JaMa: any idea why my local recipe of elmdentica is borked?
Nov 04 00:21:26 <[Rui]> http://pastebin.ca/1981147
Nov 04 00:21:44 <JaMa> as long as e-wm problem was reproducible on desktop and only few hundrets revision to bisect :)
Nov 04 00:22:22 <JaMa> [Rui]: S = "${WORKDIR}" is wrong
Nov 04 00:22:59 <[Rui]> but sources are unpacked (copied in this case) there
Nov 04 00:23:00 <JaMa> [Rui]: well I think that unpacking whole dirs from file:// doesn't work anymore at all
Nov 04 00:23:14 <[Rui]> ok, then that's it :(
Nov 04 00:23:21 <[Rui]> oh well, will do a make dist-gzip
Nov 04 00:23:31 <JaMa> [Rui]: if they are unpacked right, are they copied with dir or without?
Nov 04 00:23:32 <[Rui]> thanks
Nov 04 00:24:00 <JaMa> [Rui]: maybe you just have to update S to point to elmdentica subdirectory
Nov 04 00:24:04 <[Rui]> copied straight into workdir (there's an ls further down)
Nov 04 00:24:11 <[Rui]> I tried many variations on S
Nov 04 00:24:34 <[Rui]> but it fails for one reason or another, with the different values, because some stuff isn't where it expected it to be
Nov 04 00:24:49 <JaMa> but better to checkout "inherit srctree"
Nov 04 00:26:04 <JaMa> [Rui]: try SRC_URI = "file:///media/devdisk/enlightenment/svn/" and S = "${WORKDIR}/elmdentica", just for test
**** ENDING LOGGING AT Thu Nov 04 02:59:57 2010