**** BEGIN LOGGING AT Sat Jan 28 03:00:00 2012
Jan 28 06:54:04 <CIA-65> freesmartphone.org: 03morphis 07cornucopia * r150a8835cb4f 10/fsodeviced/src/plugins/kernel26_rfkill/ (Makefile.am plugin.vala): 
Jan 28 06:54:04 <CIA-65> freesmartphone.org: fsodeviced: kernel26_rfkill: add missing dependency to libfsosystem
Jan 28 06:54:04 <CIA-65> freesmartphone.org: Signed-off-by: Simon Busch <morphis@gravedo.de>
Jan 28 09:00:41 <CIA-65> SHR: 03morphis 07meta-smartphone * rf47fe8c86558 10/meta-samsung/recipes-graphics/xorg-drivers/xf86-input-mtev_git.bbappend: meta-samsung: xf86-input-mtev: bump SRCREV to get working touchscreen again
Jan 28 13:54:43 <GNUtoo> morphis, hi
Jan 28 13:57:33 <morphis> GNUtoo: heyho
Jan 28 13:57:44 <GNUtoo> libsamsung-ipc fails to compile
Jan 28 13:58:06 <morphis> where? which SRCREV?
Jan 28 13:58:12 <GNUtoo> ipc_util.c:161:9: error: 'IPC_SS_WAITING' undeclared (first use in this function)
Jan 28 13:58:13 <GNUtoo> last one
Jan 28 13:58:17 <GNUtoo> I think I use autorev
Jan 28 13:58:19 <GNUtoo> let me look
Jan 28 13:58:28 <GNUtoo> a6fab223402276cd543830be051ff7ef8bae8b4f
Jan 28 13:58:57 <morphis> tell paulk-desktop he did that change
Jan 28 13:59:04 <GNUtoo> yes I just saw that
Jan 28 13:59:06 <GNUtoo> USSD stuff
Jan 28 13:59:18 <paulk-desktop> I didn't update makefiles
Jan 28 13:59:30 <paulk-desktop> you must also add define DEVICE_IPC_V4
Jan 28 13:59:35 <paulk-desktop> instead of DEVICE_CRESPO
Jan 28 13:59:51 <paulk-desktop> I'm unsure how to update the autoconf/automake files
Jan 28 14:00:08 <paulk-desktop> morphis, can you adjust the makefiles or should I try?
Jan 28 14:00:29 <morphis> I will do
Jan 28 14:00:50 <paulk-desktop> thanks a lot
Jan 28 14:00:54 <paulk-desktop> sorry about that
Jan 28 14:01:05 <paulk-desktop> GNUtoo, ^^^
Jan 28 14:01:24 <morphis> no problem
Jan 28 14:01:27 <GNUtoo> ok thanks
Jan 28 14:01:36 <morphis> GNUtoo: so stick to a older version for now pleae
Jan 28 14:01:41 <GNUtoo> I can't
Jan 28 14:01:44 <GNUtoo> I'll wait
Jan 28 14:01:58 <GNUtoo> I've still no serial on nuttx-bb btw
Jan 28 14:07:45 <morphis> GNUtoo: try latest version
Jan 28 14:07:54 <GNUtoo> ok thanks
Jan 28 14:11:07 <GNUtoo> NOTE: package libsamsung-ipc-0.1.0+gitr13+51ea3aaa63e65b74b7386fe1365d7b52f4495c43-r2: task do_package: Started
Jan 28 14:15:41 <GNUtoo> lol now fsogsmd fails
Jan 28 14:16:40 <GNUtoo> http://www.pastie.org/private/glgvfzoezbcz26kqjyx2wa
Jan 28 14:17:08 <GNUtoo> | /home/gnutoo/embedded/oe/oe-core/oetmps/shr/sysroots/crespo/usr/include/samsung-ipc-1.0/types.h:35:16: fatal error: ss.h: No such file or directory
Jan 28 14:18:34 <paulk-desktop> got it
Jan 28 14:18:35 <DocScrutinizer> moo
Jan 28 14:19:39 <paulk-desktop> GNUtoo, fixed
Jan 28 14:19:46 <paulk-desktop> you'll need to rebuidl libsamsung-ipc
Jan 28 14:19:50 <paulk-desktop> rebuild*
Jan 28 14:19:54 <paulk-desktop> to have the header installed
Jan 28 14:22:50 <GNUtoo> ok
Jan 28 14:23:52 <GNUtoo> thanks
Jan 28 14:44:26 <GNUtoo> fsogsmd failed again:
Jan 28 14:44:30 <GNUtoo> | unsolicited.c:508:8: error: 'IPC_NET_ACCESS_TECHNOLOGY_UNKNOWN' undeclared (first use in this function)
Jan 28 14:59:34 <GNUtoo> wow I've usb on 3.2
Jan 28 14:59:43 <GNUtoo> ah no
Jan 28 14:59:44 <GNUtoo> sorry
Jan 28 14:59:58 <GNUtoo> I don't know why but it corrupted the fs and booted 2.6.39
Jan 28 15:00:06 <GNUtoo> Linux om-gta02 2.6.39.4 #1 Sat Dec 17 20:49:10 CET 2011 armv4tl GNU/Linux
Jan 28 15:01:23 <GNUtoo> ah ok it booted on ubifs
Jan 28 15:06:19 <GNUtoo> Linux om-gta02 3.2.1 #1 Thu Jan 26 17:23:29 CET 2012 armv4tl GNU/Linux
Jan 28 15:06:22 <GNUtoo> worked this time
Jan 28 15:06:35 <GNUtoo> [  252.550000] usb0: no IPv6 routers present
Jan 28 15:06:41 <GNUtoo> by loading it twice
Jan 28 15:09:55 <GNUtoo> hmmm  phoneuid-wrapper uses 100% CPU
Jan 28 15:13:42 <GNUtoo> ah no sound card...
Jan 28 15:14:32 <GNUtoo> lacks lots of modules to be loaded
Jan 28 15:16:11 <GNUtoo> JaMa, mrmoku, mickeyl hi
Jan 28 15:21:11 <GNUtoo> where are everybody?
Jan 28 15:22:57 <GNUtoo> lindi-_, hi
Jan 28 15:23:11 <GNUtoo> on 3.2 I got a trace of your same problem
Jan 28 15:23:25 <GNUtoo> at least if I'm not mistaken
Jan 28 15:24:08 <GNUtoo> http://www.pastie.org/private/zglq9iirdvsdkhjg3710hq
Jan 28 15:24:57 <GNUtoo> [ 1234.625000] [<c0011928>] (gta02_bat_get_voltage+0x18/0x64) from [<c001197c>] (gta02_bat_get_capacity+0x8/0xa0)
Jan 28 15:25:19 <lindi-_> GNUtoo: how did you get the trace?
Jan 28 15:25:28 <GNUtoo> apm -s
Jan 28 15:25:45 <GNUtoo> ant it did the trace automatically
Jan 28 15:25:49 <GNUtoo> *and
Jan 28 15:26:05 <lindi-_> ah, you have some kernel option that detects this
Jan 28 15:26:19 <GNUtoo> no idea
Jan 28 15:26:37 <lindi-_> anyways, I'm trying to understand the second suspend bug
Jan 28 15:26:44 <lindi-_> seems a lot more complex unfortunately
Jan 28 15:26:50 <GNUtoo> it second one?
Jan 28 15:26:58 <GNUtoo> I'm lost with numbers
Jan 28 15:27:03 <GNUtoo> the only 2 I know of are:
Jan 28 15:27:04 <lindi-_> when you fix the gta02_bat_get_capacity you start seeing another type of crash
Jan 28 15:27:07 <GNUtoo> *)alsa suspend bug
Jan 28 15:27:14 <GNUtoo> 2) the battery capacity one
Jan 28 15:27:14 <lindi-_> ok, third then :)
Jan 28 15:27:21 <GNUtoo> ok
Jan 28 15:27:40 <lindi-_> in this one you are stuck in __irq_svc forever
Jan 28 15:27:51 <GNUtoo> ok
Jan 28 15:27:55 <lindi-_> since an interrupt occurs but that interrupt is masked and the code does not think this can ever happen
Jan 28 15:27:58 <lindi-_> so it loops forever
Jan 28 15:28:11 <GNUtoo> ouch
Jan 28 15:28:26 <lindi-_> and this is during resume
Jan 28 15:29:00 <GNUtoo> ok
Jan 28 15:29:01 <lindi-_> http://lindi.iki.fi/lindi/openmoko/crash/2/arm-trace.txt has a trace
Jan 28 15:29:18 <lindi-_> nicely shows how it loops again and again
Jan 28 15:31:13 <GNUtoo> ok
Jan 28 15:31:34 <GNUtoo> what did you use to make the trace?
Jan 28 15:31:42 <GNUtoo> btw did you ever met mickeyl?
Jan 28 15:31:51 <lindi-_> GNUtoo: jtag
Jan 28 15:31:53 <GNUtoo> or do you have a debug board
Jan 28 15:31:55 <GNUtoo> ah ok
Jan 28 15:31:58 <lindi-_> GNUtoo: no, never met mickey
Jan 28 15:32:05 <lindi-_> I have several debug boards :)
Jan 28 15:32:09 <GNUtoo> ok nice
Jan 28 15:32:23 <GNUtoo> (mickeyl has some debug board to give to developers )
Jan 28 15:32:35 <lindi-_> I already gave one debug board to gena2x
Jan 28 15:32:41 <GNUtoo> ok
Jan 28 15:32:57 <GNUtoo> btw I also tried to work on the modem and failed
Jan 28 15:33:02 <GNUtoo> even with 2 serials 
Jan 28 15:33:04 <lindi-_> which modem?
Jan 28 15:33:11 <GNUtoo> calypso
Jan 28 15:33:17 <GNUtoo> I tried to port nuttx-bb to gta02
Jan 28 15:33:24 <GNUtoo> from the compal_e99 port
Jan 28 15:33:27 <lindi-_> what'snuttx-bb?
Jan 28 15:33:29 <GNUtoo> (nuttx-bb)
Jan 28 15:33:39 <GNUtoo> it's a microcontroller "OS"
Jan 28 15:33:59 <GNUtoo> BSD license I think, but it's needed to move layer23 on the calypso
Jan 28 15:34:15 <GNUtoo> (layer23 from osmocombb)
Jan 28 15:34:57 <lindi-_> ok
Jan 28 15:34:59 <GNUtoo> basically the calypso has 2 serial ports
Jan 28 15:35:08 <GNUtoo> one is MODEM and is cpu<->modem
Jan 28 15:35:22 <lindi-_> yep connected to the headset connector
Jan 28 15:35:23 <GNUtoo> and the other is IRDA which is connected trough a switch to the audio plug
Jan 28 15:35:25 <GNUtoo> yes
Jan 28 15:35:36 <GNUtoo> I made that work yesterday with the help of DocScrutinizer 
Jan 28 15:35:46 <GNUtoo> but still nuttxbb printed nothing at all
Jan 28 15:39:46 <GNUtoo> btw did you fix the first( alsa suspend) issue?
Jan 28 15:39:50 <GNUtoo> what about the second one?
Jan 28 15:59:43 <DocScrutinizer> yw
Jan 28 16:00:09 <DocScrutinizer> just explained to somebody how much I love to recycle that old knowledge
Jan 28 16:00:10 <GNUtoo> thanks
Jan 28 16:00:16 <GNUtoo> ok
Jan 28 16:00:33 <GNUtoo> but I didn't succeed either with 2 serial ports
Jan 28 16:00:46 <DocScrutinizer> there's nothing more pity than useless knowledge, or knowledge not to share
Jan 28 16:00:48 <GNUtoo> succeed means make nuttx-bb print something
Jan 28 16:00:54 <GNUtoo> indeed
Jan 28 16:04:42 * DocScrutinizer idly and sentimentally glances at that RS232<->2.5mm:4pin adapter cable - tagged "GTA02 modem serial"
Jan 28 16:05:13 <GNUtoo> basically there is a sercomm console on MODEM
Jan 28 16:05:16 <GNUtoo> so I had to use IRDA
Jan 28 16:05:18 <DocScrutinizer> we had a few approved ones around at OM
Jan 28 16:05:50 <GNUtoo> I made mine and it was dead easy, why "approved" ones were needed?
Jan 28 16:06:15 <DocScrutinizer> becuase initially nobody understood you should switch of the audio amp XP
Jan 28 16:06:23 <GNUtoo> ah ok
Jan 28 16:06:29 <DocScrutinizer> so load impedance was preety bad
Jan 28 16:06:34 <GNUtoo> ok
Jan 28 16:07:37 <DocScrutinizer> I forced that fix into fab sw only as late as A8 PV
Jan 28 16:08:39 <DocScrutinizer> and everybody frowned at me as it's been me who made some of the coders do a weekend shift as of course the bug showed up during the 3 days scheduled for PV at fab
Jan 28 16:09:42 <DocScrutinizer> It never occured to me they could have that bug, so I happily pushed some hw improvements to audio of A8 hw rev, that in turn "broke" the PV tests
Jan 28 16:10:01 <GNUtoo> PV?
Jan 28 16:10:10 <DocScrutinizer> Production Validation
Jan 28 16:10:13 <GNUtoo> ok
Jan 28 16:10:33 <DocScrutinizer> might have been first proto run though, not already PV
Jan 28 16:10:39 <GNUtoo> ok
Jan 28 16:10:53 <DocScrutinizer> I guess we never reached PV for A8
Jan 28 16:10:56 <GNUtoo> btw could #1024 be fixed by software?
Jan 28 16:11:02 <DocScrutinizer> nope
Jan 28 16:11:07 <GNUtoo> ah ok
Jan 28 16:11:08 <DocScrutinizer> just circumvented
Jan 28 16:11:25 <GNUtoo> by software I mean something like osmocombb running on top of nuttx
Jan 28 16:12:04 <DocScrutinizer> not even then, deepsleep means modem powers down main clock and relies on 32kHz clock which in turn been unstable
Jan 28 16:12:13 <GNUtoo> ahh ok
Jan 28 16:12:17 <GNUtoo> I understand
Jan 28 16:12:18 <DocScrutinizer> so your only sw chance is to avoid deepsleep
Jan 28 16:12:22 <GNUtoo> I've been reading some datasheets
Jan 28 16:12:24 <GNUtoo> ok
Jan 28 16:12:59 <DocScrutinizer> (simplified picture)
Jan 28 16:13:14 <GNUtoo> ok
Jan 28 16:13:18 <DocScrutinizer> it's clearly been a hw bug by our layouter
Jan 28 16:14:33 <DocScrutinizer> if you got a PSU output with a sense input, then you don't connect sense input to power output shortest possible way, rather you route a dedicated sense trace to the point where consumer of that power rail wants stable power voltage
Jan 28 16:14:44 <DocScrutinizer> to sense voltage at THAT point
Jan 28 16:14:58 <DocScrutinizer> layouter never heard of that
Jan 28 16:15:12 <DocScrutinizer> EE dude didn'T talk to layouter either
Jan 28 16:15:39 <GNUtoo> what's a sense?
Jan 28 16:16:13 <DocScrutinizer> a feedback to regulate output so that result on sense input is within specs
Jan 28 16:17:14 <GNUtoo> ok
Jan 28 16:17:34 <DocScrutinizer> you find that on top notch lab PSU as well
Jan 28 16:18:12 <DocScrutinizer> two power outputs, two sense inputs
Jan 28 16:18:13 <GNUtoo> ok
Jan 28 16:18:26 <GNUtoo> ah sense is like a sensor
Jan 28 16:18:51 <DocScrutinizer> PSU will deliver to output whatever it takes to make sense input == set voltage
Jan 28 16:18:59 <GNUtoo> ok
Jan 28 16:19:06 <DocScrutinizer> cabling loss gets eliminated that way
Jan 28 16:19:13 <GNUtoo> ok
Jan 28 16:20:07 <DocScrutinizer> in our case iirc the power suplly was for 32kHz oscillator
Jan 28 16:20:56 <DocScrutinizer> and EE/layout spoiled it thoroughly, by even introducing a "0R" between power+sense and consumer - of course a 0R never is zero R
Jan 28 16:21:42 <GNUtoo> hmmm
Jan 28 16:21:50 <GNUtoo> what's an or in electronics?
Jan 28 16:21:54 <DocScrutinizer> so the PSU took care there were *exactly* 1.8(?)V -- before the 0R
Jan 28 16:22:08 <DocScrutinizer> zero R
Jan 28 16:22:26 <DocScrutinizer> is a "resistor" that's supposed to be a plain wire
Jan 28 16:22:48 <DocScrutinizer> used to get breaking points where you can "cut" traces
Jan 28 16:22:54 <DocScrutinizer> to probe current etc
Jan 28 16:23:15 <DocScrutinizer> OM EE used that a lot, in rather insane positions
Jan 28 16:23:32 <DocScrutinizer> this just being one of them
Jan 28 16:24:10 <DocScrutinizer> another "nice" one: between switched PSU output and buffer capacitor   :-O
Jan 28 16:25:05 <DocScrutinizer> e.g R1720/22 of GTA02
Jan 28 16:25:15 <DocScrutinizer> BAAAD[TM]
Jan 28 16:26:57 <DocScrutinizer> DOWN1LX = output, DOWN1FB = feedback (sense), position where sense *should* be = at C1721/C1733
Jan 28 16:28:08 <DocScrutinizer> actually that 0R R1720 noticeably spoiled noise filtering and EMI on that trace
Jan 28 16:28:32 <DocScrutinizer> lack of expertise/experience in EE
Jan 28 16:28:42 <DocScrutinizer> *sigh*
Jan 28 16:30:21 <DocScrutinizer> or illiteracy as the app notes for PCF50633 (shall) CLEARLY state that the buffer Cs have to be as close to DOWNnLX as possible
Jan 28 16:30:44 <DocScrutinizer> NO 0R in between!
Jan 28 16:30:56 <DocScrutinizer> WTF! I still get upset
Jan 28 16:33:45 <GNUtoo> ok
Jan 28 16:38:01 <DocScrutinizer> they are using a 100pF || 100nF || 22uF to get low ESR on all frequency bands, esp the MHz range, then they PUT A "zero"R IN SERIES TO INCREASE EFFECTIVE SERIES RESISTANCE again - OMFG
Jan 28 16:39:08 <DocScrutinizer> (been also fixed in A8 hw rev IIRC, courtesy Doc)
Jan 28 16:40:06 <GNUtoo> lol
Jan 28 23:22:02 <GNUtoo> ALSA WORKS!!!!!! finally 
Jan 28 23:22:08 <GNUtoo> (3.2 on om-gta02)
Jan 28 23:44:14 <lindi-_> GNUtoo: so what's still broken? ;)
Jan 28 23:44:21 <GNUtoo> no idea
Jan 28 23:44:25 <GNUtoo> I'll look tomorrow
Jan 28 23:44:30 <GNUtoo> let me push the fix first
Jan 28 23:45:11 <lindi-_> GNUtoo: I'd need some low level ARM guy to debug the interrupt issue :/
Jan 28 23:45:19 <GNUtoo> ok
Jan 28 23:45:22 <lindi-_> I know some of the basics but there's a lot of stuff going on
Jan 28 23:45:26 <GNUtoo> ok
Jan 28 23:45:32 <lindi-_> I'm afraid the FIQ-in-C code might be involved too
Jan 28 23:45:40 <lindi-_> so maybe I should try disabling that first
Jan 28 23:54:48 <DocScrutinizer> OT - what's krunner (kde) doing?
Jan 28 23:55:33 <GNUtoo> lindi-_, on the todo list of 3.2 I think there is at least:
Jan 28 23:55:49 <GNUtoo>  * suspend/resume (same issue than you but really blocks suspend)
Jan 28 23:56:05 <GNUtoo>  * accelerometers I think
Jan 28 23:56:54 <lindi-_> ok, I don't care about accels :)
Jan 28 23:57:30 <DocScrutinizer> smells like IRQ breakage
Jan 28 23:57:33 <DocScrutinizer> all of it
Jan 28 23:57:47 <DocScrutinizer> accels: IRQ
Jan 28 23:57:58 <lindi-_> well all io is interrupt driven basically :/
Jan 28 23:58:04 <DocScrutinizer> suspend/resume: wake/IRQ
Jan 28 23:58:59 <DocScrutinizer> yeah, but not via some GPIO that has a dedicated IRQ handler that's fsckdup
Jan 29 00:00:39 <DocScrutinizer> I guess on DMA (just for an example) you won't have to choose for edge/level triggered IRQ, neither for level/direction that triggers
Jan 29 00:01:41 <DocScrutinizer> and not for pullup/pulldown/none termination of the pin, not for secondary-function/GPIO-in/GPIO-out
Jan 29 00:02:08 <lindi-_> DocScrutinizer: 2.6.34 has the same IRQ patch but there the suspend issue does not occur nearly as often
Jan 29 00:02:20 <lindi-_> and 2.6.29 does not have it but it still has a suspend issue
Jan 29 00:02:28 <lindi-_> so hard to predict much from this
Jan 29 00:03:33 <DocScrutinizer> also I recently learnt the chips we deal with at work (Thor) have a debouncing for GPIO IRQ that's based on clock, so going suspend and stopping clock you won't get any more level IRQ, you need to deal with those via wake-reason
Jan 29 00:04:36 <DocScrutinizer> dunno if same applies to all ARM core chips, so also to S3Cxxxx
Jan 29 00:06:42 <DocScrutinizer> on Thor a level trigged IRQ gets debounced by 4 clock cycles of the (usually) 50MHz clock on that function block, so a level has to stay steady for that duration to make a IRQ trigger, and of course that clock needs to be enabled for any triggering at all
Jan 29 00:08:20 <DocScrutinizer> usualy that shouldn't be an issue as proper level triggered IRQ is used with peripherals that don't reset the IRQ line until IRQ handler does a 'service' for the chip, I.E. reads and possibly resets some register in the chip
Jan 29 00:20:13 <DocScrutinizer> so usually you do: level on pin triggers sw jumping into IRQ handler stub (and usually also that IRQ getting disabled, obviously). This handler stub just schedules a IRQ service worker thread, then exits without re-enabling the IRQ. The service worker eventually services (reads out) - and thus resets IRQ level - of *all* chips that might have signalled the IRQ on that pin. calls or schedules the specific handlers for *all* chips 
Jan 29 00:20:14 <DocScrutinizer> that have IRQ bit set, and finally re-enables the IRQ on the SoC GPIO pin(, which same moment would catch any IRQ *level* that might have been asserted concurrently by any chip since handler has read that that chip's registers a few cpu clocks before).
Jan 29 00:22:20 <DocScrutinizer> s/specific handlers/specific service routines/
Jan 29 00:23:08 <DocScrutinizer> s/since handler/since service routine/
Jan 29 00:23:08 <apt> DocScrutinizer meant: that have IRQ bit set, and finally re-enables the IRQ on the SoC GPIO pin(, which same moment would catch any IRQ *level* that might have been asserted concurrently by any chip since service routine has read that that chip's registers a few cpu clocks bef...
Jan 29 00:23:34 <lindi-_> DocScrutinizer: http://lindi.iki.fi/lindi/openmoko/crash/2/arm-trace.txt is an instruction trace
Jan 29 00:24:15 <DocScrutinizer> of what particularly?
Jan 29 00:25:46 <lindi-_> DocScrutinizer: if the situation where resume does not succeed
Jan 29 00:25:51 <lindi-_> s/if/of/
Jan 29 00:25:52 <apt> lindi-_ meant: DocScrutinizer: of the situation where resume does not succeed
Jan 29 00:26:04 <lindi-_> just stays there in the interrupt handler
Jan 29 00:26:10 <DocScrutinizer> hmm, that's probably not enlightening much
Jan 29 00:26:29 <lindi-_> yeah needs some decoding
Jan 29 00:26:30 <DocScrutinizer> ooh?
Jan 29 00:26:43 <DocScrutinizer> what means "stays there"?
Jan 29 00:26:52 <lindi-_> DocScrutinizer: does not exit
Jan 29 00:27:36 <lindi-_> svc_exit macro is never executed
Jan 29 00:27:48 <lindi-_> so it is stuck trying to handle the interrupt
Jan 29 00:28:09 <DocScrutinizer> I don't see how that happens, unless you get re-entrance by some messed up IRQ control not disabling the IRQ properly (or IRQ handler re-eanbling it)
Jan 29 00:28:29 <lindi-_> DocScrutinizer: the code does not cope with the situation where an interrupt is pending and masked at the same time
Jan 29 00:28:53 <lindi-_> so it does not ack the interrupt and it is pending on every iteration of the loop
Jan 29 00:29:14 <DocScrutinizer> :nod:
Jan 29 00:29:37 <DocScrutinizer> seems this is pretty messed up and not in line with what I sketched above
Jan 29 00:30:26 <DocScrutinizer> IRQ handler mustn't re-enable the IRQ
Jan 29 00:30:38 <DocScrutinizer> unless the handler itself did the service
Jan 29 00:31:12 <DocScrutinizer> what usually isn't what you want to do, to keep IRQ times (where no other IRQ can happen) as short as possible
Jan 29 00:32:13 <DocScrutinizer> so the IRQ handler doesn't re-enable the IRQ, and thus won't spin in an endless loop
Jan 29 00:32:55 <lindi-_> DocScrutinizer: interrupts stay disabled
Jan 29 00:33:14 <lindi-_> it is not entering the interrupt handler again and again
Jan 29 00:33:18 <DocScrutinizer> then I don't see how the handler wouldn't exit
Jan 29 00:33:25 <lindi-_> there's a loop over all pending interrupts
Jan 29 00:33:34 <DocScrutinizer> WHAT?
Jan 29 00:34:06 <lindi-_> yeah
Jan 29 00:34:16 <lindi-_> it's all assembler of course
Jan 29 00:34:23 <lindi-_> so getting a clear picture takes some time
Jan 29 00:34:37 <lindi-_> but I know that interrupts stay disabled and the interrupt handler is not re-entered
Jan 29 00:34:46 <DocScrutinizer> I never seen such nonsense, usually you get a dedicated handler stub at a dedicated address in memory for each single IRQ line
Jan 29 00:35:13 <lindi-_> afaik there is some muxing going on
Jan 29 00:35:48 * DocScrutinizer burps
Jan 29 00:36:25 <lindi-_> my guess is that the goal is to reduce latency by handling more than one interrupt directly without returning from the handler
Jan 29 00:36:47 <DocScrutinizer> that's a onsensical approach
Jan 29 00:36:47 <lindi-_> since that surely reduces the worst-case latency
Jan 29 00:36:57 <lindi-_> I'm just reading what linux does :)
Jan 29 00:38:46 <lindi-> the interrupt handler that I wrote for ARM in an university course did handle only one interrupt per handler invocation :)
Jan 29 00:39:06 <DocScrutinizer> well, you say it is not reentring and still it doesn't ever exit. So there's some bug in the code that does an endless loop
Jan 29 00:39:30 <lindi-> got some report from that project we wrote: http://lindi.iki.fi/lindi/buenos-arm/doc.pdf
Jan 29 00:40:01 <lindi-> DocScrutinizer: yeah the code does not cope with the situation where pending != 0 && (pending & mask == 0)
Jan 29 00:40:06 <lindi-> (in pseudocode)
Jan 29 00:40:35 <DocScrutinizer> there mustn't be any >while "condition"< loop in a IRQ handler or service, only >for i in [whatever] do< loops that never can spin infinitely
Jan 29 00:40:46 <lindi-> well there is
Jan 29 00:40:51 <lindi-> a jump backwards in assembler
Jan 29 00:41:08 <lindi-> just check the source if you don't believe :)
Jan 29 00:42:27 <DocScrutinizer> I don't even think about whether it's true or flase, I just play Cpt. Obvious here and state what it must and what it mustn't do and look like
Jan 29 00:42:46 <lindi-> yeah it did seem weird to me too
Jan 29 00:43:07 <lindi-> I can only guess this is some latency optimization
Jan 29 00:43:27 <DocScrutinizer> IF the handler or service has a loop that doesn't terminate deterministically (on a defined count of loop iterations) then that's a bug
Jan 29 00:43:42 <DocScrutinizer> no, that's brainfuck
Jan 29 00:43:49 <DocScrutinizer> not optimization
Jan 29 00:44:40 <lindi-> I guess it depends on your point of view, I'm not sure :)
Jan 29 00:44:40 <DocScrutinizer> and FOR SURE won't result in any better latency whatsoever
Jan 29 00:48:26 <DocScrutinizer> you use edge triggered IRQ with a hadler that does the real thing already (which usually is sth silly like incrementing a counter or sth) when you need ultralow latency. The handler then never calls a service, as there's no need to service an edge triggered IRQ, the IRQ triggering condition is an entity anyway, and you'd not want to do lengthy servicing by reading out the peripheral that did IRQ via some sloooow I"C bus or sth
Jan 29 00:49:16 <DocScrutinizer> for everything else you use level triggered IRQ which also can be shared IRQ line, and the handler only schedules the service worker thread and then exits
Jan 29 00:50:35 <lindi-> DocScrutinizer: that's unfortunately not very helpful here :/
Jan 29 00:51:03 <DocScrutinizer> the service in turn of course reads out all the possible IRQ sources for that particular pin/GPIO to determine who fired the IRQ (there might be more than one, meanwhile)
Jan 29 00:52:38 <DocScrutinizer> it initiates whatever is due according to the meaning of the interrupt, for each interrupt if finds the flag set in a periph register, then definitely doesn't start all over again by periph#1 but rather ENABLES IRQ AND EXITS
Jan 29 00:54:34 <DocScrutinizer> so the loop in service is: for (i=0; I<NUM_OF_PERIPHERALS; i++)
Jan 29 00:56:04 <lindi-> DocScrutinizer: in your design yes :)
Jan 29 00:56:22 <DocScrutinizer> once the service did one run across all peripherals, it exits, last thing it's doing is enabling the IRQ for the GPIO
Jan 29 00:56:55 <DocScrutinizer> no races, no deadlocks, in that concept
Jan 29 00:57:16 <lindi-> yeah, unfortunately that concept is just not used in linux so it doesn't help :(
Jan 29 00:58:04 <DocScrutinizer> well, then nuke whatever is "used in linux" as it's evidently buggy anyway. Implement a clean IRQ framework
Jan 29 00:58:23 <lindi-> DocScrutinizer: eh?
Jan 29 00:58:36 <lindi-> DocScrutinizer: I already did that once for a toy os in a team of three people
Jan 29 00:58:56 <lindi-> DocScrutinizer: I know I wouldn't have a chance of doing something like that for linux
Jan 29 00:59:06 <DocScrutinizer> eh?
Jan 29 00:59:10 <DocScrutinizer> why?
Jan 29 00:59:28 <lindi-> because I don't have the time or skills
Jan 29 00:59:45 <lindi-> or the motivation really either
Jan 29 00:59:48 <DocScrutinizer> hell, that's basicall 150 lines of code
Jan 29 00:59:53 <lindi-> well then do it :)
Jan 29 01:00:19 <lindi-> also I try to mainline things, inventing a new IRQ framework would kind of make that harder
Jan 29 01:01:01 <DocScrutinizer> so what else? "fix" a broken concept? how you'd maintain THAT?
Jan 29 01:01:15 <lindi-> I didn't say the concept is broken
Jan 29 01:01:26 <DocScrutinizer> it evidently is
Jan 29 01:01:43 <lindi-> world is not black and white, I'm sure there were some good reasons behind this, I just don't understand them all, I can only guess
Jan 29 01:02:07 <DocScrutinizer> there was the reason somebody was clueless
Jan 29 01:02:24 <lindi-> I wouldn't blame people like that without first researching :/
Jan 29 01:03:20 <DocScrutinizer> well, you tell me IRQ handler (or was it service?) never exits. This indicates the concept is broken, as with a proper concept there was no way this could ever happen
Jan 29 01:03:44 <DocScrutinizer> Never happen*
Jan 29 01:04:12 <lindi-> never say never, for example memory corruption could easily cause that even in your simple concept
Jan 29 01:04:25 <DocScrutinizer> meh
Jan 29 01:04:46 <DocScrutinizer> no, only little green worms can cause that
Jan 29 01:05:58 <DocScrutinizer> when talking about memory corruption messing up code, we don't need to continue using this hardware
Jan 29 01:06:35 <lindi-> a bug anywhere in kernel could write a random byte to a wrong location :)
Jan 29 01:07:04 <DocScrutinizer> uhuh, thus changing a for loop to a while loop?
Jan 29 01:07:36 <DocScrutinizer> this starts to get silly
Jan 29 01:07:53 <lindi-> I don't think I manage to communiate this bug very well
Jan 29 01:08:03 <DocScrutinizer> sorry, I got better things to do than discussing this fictive error source
Jan 29 01:08:12 <lindi-> so just look at the source and trace :)
**** ENDING LOGGING AT Sun Jan 29 02:59:58 2012