**** BEGIN LOGGING AT Tue Dec 23 02:59:59 2014
Dec 23 09:09:29 <lumag> ant_work, hello.
Dec 23 09:09:39 <lumag> I'm debugging the collie wakeup.
Dec 23 09:09:53 <lumag> I don't know why I didn't have those issues with my setup.
Dec 23 09:10:14 <ant_work> gm
Dec 23 09:11:00 <lumag> Anyway I have identified few problems.
Dec 23 09:11:01 <ant_work> note that w/out locomo patches susp-resume works but reboot puts collie to freeze (no wakeup by on/off)
Dec 23 09:11:13 <lumag> Yep, the reboot was the easiest problem.
Dec 23 09:11:15 <ant_work> collie reboot is fishy...
Dec 23 09:11:17 <ant_work> ;)
Dec 23 09:11:44 <lumag> It looks like a generic sa1100 problem (ugh).
Dec 23 09:13:04 <lumag> The kernel is not resetting the 'reset cause'.
Dec 23 09:13:23 <lumag> If you remember, the 'sleep' is just a special form of reset.
Dec 23 09:13:38 <ant_work> yes
Dec 23 09:14:41 <lumag> So after sleep the 'reset cause' register has a 'resume' bit set. This tells bootloader to load a value from 'scratchpad' register and use it to resume.
Dec 23 09:15:46 <lumag> After you 'reboot' the unit, this 'sleep' bit is still set (nobody clears that), so the bootloader reads dummy value from scratchpad and jumps into the limbo.
Dec 23 09:16:23 <lumag> Technically this is a problem of bootloader/kernel interaction. However as the bootloader is fixed, we can just fix the kernel.
Dec 23 09:21:06 <ant_work> can this explain the issues of new kexecboot (with 3.10 kernel ?)
Dec 23 09:22:00 <ant_work> I understand the running kernel writes badly the registers
Dec 23 09:22:29 <ant_work> but what about the fresh booting kernel? maybe 2.6.31 was ignoring something on boot
Dec 23 09:22:47 <ant_work> while 3.x did refuse to boot
Dec 23 09:22:58 <ant_work> I guess it was the LOW_BATTERY or such
Dec 23 09:26:10 <lumag> No, it's not the kernel.
Dec 23 09:26:20 <lumag> Maybe old kexecboot/kernels contained additional patches.
Dec 23 09:26:42 <lumag> Maybe Russell changed something (what is the working kexecboot kernel version, btw?)
Dec 23 09:27:53 <lumag> I'm disabling wakeup through 'remote controller' since nobody probably has that
Dec 23 09:28:56 <lumag> It's not the kernel writing the registers badly.
Dec 23 09:29:05 <lumag> It's the kernel badly not writing to register.
Dec 23 09:38:02 <lumag> ant_work, btw, I have the feeling that LZ4 compression gives better results on collie compared to lzma
Dec 23 09:38:45 <ant_work> we only have the 1mb limit for linux-kexecboot
Dec 23 09:38:53 <ant_work> iirc we use xz now
Dec 23 09:39:15 <ant_work> for the production kernel we can use faster decompre4ssors
Dec 23 09:40:00 <lumag> ok, maybe for me the issue is reading from slow CF card
Dec 23 09:58:40 <lumag> ant_work, final test and I'll send you patches fixing the issue.
Dec 23 09:59:09 <ant_work> no, there must be some issue
Dec 23 09:59:20 <ant_work> kexec takes 20x on collie than on poodle
Dec 23 09:59:33 <lumag> misaligns maybe?
Dec 23 09:59:37 <ant_work> I have to test on cmdline
Dec 23 09:59:41 <ant_work> kexec -l
Dec 23 09:59:45 <ant_work> and then kexec -r
Dec 23 09:59:49 <ant_work> err -e
Dec 23 09:59:56 <lumag> I don't remember if there were architecture differences between armv4 and armv5te
Dec 23 09:59:57 <ant_work> (tody can't type here...)
Dec 23 10:00:23 <lumag> ant_work, can we time kernel load and 'kexreboot' separately
Dec 23 10:00:24 <ant_work> it cannot take so long to load 1-2 mb to ram...
Dec 23 10:00:25 <lumag> ?
Dec 23 10:00:34 <ant_work> yes
Dec 23 10:00:40 <ant_work> kexec -l  -> load
Dec 23 10:00:50 <ant_work> kexec -e -> execute
Dec 23 10:01:12 <ant_work> I think it's the first part
Dec 23 10:01:34 <ant_work>  -e just passes control to the new kernel
Dec 23 10:01:43 <lumag> It'd be nice if you can include any prints into that part of script.
Dec 23 10:02:04 <ant_work> ah, it's kexec-tools utility
Dec 23 10:02:22 <ant_work> in shell we have the standard one
Dec 23 10:02:36 <ant_work> I'll see if we can increase debug
Dec 23 10:13:27 <lumag> thx
Dec 23 10:13:37 <lumag> I've send you patches, btw.
Dec 23 10:27:00 <lumag> gtg now.
Dec 23 10:30:56 <ant_work> thx, bbl
Dec 23 22:01:37 <lumag_> ant__, ge
Dec 23 22:04:02 <ant__> hi
Dec 23 22:04:15 <ant__> I'm testing now the patches
Dec 23 22:04:47 <lumag_> OMG, Isn't it a Christmas Eve in Europe?
Dec 23 22:04:55 <ant__> tomorrow
Dec 23 22:05:29 <lumag_> Ah. Calendar is tricking me. It shows 24th already.
Dec 23 22:05:49 <lumag_> If they work, I'll send you a version with tiny updates.
Dec 23 22:07:17 <lumag_> Regarding resumes: it's funny. My locomo patches somehow trigger the 'remote controller / headphone plugin' pin/irq.
Dec 23 22:07:39 <lumag_> It was listed as a wakeup source (not that we support headphones and/or RC).
Dec 23 22:07:47 <ant__> heh
Dec 23 22:09:07 <ant__> yes, suspend-resume is ok
Dec 23 22:09:54 <ant__> reboot does reboot
Dec 23 22:09:59 <lumag_> great.
Dec 23 22:11:12 <ant__> halt does 'power down' and on/off wakes
Dec 23 22:11:29 <lumag_> So... we have everything fixed?
Dec 23 22:11:36 <ant__> mom
Dec 23 22:12:04 <lumag_> I've send you an updated sus/res patchset. It should fix a possible backtrace on resume in some cases.
Dec 23 22:12:35 <ant__> poweroff is ok as well (you never know...)
Dec 23 22:12:43 <ant__> grat work Dmitry!
Dec 23 22:14:16 <ant__> now thinking..we might have a strange wake-up source on poodle?
Dec 23 22:14:37 <lumag_> Do you mean on poweroff?
Dec 23 22:14:40 <ant__> yes
Dec 23 22:14:55 <lumag_> I'll have to check, but most probably not.
Dec 23 22:15:05 <lumag_> Does suspend/resume work for poodle as expected?
Dec 23 22:15:08 <ant__> not on suspend, only on sleep
Dec 23 22:15:12 <lumag_> Yep.
Dec 23 22:15:12 <ant__> yes
Dec 23 22:16:26 <ant__> now I'll do some kexec test
Dec 23 22:16:33 <ant__> on collie
Dec 23 22:17:14 <lumag_> no. poodle does just 'reset' on power_off
Dec 23 22:17:38 <ant__> ah, that is wrong then
Dec 23 22:27:32 <ant__> hmm
Dec 23 22:27:35 <ant__> root@collie:~# kexec -l /boot/zImage-3.18.0-yocto-standard
Dec 23 22:27:35 <ant__> unrecoverable error: could not scan "/proc/device-tree/": No such file or directory
Dec 23 22:28:58 <lumag_> Did somebody implement dts in not-so-correct way ??
Dec 23 22:29:04 <lumag_> in kexecboot
Dec 23 22:29:10 <lumag_> (or in kexec)
Dec 23 22:29:32 <ant__> kexec-tools 2.0.8 released 23 December 2014
Dec 23 22:29:45 <ant__> now testing old good 2.0.2 -klibc
Dec 23 22:30:09 <lumag_> ant__, I can think of implementing a poweroff for poodle. It should call suspend with cooked 'resume' function that will re-suspend if 'on' key is not pressed.
Dec 23 22:30:36 <lumag_> Heh. gpio-keys configuration is not present for poodle.
Dec 23 22:33:07 <ant__> root@collie:~# time kexec -l /boot/zImage-3.18.0-yocto-standard
Dec 23 22:33:07 <ant__> real	0m 0.90s
Dec 23 22:33:07 <ant__> user	0m 0.02s
Dec 23 22:33:07 <ant__> sys	0m 0.77s
Dec 23 22:33:07 <ant__> root@collie:~#
Dec 23 22:33:09 <ant__> fwiw
Dec 23 22:33:32 <lumag_> So load is fast.
Dec 23 22:33:39 <ant__> and kexec -e is also immediate
Dec 23 22:33:48 <ant__> it is on uncompressing linux....
Dec 23 22:34:12 <ant__> but on kexecboot was apperently before
Dec 23 22:37:14 <ant__> no, it the decompression
Dec 23 22:37:17 <ant__> indeed
Dec 23 22:38:11 <lumag_> Most probably it's a decompression with disabled caches.
Dec 23 22:38:22 <ant__> right
Dec 23 22:38:23 <lumag_> or misconfigured.
Dec 23 22:38:58 <ant__> if you remember there was some change and we got to remap phys to virt for sharpsl_param
Dec 23 22:39:08 <ant__> because the mmu was off iirc
Dec 23 22:40:42 <ant__> about collie battery, there were strange readings iirc (over the max)
Dec 23 22:40:44 <lumag_> yes, but that was another story.
Dec 23 22:40:56 * lumag_ is sorry.
Dec 23 22:41:04 <ant__> did the old patch add anything new?
Dec 23 22:41:09 <lumag_> I still did not have time to check battery readings.
Dec 23 22:46:34 <lumag_> Not for the battery. It makes it work with LCD turned off (usefull), adds hackish charge-in-suspend mode (by suspending if AC plugin/out or battery full was the cause of the wakeup event).
Dec 23 22:47:01 <lumag_> ucb1x00 is the mess.
Dec 23 22:47:11 <lumag_> It hangs/oopses on just evdev  scanning.
Dec 23 22:52:03 <lumag_> too many items in todo list.
Dec 23 22:52:47 <ant__> well, having power management is a big leap forward for collie
Dec 23 22:53:03 <ant__> touchscreen is next...
Dec 23 22:53:08 <ant__> ;)
Dec 23 22:55:02 <lumag_> No. My big next items are locomo driver (mainlining), gpio/irq cleanup (mainlining) and udc driver (at least checking that it works and updating to the contemporary kernels/usbphy framework)
Dec 23 22:56:55 <ant__> ok, talking from user perspective here, opie-image for poodle is ok (just missing poweroff)
Dec 23 22:57:04 <ant__> collie lacks ts urgently
Dec 23 22:57:16 <ant__> UDC comes later
Dec 23 22:57:31 <ant__> but yes, before try to upstream locomo rework
Dec 23 22:57:41 <lumag_> After that collie sound (development, fun), pxa dma rework (testing/measuring/debugging, not so fun), pxa cleanup (throwing code, fun), checking tosa for issues (debugging, not so fun) and looking onto DRM drivers implementation (strange code, not fun at all ATM).
Dec 23 22:57:57 <ant__> ah..sound...
Dec 23 22:58:02 <lumag_> ant__, so there are issues with ts?
Dec 23 22:58:20 <ant__> yes, cannot calibrate
Dec 23 22:58:26 <lumag_> hmm.
Dec 23 22:58:32 <ant__> gives invalid values
Dec 23 22:58:37 <lumag_> as I said, ucb1x00 is a mess.
Dec 23 22:58:39 <ant__> I shoukd have some log
Dec 23 23:01:45 <ant__> rebooting now patches v2
Dec 23 23:03:18 <ant__> ok, works like before
Dec 23 23:04:52 <ant__> tested susp/res, reboot, poweroff
Dec 23 23:05:04 <ant__> very nice
Dec 23 23:05:34 <ant__> hm.. in poweroff it doesn't recharge
Dec 23 23:06:02 <lumag_> most probably.
Dec 23 23:06:08 <ant__> it does after hw reset
Dec 23 23:06:14 <ant__> orange-led
Dec 23 23:06:20 <lumag_> It should keep the last status.
Dec 23 23:06:28 <lumag_> There is fun with bootloader.
Dec 23 23:07:08 <lumag_> ant__, that's strange. My unit boots after hardware reset.
Dec 23 23:07:18 <ant__> mine as well
Dec 23 23:08:32 <ant__> as you say, it seems keeping the last state when poweroff was executed
Dec 23 23:08:36 <lumag_> straight after hw reset.
Dec 23 23:08:39 <lumag_> yep.
Dec 23 23:08:45 <ant__> now it is sleeping and the orange led is lit
Dec 23 23:08:47 <ant__> doh
Dec 23 23:11:04 <ant__> ah..remember the locomokbd is unusable, remove the debug
Dec 23 23:11:06 <lumag_> There is nobody to control charging during poweroff.
Dec 23 23:11:14 <lumag_> ant__, yes, I remember.
Dec 23 23:11:42 <lumag_> it should wakeup when battery gets full, but that's all.
Dec 23 23:11:47 <lumag_> Hmm.
Dec 23 23:12:02 <lumag_> And most probably it won't wake when powered off. Only when suspended.
Dec 23 23:12:14 <ant__> it's always been like that: after pressing reset the device boots
Dec 23 23:12:30 <ant__> after flashing Sharp Rom reset is needed as well
Dec 23 23:13:08 <lumag_> yes.
Dec 23 23:13:15 <ant__> only if there is a BAT_LOW or such event the sa1100 stay suspended iirc
Dec 23 23:44:27 <lumag_> gn
**** ENDING LOGGING AT Wed Dec 24 02:59:59 2014