**** BEGIN LOGGING AT Tue Nov 26 02:59:58 2013
Nov 26 03:00:41 <DocScrutinizer05> check 8080 RETI opcode
Nov 26 03:01:54 <DocScrutinizer05> since IRQ can (and usually should) be level triggered, each CPU has some means to avoid the same or other IRQ kicking in while the CPU is already executing the IRQ handler
Nov 26 03:03:07 <DocScrutinizer05> so usually the IRQ (or all IRQs) get masked when triggering, and you need to unmask it or re-enable IRQs at large, on eiting the irq-handler
Nov 26 03:03:38 <DocScrutinizer05> s/eit/ent/
Nov 26 03:03:40 <apt> DocScrutinizer05 meant: so usually the IRQ (or all IRQs) get masked when triggering, and you need to unmask it or re-enable IRQs at large, on enting the irq-handler
Nov 26 03:03:53 <DocScrutinizer05> s/eit/exit/
Nov 26 03:03:53 <apt> DocScrutinizer05 meant: so usually the IRQ (or all IRQs) get masked when triggering, and you need to unmask it or re-enable IRQs at large, on exiting the irq-handler
Nov 26 03:04:13 <fling> How to get all the data from a simcard using gta04? I want to export contacts and messages for backup purposes.
Nov 26 03:04:19 <fling> In a textfile.
Nov 26 03:04:26 <DocScrutinizer05> RETI for example dos this implicitly
Nov 26 03:04:59 <DocScrutinizer05> fling: check Option601 AT command set reference manual
Nov 26 03:05:19 <DocScrutinizer05> it probably pretty simple
Nov 26 03:06:17 <fling> DocScrutinizer05: thanks.
Nov 26 03:07:35 <DocScrutinizer05> I don't know the exact command, but sending sth similar to AT+cgmr=1,0,200 to the modem should result in the modem spitting all contacts on the SIM as response
Nov 26 03:08:21 <DocScrutinizer05> though I think in SHR phonebook/contacts this function been already integrated
Nov 26 03:08:27 <DocScrutinizer05> some 4 years ago
Nov 26 03:09:04 <fling> DocScrutinizer05: so I just run minicom on my gta04 right?
Nov 26 03:09:11 <DocScrutinizer05> right
Nov 26 03:09:27 <fling> will it also show me deleted messages and contacts?
Nov 26 03:09:47 <DocScrutinizer05> nah, deleted contacts on SIM are lost afaik
Nov 26 03:09:57 <DocScrutinizer05> as well as deleted SMS
Nov 26 03:12:28 <fling> but pySimReader shows them
Nov 26 03:12:36 <DocScrutinizer05> btw instead of minicom or SHR contacts you also could use kandy or gnokii
Nov 26 03:12:50 <fling> it is crashing with cyrillic ones so I have a problem hmm hmmm
Nov 26 03:13:13 <DocScrutinizer05> hehe, sounds strangely familiar
Nov 26 03:13:35 <fling> install gnokii onto gta04?
Nov 26 03:13:53 <DocScrutinizer05> ask a python crack how to teach python to deal with UTF-8
Nov 26 03:14:55 <DocScrutinizer05> well, either install gnokii on gta04 or install it on your PC and access the /dev/ttyACM or whatever the modem is called on GTA04 via some forwarding
Nov 26 03:16:37 <fling> ok :>
Nov 26 03:17:18 <DocScrutinizer05> the modem behaves on GTA04 local tty pretty much like a USB stick modem on your PC
Nov 26 03:17:55 <DocScrutinizer05> actually it *is+ attached to CPU via USB
Nov 26 03:19:18 <fling> I know…
Nov 26 03:19:26 <fling> 1~
Nov 26 03:20:50 <DocScrutinizer05> yeah, you do. sure. you got a gta04
Nov 26 04:50:18 <PaulFertser> DocScrutinizer05: ok, so the way I see it:
Nov 26 04:50:31 <DocScrutinizer05> :-)
Nov 26 04:50:38 <PaulFertser> DocScrutinizer05: pcf50633 decides it needs attention and pulls the IRQ line low.
Nov 26 04:50:56 <DocScrutinizer05> yep
Nov 26 04:53:56 <PaulFertser> DocScrutinizer05: then the external interrupt module in s3c detects level change (it can also do rising and/or falling edge detection) and sets a bit in EXTPEND. If the corresponding bit in EXTMASK is 0 (the particular line is unmasked) then it pulls an internal IRQ line inside SoC (line "5"). The SoC sees it's not masked and latches a bit in SRCPND register. If no more important handler is running, it enter exception handling mode and ...
Nov 26 04:54:02 <PaulFertser> ... sets the corresponding bit in INTPEND. No goes the software processing:
Nov 26 04:55:53 <PaulFertser> DocScrutinizer05: the generic exception handler sees it's an interrupt corresponding to the external controller level type. It calls the corresponding handler which processes all the currently EXTPENDing IRQs that are not masked. If at least one handler is called, it clears not only its EXTPEND bit but also SRCPND and INTPEND bits. After leaving the IRQ handler the SoC sees that no more SRCPND bits are set and proceeds running as usual. 
Nov 26 04:57:19 <PaulFertser> Now what I observed is that the device was continiously reentering External interrupt handler without any way to stop this, that's why: all the external interrupts were masked but SRCPND bit is set.
Nov 26 04:57:42 <DocScrutinizer05> you missing the most important bit: talking to PCF50633 and asking why it asked for attention
Nov 26 04:57:46 <PaulFertser> Since no handler can be called (no external interrupt is available) the SoC was reententering the exception handler again and again.
Nov 26 04:58:23 <DocScrutinizer05> and resetiing the IRQ line so it's not pulled low anymore
Nov 26 04:58:25 <PaulFertser> But its interrupt is masked at that time, it should just wait there until the kernel fully resumes and interrogates it.
Nov 26 05:00:03 <DocScrutinizer05> did you mask the IRQ before you suspend?
Nov 26 05:01:16 <PaulFertser> I guess what can lead to this situation is: some more important interrupt handler is running or all the interrupts are disabled, then pcf50633 requires attention, SRCPND bit is set. But then the currently running code decides to mask this external interrupt (and probably suspend after that). It masks the interrupt, suspends, and on resume we see the extint handler activated without anything to do.
Nov 26 05:03:42 <PaulFertser> It doesn't make sense debugging this on 2.6.39.4 anyway afaict. This kernel is old and interrupt handling predates current proper framework, iirc gta02 received another implementation since then.
Nov 26 05:04:01 <PaulFertser> I just need a working phone and by avoiding this interrupt storm it seems like I get it all right.
Nov 26 05:04:59 <PaulFertser> It's a sane thing to do regardless: if you're called you _must_ ack the interrupt, it makes little sense to leave the irq handler without doing it, as it will be inevitable called right again.
Nov 26 05:38:47 <DocScrutinizer05> irq handler generally polls all possible IRQ sources, irrespective of whether the IRQ is masked or whatever. Any peripheral that could assert that line to GPIO which triggered the IRQ needs to get asked if it asserted an IRQ and same time it will release the IRQ line when it asserted it
Nov 26 05:42:12 <DocScrutinizer05> ideally after that you have collected one or more IRQ sources/causes and reset one or more IRQ bits set in one or more peripheral chips, when you exit from IRQ handler. 
Nov 26 05:46:19 <DocScrutinizer05> you usually should have a root IRQ handler that is assigned to that one GPIO, and you can register an arbitrary number of generic handler routines to that GPIO-specific root-handler. Each of those generic handlers will get executed and talks to their peripheral to ask if it actually asserted the IRQ line, and for what reason (often peripherals have more than just one IRQ source, yet the peripheral has only one IRQ line which it 
Nov 26 05:46:23 <DocScrutinizer05> may even share with other peripherals)
Nov 26 05:47:17 <DocScrutinizer05> obviously you have only one generic handler per peripheral chip registered with the handler-root
Nov 26 05:50:06 <DocScrutinizer05> for wolfson codec the situation been a tad nasty since the chip isn't wired up to the SoC in a way so you could read out registers from it, so you need to determine which cause triggered the IRQ by reseting one bit of IRQ register at a time and check if the IRQ line dropped - this will work as long as no two causes fired concurrently
Nov 26 05:50:55 <DocScrutinizer05> iirc
Nov 26 05:52:17 <DocScrutinizer05> or was this wolfson trick by *masking* one irq source after the other until IRQ line gets disasserted? can't recall the details
Nov 26 05:58:25 <DocScrutinizer05> (ack the interrupt) yes, the handler-root should take care of all IRQ bits (literaly) on SoC, *after* last generic handler returned and thus the external IRQ line probably is de-asserted so resetting the internal flag bits makes sense. then unmask all masked IRQs again and leave the handler-root. NB another peripheral (or even same peripheral) could already have asserted a *new* IRQ. Thus if the external IRQ line/GPIO is (again) 
Nov 26 05:58:25 <DocScrutinizer05> pulled low when handler-root exits, it's absolutely correct to imediately jump into same handler-root again the very moment it exits
Nov 26 06:02:41 <DocScrutinizer05> >>...then unmask all masked IRQs again and leave the handler-root<< to avoid stack to explode from return addr stacked on IRQ handler jumps, every CPU has a means to enable/unmask IRQs only *after* the return-from-subroutine stack-pop happened. Already mentioned: 8080 RETI (iirc). Other CPUs delay the unmask opcode to take effect for one clock cycle, so next command after unmask must be a RETURN
Nov 26 06:04:45 <DocScrutinizer05> usually in any OS the handler-root already got implemented in a CPU-specific way, and all you need to take care about is your generic handler for your particular peripheral
Nov 26 06:07:26 <DocScrutinizer05> and suspend-to-ram must disable all IRQ but enable the wake-events on same GPIO, so the CPU wakes up again when a peripheral asserts the esternal IRQ line, but it will NOT immediately jump into the handler-root but rather first restore all regulators and clockrate and I2C-IP config registers or whatnot else needed. Only *after* all that got done you enable the IRQs again
Nov 26 06:16:20 <PaulFertser> DocScrutinizer05: but if we masked IRQ that means we do not want to handle it right now, and probably can't, so the main irq handler rightfully decides to not call any handlers for irqs that are currently masked.
Nov 26 06:17:19 <DocScrutinizer05> the main irq handler can't get called when IRQs are masked. That's the whole pirpose of masking IRQs
Nov 26 06:17:55 <DocScrutinizer05> purpose even
Nov 26 06:19:59 <PaulFertser> DocScrutinizer05: what if we masked irq before actually handling it?
Nov 26 06:20:03 <DocScrutinizer05> usualy the CPU sets the maskbit automatically same time it jumps to the irq-handler vector
Nov 26 06:20:22 <PaulFertser> Yes, but there're several different levels of masking involved.
Nov 26 06:20:43 <PaulFertser> If that exti line is masked it can't cause interrupt _any more_ but it might have lead to SRCPND bit latched beforehand.
Nov 26 06:25:55 <DocScrutinizer05> well, so what?
Nov 26 06:26:19 <DocScrutinizer05> main handler will reset all those bits on exit, no?
Nov 26 06:30:08 <DocScrutinizer05> there's a possible race when you receive an IRQ the very moment your suspend routine masks those IRQ. The main handler will get called and on exit will unmask the IRQs again. So in your suspend code you should mask the IRQs and then check if they are actually (still) masked. If they're not you jump back to masking them again and check again...
Nov 26 06:37:10 <DocScrutinizer05> btw don't miss in my above wall of text that main handler *always* calls *all* generic handlers. The main handler doesn't _decide_ to call a handler or not. It's the generic sub-handlers themselves who check if they actually need to do something. They do this by talking to the peripheral chip they are designed to service
Nov 26 06:38:31 <DocScrutinizer05> when 3 handlers registered for GPIO168-IRQ since three chips share that line, then of course all three get executed whenever an IRQ on GPIO-168 gets triggered
Nov 26 06:40:42 <DocScrutinizer05> so >>main handler deciding not to call any sub-handler<< can't happen at all, since main handler doesn't care about which IRQ is masked or not
Nov 26 06:41:06 <DocScrutinizer05> one main handler for one IRQ line
Nov 26 06:41:47 <DocScrutinizer05> when that line fires, the irq handler gets executed and it calls all sub handlers registered for that GPIO line
Nov 26 06:42:42 <DocScrutinizer05> of course you can stack this several "floors" high
Nov 26 06:43:57 <DocScrutinizer05> probably there are CPUs that don't support one IRQ vector aka jump addr in the IRQ jump addr table for each possible IRQ source on SoC
Nov 26 06:48:31 <DocScrutinizer05> and you can have several IRQ-concentrators that have 8 or 16 or 476 inputs but only one output IRQ line. So this is also a peripheral for you, and you need to talk to the IRQ-conentrator like a it was a peripheral, Then actually this sub-handler decides based on the result of this inquiry which of the sub-sub-handlers to run. The sub-sub-handlers are registering to the concentrator-sub-handler for one of the "GPIO" actually 
Nov 26 06:48:32 <DocScrutinizer05> input lines. 
Nov 26 06:48:50 <DocScrutinizer05> this scheme can nest several levels deep
Nov 26 06:51:30 <DocScrutinizer05> the sub-sub-handler then talks to the peripheral and resets the IRQ line there and finds out what to do for the root IRQ cause
Nov 26 06:54:03 <DocScrutinizer05> the sub-handler, after talking to the conentrators, might have found out that actually an event happened for input2 and one for input7 as well (it also resets the flag bits in concentrator same time it talks to it). So it runs all sub-sub-handlers for #2 and for #7, then resets the IRQ flag one level higer on exit
Nov 26 06:54:40 <DocScrutinizer05> s/resets/resets and unmasks/
Nov 26 06:54:42 <apt> DocScrutinizer05 meant: the sub-handler, after talking to the conentrators, might have found out that actually an event happened for input2 and one for input7 as well (it also resets and unmasks the flag bits in concentrator same time it talks to it). So it runs all sub-sub-hand...
Nov 26 06:56:38 <DocScrutinizer05> one level higher of sub.handler is main handler which ran the sub-handler when itself got executed by IRQ handling of SoC
Nov 26 06:57:08 <DocScrutinizer05> it's maybe a bit nested sometimes, but not really complicated at all
Nov 26 07:13:54 <PaulFertser> DocScrutinizer05: that was indeed the problem. The main handler didn't receive anything if it didn't call any subhandler.
Nov 26 07:14:39 <PaulFertser> didn't clear/ack anything
Nov 26 07:14:49 <DocScrutinizer05> what should main handler "receive"?
Nov 26 07:15:08 <PaulFertser> s/receive/reset/
Nov 26 07:15:11 <PaulFertser> Typo, sorry.
Nov 26 07:15:14 <DocScrutinizer05> main handler gets executed, that's the definition of how interrupts work
Nov 26 07:15:17 <PaulFertser> Yep
Nov 26 07:15:25 <DocScrutinizer05> aaah
Nov 26 07:15:28 <DocScrutinizer05> ok :-)
Nov 26 07:16:00 <PaulFertser> So your description is fully correct.
Nov 26 07:16:18 <PaulFertser> But the main handler didn't clear the pending bits if none of the subhandlers was called.
Nov 26 07:16:31 <DocScrutinizer05> yes, main handler needs to unmask and clear all the irq bits it's responsible for, at very end just before return
Nov 26 07:17:09 <DocScrutinizer05> but I don't see how "none of sub handlers called" can even happen
Nov 26 07:17:58 <DocScrutinizer05> when the irq handler get called/execuzed, then one IRQ must have happened and caused this
Nov 26 07:20:09 <DocScrutinizer05> when it's a single GPIO without any IRQ controller between it then it's straight to directly call all sub-handlers that registered. IF it's a handler for a single IRQ generated by a IRQ-multiplexer/concentrator, then in *that* hardware there must be a flag bit set for all the inputs that seen an event, and the main handler needs to call all sub-handlers that registered for the according concentrator input
Nov 26 07:20:53 <DocScrutinizer05> there can't exist a situation where concentrator output asserts the IRQ line despite none of the inputs seen an event and thus a bit latched for that
Nov 26 07:22:00 <PaulFertser> What if the external irq was masked after the pending bit was set but before the handler got executed?
Nov 26 07:22:24 <DocScrutinizer05> nothing, that's normal
Nov 26 07:23:19 <DocScrutinizer05> many concentrators set the mask bit on same time as the event bit, to evoid multiple triggers when IRQ is edge triggered
Nov 26 07:23:29 <PaulFertser> I mean pending bit in SRCPND, that's actually what I saw myself. SRCPND bit will lead to exception on the nearest possible opprotunity. 
Nov 26 07:23:58 <DocScrutinizer05> anyway the handler gets executed, detects which latch bit signals an event and acts accordingly
Nov 26 07:24:57 <PaulFertser> It can't act because all the signals are masked, so noone can process the actual signal.
Nov 26 07:24:58 <DocScrutinizer05> well, SRCPND set must have a reason, and that reason can't vanish. I don't see the problem
Nov 26 07:25:12 <PaulFertser> The reason can't vanish of course, but it's not possible to process it at that time.
Nov 26 07:25:24 <DocScrutinizer05> why?
Nov 26 07:25:31 <PaulFertser> I2C not initialised e.g.
Nov 26 07:25:40 <DocScrutinizer05> well, that's too bad
Nov 26 07:25:44 <PaulFertser> I agree what I saw was abnormal.
Nov 26 07:25:53 <PaulFertser> But the fix makes sense regardless of the cause.
Nov 26 07:26:17 <DocScrutinizer05> told you to first disable/mask bits in your suspend code, only *then* power down I2C etc
Nov 26 07:26:45 <DocScrutinizer05> and *first* power up and initialize I2C, only *then* unmask IRQs
Nov 26 07:27:36 <PaulFertser> Yes, but I'm not the one who wrote the suspend code.
Nov 26 07:27:58 <DocScrutinizer05> don't expect you can fix it in inerrupt handler
Nov 26 07:28:41 <DocScrutinizer05> you MUST mask all IRQs before you power dow busses
Nov 26 07:29:31 <DocScrutinizer05> when your IRQ handler doesn't react accordingly on suspend-notification, then probably something is flawed
Nov 26 07:29:37 <PaulFertser> With the fix I have now, yes, I might miss that interrupt that made SRCPND latch, I agree. Still way better than having my cellphone stuck on resume (especially when someone calls, it tries to resume but instead stucks eating battery in several hours, once I notice it needs reboot, the battery is flat).
Nov 26 07:30:26 <DocScrutinizer05> and losing an IRQ may be fatal
Nov 26 07:30:34 <PaulFertser> But digging deeper in this 2.6.39.4 SHR version makes little sense, IMHO. The interrupt handling for gta02 changed considerably since then.
Nov 26 07:31:39 <PaulFertser> I do not think loosing any of our EXTI interrupts can be fatal.
Nov 26 07:32:15 <DocScrutinizer05> I fail to see how you get into this situation anyway
Nov 26 07:33:05 <PaulFertser> Me too
Nov 26 07:33:43 <PaulFertser> But it was steadily reproducible with dmesg -n7 probably 3% rate, with -n4 probably .5%.
Nov 26 07:35:16 <DocScrutinizer05> sounds like a race condition
Nov 26 07:37:50 <PaulFertser> That's what I suspect as well.
Nov 26 07:38:23 <DocScrutinizer05> [2013-11-26 03:49:19] <DocScrutinizer05> PaulFertser: take care your patch is not only introducing a duct tape fix based on changes in timing of a race condition ;-)
Nov 26 07:42:41 <DocScrutinizer05> e.g. when you got a level-low IRQ on a GPIO that's connected to any peripheral that#s going to get suspended, then you should mask or even deregister the IRQ for that peripheral before you shut down VDD-IO
Nov 26 07:43:38 <DocScrutinizer05> and on resume you must enable VDD-IO before you register/enable/unmask the IRQ again
Nov 26 07:43:57 <DocScrutinizer05> quite a few milliseconds before
Nov 26 07:45:57 <PaulFertser> DocScrutinizer05: but I do not see why I should take care about this because this kernel is too old to spend time on anyway, IMHO.
Nov 26 07:46:05 <DocScrutinizer05> and IRQs shuld get switched on at the "leafs" (sub-sub-sub... level) last, and disabled first
Nov 26 07:46:33 <PaulFertser> We have ar6000 driver which is just a pile of crap, way worse than any irq code we have. And I'm not inclined rewriting it.
Nov 26 07:46:35 <DocScrutinizer05> well, then get a newer kernel, no?
Nov 26 07:47:14 <DocScrutinizer05> I don't get it what's the goal
Nov 26 07:47:31 <PaulFertser> I seem to remember newer kernels have some other problem.
Nov 26 07:47:50 <PaulFertser> My goal is just to use my cellphone, I have difficulties living without one, and gta02 is the only I can use.
Nov 26 07:47:53 <DocScrutinizer05> make old kernel work? then do it right, and save much time on hunting nasty bugs at wrong end. 
Nov 26 07:48:12 <PaulFertser> And this resume issue is something everyone knew but noone cared about. 
Nov 26 07:48:16 <DocScrutinizer05> or get a new kernel? then why do you mess with the old one?
Nov 26 07:48:34 <PaulFertser> I think newer proper kernels have some other issues, but I might be misremembering.
Nov 26 07:48:57 <PaulFertser> radekp_: hey, what's the reason you ship 2.6.39 and not 3.4 (or something newer) for gta02?
Nov 26 07:50:16 <PaulFertser> I think this one workaround will allow me to use 2.6.39 without hunting any other bugs, as it would be tolerable if resume becomes stable enough.
Nov 26 07:59:17 <radekp_> PaulFertser: hi, i have never tried anything higher then 2.6.39 on Freerunner
Nov 26 07:59:52 <PaulFertser> radekp_: is there anything going on in kernel land for gta02? What's the status, and why's everybody using 2.6.39?
Nov 26 07:59:53 <radekp_> PaulFertser: QtMoko now uses 2.6.34 which is fairly stable - but i have seen it not waking from suspend too
Nov 26 08:00:23 <PaulFertser> radekp_: have you tried to experiment with rtcwake to determine the failure rate?
Nov 26 08:00:33 <radekp_> PaulFertser: no havent
Nov 26 08:01:07 <PaulFertser> radekp_: this morning my FR went through more than 1000 cycles and was apparently stable with that patch.
Nov 26 08:01:22 <radekp_> PaulFertser: my guess is that it wont survive more then 50 resumes ;-)
Nov 26 08:01:48 <radekp_> PaulFertser: hmm i could try to apply it on 2.6.34 and try too
Nov 26 08:02:43 <PaulFertser> radekp_: yes, but since you haven't tried reproducing it you won't feel the difference probably.
Nov 26 08:03:40 <radekp_> i can try reproduce - no problem except that i am now too busy at moneywork - but i can do on xmas
Nov 26 11:09:59 <PaulFertser> JaMa: btw, what do you know about running non-ancient kernels on gta02?
Nov 26 13:45:47 <radekp_> PaulFertser: you are using SHR kernel now?  this one git@gitorious.org:shr/linux.git ?
Nov 26 13:46:31 <radekp> PaulFertser: i mean this one https://gitorious.org/shr/linux/commits/e63c60958791fe5091aed53a7745f4aab6e2e55a
Nov 26 13:47:27 <JaMa> PaulFertser: I'm using 3.2 there and gnutoo created branches even up-to 3.5 or something
Nov 26 14:55:12 <PaulFertser> radekp: yes, exactly.
Nov 26 14:55:21 <PaulFertser> JaMa: but does it work decently for everyday needs?
Nov 26 14:56:41 <JaMa> PaulFertser: works for my needs, but I don't use gta02 much anymore, so I wouldn't recommend it for everyday phone
Nov 26 14:57:12 <PaulFertser> JaMa: btw, is there any alternative for FSO now?
Nov 26 14:57:37 <JaMa> see alisa's last comment in http://trac.shr-project.org/trac/ticket/2100
Nov 26 14:58:08 <JaMa> PaulFertser: I don't know about better alternative
Nov 26 14:58:31 <PaulFertser> I feel abandoned by fso devs :(
Nov 26 14:58:39 <PaulFertser> No kidding
Nov 26 15:03:28 <DocScrutinizer05> hmm, prolly there been only one FSO dev
Nov 26 15:03:40 <DocScrutinizer05> busy with kid now
Nov 26 15:08:51 <PaulFertser> There were 3 people actively contributing to FSO afair
Nov 26 15:10:24 <TAsn> kids are the devil.
Nov 26 15:10:56 <TAsn> https://www.youtube.com/watch?v=LyhapayOx44
Nov 26 15:15:22 <PaulFertser> 4123 suspend/resume cycles, cool
Nov 26 15:15:46 <PaulFertser> I even had to learn some Vala to help with FSO, heh.
Nov 26 15:29:39 <PaulFertser> Boy, do I miss those days when everyone was enthusiastic and passionate about some direction, there was plenty of arguing and obstacles but there also was drive, fun, energy, the project was fast-evolving...
Nov 26 15:30:07 <PaulFertser> Where's raster and his elementary now? Showing widgets on samsung's freezers? TAsn?
Nov 26 15:30:22 <PaulFertser> Where's mickey, doing iphone/ipad development?
Nov 26 15:31:20 <TAsn> well
Nov 26 15:31:20 <PaulFertser> All the fine folks I've met here drifted away from the only free smartphone in mass production.
Nov 26 15:31:27 <TAsn> raster and I are working on samsung phones
Nov 26 15:31:38 <TAsn> (and freezers ;P) 
Nov 26 15:31:56 <PaulFertser> I feel like a dinosaur with my gta02, somehow others managed to find something better and I didn't.
Nov 26 15:31:57 <TAsn> but yeah
Nov 26 15:31:59 <TAsn> sad
Nov 26 15:32:22 <TAsn> PaulFertser, well, android is better for a very specific definition of better
Nov 26 15:32:28 <TAsn> and horrible for everything but hat definition
Nov 26 15:32:29 <TAsn> that*
Nov 26 15:32:30 <PaulFertser> raster talked a lot about how cool samsung phones will be. Not that he ever showed anything.
Nov 26 15:32:43 <TAsn> I gotta get raster's back here
Nov 26 15:32:45 <TAsn> it's not his fault
Nov 26 15:32:58 <TAsn> they were cool at some point
Nov 26 15:33:05 <TAsn> you can track progress at tizen.org
Nov 26 15:33:10 <TAsn> maybe less cool now
Nov 26 15:33:14 <PaulFertser> What's funny is that QtMobile is still alive and kicking, thanks to the hard and awesome work of radekp.
Nov 26 15:33:56 <TAsn> :|
Nov 26 15:35:12 <PaulFertser> Elementary cloud-castles, Cornucopia architecture work, etc etc all blown away by "progress" (which is of course a real regress from an engineering PoV regarding software design and quality and ecosystem)
Nov 26 15:37:05 <PaulFertser> neo900 gives a new hope, that's encouraging, i've always underestimated maemo community but luckily DocScrutinizer05 haven't.
Nov 26 15:37:43 <DocScrutinizer05> heh, I'm the community ambassador
Nov 26 15:37:46 <DocScrutinizer05> ;-)
Nov 26 15:42:03 <DocScrutinizer05> but actually I'm concerned about devel manpower available and willing to port fremantle to new hw platform
Nov 26 15:43:57 <PaulFertser> I think now Nicolas can afford contracting one or two devs for a while if the progress slows down too much.
Nov 26 15:46:40 <DocScrutinizer05> Nikolaus?
Nov 26 15:46:44 <DocScrutinizer05> nope
Nov 26 15:48:05 <DocScrutinizer05> you might think we had great success and lots of money now, according to neo900.org/#donate, but that's a misconception since all that are rebates that are "refundable" once we deliver devices
Nov 26 15:49:53 <PaulFertser> Yes, but I hope you have some reasonable price margin to allow for proper development funding even if it gets a bit tougher than first anticipated.
Nov 26 15:51:39 <DocScrutinizer05> well, the price margin is not determined yet since the sales price is not fixed, but when we earn a 50 bucks per device then that's already much
Nov 26 15:52:05 <DocScrutinizer05> sw development isn't priced in to the calculation of this project
Nov 26 15:53:15 <PaulFertser> I understand. The device seems to be promising enough to attract some smart heads.
Nov 26 15:54:43 <DocScrutinizer05> yeah, but I'd have hoped for more than the maybe 2 or 3 guys actively contributng to porting fremantle to neo900
Nov 26 15:55:51 <DocScrutinizer05> and tbh I don't see future for the "standard" distros which still pretend embedded was a small x86 PC and don't even ponder if going out of line of 100% upstream was anything reasonable to do when needed
Nov 26 15:57:00 <DocScrutinizer05> even GTA04 still pursues that insane suspend-to-ram idea instead of doing proper PM and zeroclock, based on SmartReflex which has some support from TI and works just nice in fremantle
Nov 26 15:58:56 <DocScrutinizer05> we'll probably rather see KDE ported to ARM debian than hildon framework getting ported to a decent neo900 specific and optimized system
Nov 26 15:59:01 <PaulFertser> I do not think that depends on the distro?
Nov 26 15:59:26 <DocScrutinizer05> yeah, that's the huge misconception
Nov 26 15:59:31 <PaulFertser> I think cpu clock management should just work, if you do not have any evil apps, it'll do fine job on its own?
Nov 26 15:59:43 <DocScrutinizer05> yes
Nov 26 15:59:51 <PaulFertser> I was trying to monitor what's happening on my tegra2 netbook with plain debian.
Nov 26 16:00:02 <DocScrutinizer05> when you got all the low level and kernel bit in place, it should
Nov 26 16:00:20 <PaulFertser> It scales all the way down, just fine, waiting for the nearest timer tick (which doesn't happen earlier than needed by one of the apps)
Nov 26 16:00:50 <DocScrutinizer05> but fremantle is a complete framework that also has proper middleware and services which are optimized resp tailored to fit for OMAP
Nov 26 16:01:21 <DocScrutinizer05> for an instance see alarmd and timed, instead of cron and systime()
Nov 26 16:03:06 <DocScrutinizer05> refreshing icons/widgets only when visible is another arbitrary example that I'm not convinced is really a major concern in other distros than maemo 
Nov 26 16:04:03 <DocScrutinizer05> there's a lot of special tweaks in whole system (as opposed to kernel with standard system on top) that make maemo fremantle work like it does
Nov 26 16:04:30 <PaulFertser> I think that might be possible to implement in any toolkit without much difficulty, testing would be needed to determine if it's really power-efficient.
Nov 26 16:04:59 <DocScrutinizer05> and not even mer/nemo/sailfish seem to really have a decent clue how to take similar care about all those aspects
Nov 26 16:05:55 <DocScrutinizer05> sure, if all devels would be aware of how to implement it and that it actually *needs* to get implemented, I'd agree that it "only" needs lots of testing
Nov 26 16:08:20 <DocScrutinizer05> for now 3 developers are trying to port and RE fremantle to allow running it on new platforms
Nov 26 16:10:32 <DocScrutinizer05> and those are either students with a uni to visit every now and then, or they have a dayjob and are not available for more than they already do, and I'm trying to guide them and review the architectural aspects and power management and hw interfacing concerns at large
Nov 26 16:11:46 <DocScrutinizer05> freemangordon recently made 3.12 kernel run on N900, and even boot fremantle, but of course not with all services
Nov 26 16:12:06 <DocScrutinizer05> upstream support for OMAP been sparse at best
Nov 26 16:12:39 <DocScrutinizer05> DT been buggy like hell it seems, and so were clock dividers and regulators
Nov 26 16:12:45 <PaulFertser> Oh
Nov 26 16:13:09 <PaulFertser> I thought they should have ironed that out by now for their dev boards.
Nov 26 16:14:39 <DocScrutinizer05> who? which dev board?
Nov 26 16:20:51 <PaulFertser> TI themselves plus community gathered around beagleboards etc.
Nov 26 16:21:41 <DocScrutinizer05> yes, and both N900 and Neo900 are beagleboards with a few essential hw extensions
Nov 26 16:22:22 <DocScrutinizer05> but recent beagleboards are not using OMAP3 anymore
Nov 26 16:22:48 <DocScrutinizer05> and beagleboard doesn't have a camera attached to SoC
Nov 26 16:22:57 <DocScrutinizer05> etc pp
Nov 26 16:23:25 <PaulFertser> Yup
Nov 26 16:25:07 <DocScrutinizer05> and we don't have anybody even working for booting maemo via uBoot for example
Nov 26 16:25:54 <DocScrutinizer05> sure it should "just work2 but as usual the devil is in detail
Nov 26 16:33:16 <PaulFertser> I know of another uncool bug in gta02 kernel that nobody noticed apparently: ar6000 driver reports link up before it's actually up, and so the kernel doesn't get ipv6 address via slaac etc.
Nov 26 16:43:36 <jake42> hi, take a look at http://shr-project.org/trac/ticket/2103
Nov 26 16:44:01 <jake42> maybe someone can try to reproduce this strange bug
Nov 26 16:45:06 <jake42> or has some advice about it
Nov 26 16:46:04 <PaulFertser> jake42: what state the device is actually in? If you say usb networking works, can you tell what happens? Does the backlight get enabled or not? Do you see all-white screen?
Nov 26 16:47:22 <jake42> PaulFertser: console over usbnet works fine
Nov 26 16:48:19 <jake42> PaulFertser: backlight is not enabled as fb_blank (can't remember the name) is set
Nov 26 16:48:24 <PaulFertser> jake42: btw, i'm using 2.6.39.4 and apart from the resume bug it worked ok.
Nov 26 16:48:41 <PaulFertser> jake42: but you can try manually unblanking via sysfs, what does that give?
Nov 26 16:49:22 <jake42> PaulFertser: did that some time ago
Nov 26 16:50:03 <jake42> it wasn't X what I saw, but I'd have to recheck
Nov 26 16:50:40 <jake42> It looks too me like it is not properly suspending (or not coming back from it)
Nov 26 16:50:59 <jake42> only message about suspend is file system sync
Nov 26 16:51:33 <jake42> question would be if someone with a gta02 and the same image can reproduce it or if it is some hw-failure
Nov 26 16:51:47 <jake42> as it never happens without the frontcover
Nov 26 16:51:54 <jake42> which is really strange
Nov 26 16:54:47 <PaulFertser> jake42: i'm using upstream Debian here. Have partially fixed that resume issue just yesterday on 2.6.39.4, at least it doesn't render device unusable now (and has no obvious ill effects).
Nov 26 16:56:01 <jake42> PaulFertser: yes, I'd test your fix in everyday usage, but I got the mentioned issue which is no joy in that regard
Nov 26 16:56:13 <PaulFertser> Is smartphones-userland list dead unavailable now?
Nov 26 16:56:39 <jake42> gotta run
Nov 26 16:56:42 <PaulFertser> jake42: have you noticed any difference in the bootlog between the case with and without cover?
Nov 26 16:56:52 <PaulFertser> jake42: see you
Nov 26 16:57:22 <jake42> PaulFertser: I'll try that
Nov 26 17:29:44 <DocScrutinizer05> hi jake42
Nov 26 17:42:56 <lindi-> PaulFertser: possible solution to what? please send email, I'm not following irc actively at the moment
Nov 26 17:46:56 <PaulFertser> lindi-: I've sent one to the kernel mailing list, a solution to 2.6.39 inability to resume sometimes.
Nov 26 17:47:10 <lindi-> PaulFertser: ok
Nov 26 17:47:14 <PaulFertser> gena2x: having jtag access just rocks for this kinds of issues, I like debugging interactively.
Nov 26 17:47:22 <PaulFertser> lindi-: great thanks again for the board
Nov 26 17:50:58 <JaMa> PaulFertser: wrt FSO devs, Simon is very busy with webOS-ports
Nov 26 17:53:35 <PaulFertser> JaMa: I know but I also know webos sucks and gives about nothing good to a free software enthusiast/hacker. Probably I'm wrong here but so far it looked like that.
Nov 26 17:54:36 <PaulFertser> JaMa: also, I'm still using fsogsmd, and he's not. If he was, I'd be able to understand it.
Nov 26 17:59:56 <JaMa> true for both
Nov 26 18:05:10 <PaulFertser> JaMa: I understand you're involved too and I'm not feeling like downplaying your or Simon's work. But my personal feeling about all this is distasteful. Ubuntu "touch" utilizing android telephony and driver, then webos following, sigh, that's really too far away from what we do have here on gta02 and gta04. Better than android of course but meh.
Nov 26 18:07:09 <PaulFertser> Also, I dislike modern web so much that the very idea of using "web technologies" for "smartphone development" seems to me like a sick one. I understand webos is not just about that, and having native qt apps is nice. But if Qt 5.0 fully supports android without webos, what would be the difference then?
Nov 26 18:12:07 <JaMa> What's worse is that I agree with you even when I'm involved with this "bloating"
Nov 26 18:13:17 <PaulFertser> I sincerely hope you're having fun nevertheless.
Nov 26 18:13:37 <JaMa> All I need from phone are 2 big buttons to accept and end phone call and possibility to open fullscreen terminal and type on preferrably hw keyboard (so that I have whole screen for terminal and can type without many typos)
Nov 26 18:15:08 <JaMa> I'm using n900 most of the time, because it's the only phone I have with hw keyboard and I don't care that it's slower than GNexus, because it's fast enough for terminal, I would even more stripped UI for that
Nov 26 18:15:59 <JaMa> I got involved with webos mostly because it looked like ready-to-use UI suitable for "average end-users" when our own SHR UI was dying from lack of developers
Nov 26 18:17:07 <JaMa> but in the end it's wasn't ready-to-use, easy-to-build for multiple MACHINEs, easy to port over FSO etc
Nov 26 18:17:52 <JaMa> so biggest benefit from this whole webos adventure for me was new dayjob which I like, but the hobbist in me suffers greatly from it
Nov 26 18:18:14 <JaMa> and lack of time to do more fun stuff in free time
Nov 26 18:27:55 <PaulFertser> Q-Master: hey
Nov 26 18:28:02 <Q-Master> howdy
Nov 26 18:32:11 <PaulFertser> Q-Master: how're you doing? Still using gta02?
Nov 26 18:39:40 <Q-Master> PaulFertser: rather good, thnx. Almost not using it at all. No time for it now. Too busy, and a kid is growing up/
Nov 26 18:46:04 <PaulFertser> Q-Master: what do you use instead then?
Nov 26 18:46:58 <Q-Master> PaulFertser: xperia z ultra 8)
Nov 26 18:49:22 <jake42> DocScrutinizer05: hi
Nov 26 21:44:19 <jake42> PaulFertser: after "unblanking" (http://paste.debian.net/67918/) there are some old kernel messages visible and a blinking curser
Nov 27 02:18:35 <pabs3> PaulFertser: looks like there was some hardware issues: LinuxToGo.org is currently under maintenance...
**** ENDING LOGGING AT Wed Nov 27 03:00:00 2013