**** BEGIN LOGGING AT Fri Dec 07 02:59:59 2012 Dec 07 03:37:40 can someone reccomend a fun introductory project? Dec 07 03:46:28 lVathan: for what? Dec 07 03:51:56 I would like to be able to create a remote controlled vehicle through a network Dec 07 03:53:24 something for a fun afterwork project Dec 07 04:11:14 Hmm Dec 07 04:19:12 Hmm! Dec 07 04:31:13 how is it in ds2 world? Dec 07 06:03:18 Hi guys, I was wondering where can i get mod_cgi.so for beagleboard xM Dec 07 06:03:25 I can not find it anywhere Dec 07 06:06:09 tried the source? Dec 07 06:07:15 ye Dec 07 06:07:20 couldn't find Dec 07 06:07:38 its not in the usr/lib folder Dec 07 06:07:47 you keep source in usr/lib? Dec 07 06:07:53 no a fan of unix conventions? Dec 07 06:07:55 no Dec 07 06:08:11 well i opkg install lighttpd Dec 07 06:08:23 and change the conf Dec 07 06:08:35 however when i restart the server mod_cgi is not found Dec 07 06:08:49 then... Dec 07 06:09:08 you answered yes and mentioned it is not in usr/lib, yet you do not agree that you keep source in usr/lib Dec 07 06:09:32 so is pi exactly 3, and squares are circles? Dec 07 06:09:47 oh i miss read the source part Dec 07 06:09:55 sorry* Dec 07 06:10:26 so i should download the lighttpd source and find it there? Dec 07 06:10:47 one would hope so if it is indeed part of it Dec 07 06:11:02 ideally, you would want to get the sources for what your binaries came from Dec 07 06:11:39 ok i will try that now. So im assuming that opkg doesnt install everything? Dec 07 06:12:57 hmm found the mod_cgi.c Dec 07 06:13:10 i guess i will have to reinstall it from source Dec 07 06:13:57 look at the recipe to see if it builds it Dec 07 06:14:02 it might get packaged differently Dec 07 06:14:37 sigh... Dec 07 06:14:45 the loses_context thing in omap has always confounded me Dec 07 06:15:03 ''The omap gpio driver should never be calling get_context_loss_count for a gpio bank in a always-on domain. This is pointless and adds unneccessary overhead.' Dec 07 06:15:07 oh i see, thanks for the help Dec 07 06:15:23 yes, because tracking loses_context is so much easier than get_context_loss_count Dec 07 06:15:26 wtf yo Dec 07 06:15:47 it can be Dec 07 06:16:04 in comparison to a resume? Dec 07 06:16:44 and in the case of hibernate, or rtc only ddr self refresh, *everything* loses context Dec 07 06:17:09 well... Dec 07 06:17:12 which OMAP? Dec 07 06:22:03 am335x Dec 07 06:22:09 well, with hibernate, any omap Dec 07 06:22:30 the whole keeping tracking of loses_context to avoid a call is just silly Dec 07 06:22:53 the extra complexity and book keeping for what? Dec 07 06:23:35 thought PM is completely F'ed on that? Dec 07 06:23:55 on hibernate? Dec 07 06:23:59 on am335x? Dec 07 06:24:05 yes on am335x Dec 07 06:24:12 fortunately or on-fortunately, I'm dealing with the psp kernel Dec 07 06:24:16 at least for now Dec 07 06:25:38 ohh Dec 07 06:25:55 I got the completely F description from mr BB Dec 07 06:25:57 er, unfortunately Dec 07 06:26:05 jk? Dec 07 06:26:06 what part of PM does work then (in the PSP kernel)? Dec 07 06:26:07 yeah Dec 07 06:26:15 sleep works Dec 07 06:26:27 but this is psp, am335x is still getting upstreamed Dec 07 06:27:03 don't care about upstream Dec 07 06:27:13 my udnerstanding is there is a fatal bug in the M3 firmware Dec 07 06:27:20 hence it has issues waking up Dec 07 06:27:24 could be, I'm not aware of it Dec 07 06:27:33 is this a once in 1, once in 10, once is 1000? Dec 07 06:28:26 donno Dec 07 06:28:33 it was enough of a reason to avoid that platform Dec 07 06:28:50 once in 1k is certainly enough to commercially avoid a platform Dec 07 06:29:38 fatal M3 firmware bugs are fixable though, unlike rom code Dec 07 06:30:00 isn't M3 ROM'ed? Dec 07 06:30:13 the M3, AFAIK, isn't well documented Dec 07 06:30:17 for us mere mortals Dec 07 06:31:06 firmware/am335x-pm-firmware.bin.gen.S Dec 07 06:31:20 Ooooh Dec 07 06:31:24 er Dec 07 06:31:26 that isn't source Dec 07 06:31:38 you are using the same ES as the bone, right? Dec 07 06:31:44 firmware/am335x-pm-firmware.bin is just a blob Dec 07 06:32:06 is that linked into the kernel? Dec 07 06:32:08 somehow, I go long periods of time without learning simple things like 'ES' Dec 07 06:32:21 it can be linked into the kernel, or loaded at runtime Dec 07 06:32:32 ES is one of those things you live and die by with the OMAP world :( Dec 07 06:33:06 silicon revision? Dec 07 06:33:10 yeah Dec 07 06:33:26 a lot of the ES1.0 stuff have problems and I suspect the bones are ES1 stuff Dec 07 06:33:26 I'm on PG 1.0 right now Dec 07 06:34:05 you say ES, I say PG? Dec 07 06:34:35 Hmmmm wonder if there is a difference Dec 07 06:35:02 I think I was supposed to get a PG 2.0 board, but there was some confusion Dec 07 06:35:29 wonder if ES is an OMAP term and PG is a 'star' term Dec 07 06:38:48 dunno, pg 2.0 has a lot of fixes from what I understand Dec 07 06:41:22 I'd expect so Dec 07 06:41:31 and probally some registers are getting changed Dec 07 06:52:41 * mranostay hides from tema Dec 07 06:56:00 Hmm why is gcc in the usr/lib folder? shouldnt it be in /usr/bin folder? Dec 07 06:56:12 ls Dec 07 06:57:28 :/ Dec 07 06:58:41 i can't compile anything if gcc is not in usr/bin folder? Dec 07 07:04:56 er why not? Dec 07 07:06:42 i dont know when i do gcc file.c i get an error says -sh: gcc: not found Dec 07 07:08:54 why did you not install gcc? Dec 07 07:10:41 i did install gcc Dec 07 07:19:08 there is a symlinks packages iirc Dec 07 07:23:12 hi tasslehoff Dec 07 07:59:10 mranostay: how to join the trolling? for me, there'snowwhere a button for it... Dec 07 08:00:02 er Dec 07 08:00:07 there was Dec 07 08:00:15 you clikc on the comminitry Dec 07 08:00:19 and then accept Dec 07 08:00:36 no accept button here. Dec 07 08:01:05 "view community" Dec 07 08:01:12 the button says "preview communitty" Dec 07 08:01:23 i invited you Dec 07 08:01:38 you doing this from your computer not phone? Dec 07 08:01:54 yep, computer Dec 07 08:02:43 LetoThe2nd: I had the same problem, then I switched browsers Dec 07 08:02:53 google chrome doesn't work with g+ communities over here Dec 07 08:02:57 safari nightly does Dec 07 08:03:13 koen: yeah was abaout to say i'm already running the one and only google browser Dec 07 08:03:28 g+ also looks different between the two, so I suspect chrome is caching some old css Dec 07 08:05:55 indeed, on the flaming fox it works. Dec 07 08:07:25 am i missing any trolls? Dec 07 08:07:34 some haven't accepted yet Dec 07 08:21:13 linux is so dead: http://www.cnx-software.com/2012/12/07/ti-releases-ti-rtos-a-free-real-time-operating-system-for-mcus Dec 07 08:22:11 av500: tglx will suffer a heart attack. Dec 07 08:22:43 yes Dec 07 08:22:47 and it is even in concert(o) Dec 07 08:22:48 in real time Dec 07 08:23:10 aargh, XDC Dec 07 08:23:30 av500: as in "you, and me, and xdc"? Dec 07 08:23:59 yes Dec 07 08:24:05 hmm, can I run that on the launchpad? Dec 07 08:24:15 soon, it says Dec 07 08:25:30 * LetoThe2nd wonders if it is just free beer - open source, or an actual FOSS license that thing is under Dec 07 08:27:47 who, 500M for an cortex-m4 OS? you kidding me. Dec 07 08:29:01 hey, it says bsd. Dec 07 08:29:23 it has to Dec 07 08:29:40 you mean it is not quite voluntarily? Dec 07 08:30:44 bsd makes sense Dec 07 08:30:52 (delayed) hi mranostay :) Dec 07 08:31:14 * LetoThe2nd grabs source and instantly ports to nxp cortex-mX ;) Dec 07 08:43:57 that frackin' TI installer Dec 07 08:44:07 that loses the folder name as soon as you navigate Dec 07 09:27:25 mru: another reason to study psychology: you get cookies from the girls :) Dec 07 09:29:26 KotH: what is your cookie acceptance policy? Dec 07 09:33:16 av500: must contain chocolate Dec 07 09:38:39 KotH: sounds ok Dec 07 09:38:45 will set that in firefox :) Dec 07 09:52:07 :) Dec 07 10:00:31 lol... *lots of simple statistical formulas on the blackboard* student asks "what's this 'e' there?" Dec 07 10:20:41 e^-j? Dec 07 10:22:58 simpler than that Dec 07 10:23:26 just some e^(1/(1+d)) and similar Dec 07 10:23:47 ah Dec 07 10:24:46 remember, it's psychology, not EE or physics :) Dec 07 10:25:55 * KotH wonders what would happen if some prof would actually use complex numbers Dec 07 10:26:59 KotH: you could write a psychology paper on the reactions Dec 07 10:27:12 good idea Dec 07 10:27:18 for using Cthulhu numbers Dec 07 10:28:02 the title would probably read something like "girls taking up pitchforks when being exposed to complex numbers" Dec 07 10:29:00 mhhh project pitchfork Dec 07 10:30:05 .o0(hunger) Dec 07 10:30:29 one for the weekend: http://www.youtube.com/watch?v=cdkBs0VCSX0 Dec 07 10:43:53 are these errors normal in the beagle 3.7-rc8 kernel? Dec 07 10:43:53 [ 2746.021344] hub 1-0:1.0: hub_suspend Dec 07 10:43:53 [ 2746.021406] usb usb1: bus auto-suspend, wakeup 1 Dec 07 10:43:53 [ 2746.021426] usb usb1: bus suspend fail, err -16 Dec 07 10:43:53 [ 2746.021439] hub 1-0:1.0: hub_resume Dec 07 10:43:53 [ 2746.021544] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 Dec 07 10:44:03 over and over and again Dec 07 11:12:33 jackmitchell: those are expected, yes Dec 07 11:12:45 jackmitchell: you can work around those by plugging in a usb device Dec 07 11:12:59 to plug the leak so to say? Dec 07 11:13:12 usb microwave ok? Dec 07 11:20:33 koen: another quick one, admittedly I haven't really looked into it, but the bone is getting a new IP address on every reboot from the DHCP server, does the MAC address get read from the eeprom properly? I'm using the generic u-boot eEnv on the github repo Dec 07 11:21:51 jackmitchell: it doesn't, random mac Dec 07 11:22:03 jackmitchell: the comments in the code say "uboot fills it in", but that's a lie Dec 07 11:22:30 koen: pass a MAC on the kernel command line? Dec 07 11:23:00 koen: ok, thanks! Dec 07 11:23:52 av500: sure, that would work Dec 07 11:24:13 av500: but I'm being a petty jerk and waiting for TI to fix it properly Dec 07 11:24:49 if you have an eth driver that accepts the mac from the command line, it works ;) don't know bout the bone, but certainly not everyone does. Dec 07 11:26:32 it's not all bad, the company refuse to do some work to extend the IP range on the network, this fast use of IP address might get them into gear when people start being locked out of the domain due to lack of IP addresses Dec 07 11:28:54 what, you don't have your own desk subnet? Dec 07 11:30:52 LetoThe2nd: I have my personal "off grid" subnet but I work on a lot of products with web front-ends which I then parade round everyone else on the peons subnet Dec 07 11:57:05 TGIF Dec 07 12:04:20 panto Dec 07 13:06:36 av500: http://img.thedailywtf.com/images/12/q4/e41/Pic-6.jpg Dec 07 13:07:01 that is one damn expensive list price! Dec 07 13:34:13 Hi guys! I am trying to do some interrupt generation on the BeagleBone and am finding out that it's impossible to send a word + a flag on a GPIO bank and have the interrupt actually trigger. Is there any way around that, and why is this happening? Dec 07 13:36:00 When I say send, I mean the BeagleBone read the pins that are set at the appropriate voltages by an external circuit. Dec 07 13:36:28 And for anyone interested I've managed to get Xenomai to run on the BeagleBone, I promised I'll come back with the answer :) Dec 07 13:36:40 heh, congrats Dec 07 13:36:53 dvance_, what do you mean impossible to send a word + flag? Dec 07 13:37:02 the gpio interrupts don't work? Dec 07 13:37:42 Ok, I'll elaborate -- I want to receive two types of data. Type A and B. So I would like those to be recognized by the BeagleBone as different types. Dec 07 13:38:00 For that purpose I have two pins be configured as interrupts and depending on which one is HIGH I can tell which word is being received Dec 07 13:38:03 So far so good Dec 07 13:38:19 When you activate one of those two pins, the IRQs are generated and handled correctly Dec 07 13:38:48 but if I set the rest of the pins which are to carry the word over to some values and the pin that is the corresponding to the data type, then the IRQ is not generated Dec 07 13:39:42 In short if you set anything else apart from the interrupt pin on that bank to anything, then the interrupt is not generated Dec 07 13:40:15 dvance_: how are you reading the other pins? You're not wiping the interrupt by accident are you? Dec 07 13:40:48 No, I am trying to communicate between two BeagleBones, so I have a cable connection over Dec 07 13:40:56 One BeagleBone outputs the other receives Dec 07 13:41:07 dvance_: and how do you read the pins on your beaglebone Dec 07 13:41:16 sysfs..? Dec 07 13:41:28 Kernel module -- so read32 Dec 07 13:41:49 hmm, so are they memory mapped? Dec 07 13:41:50 dvance_, err, you're reading the GPIO registers directly? Dec 07 13:42:02 yes Dec 07 13:42:04 and from user-space? Dec 07 13:42:09 That's the only way to do it from kernel space Dec 07 13:42:10 you should really be using the gpiolib Dec 07 13:42:16 yeah Dec 07 13:42:44 jackmitchell , the gpiolib is not real time compatible and is generally rather slow, so I can't really use that Dec 07 13:43:02 ah Dec 07 13:43:04 Apologies, not read32 but ioread32 :) Dec 07 13:43:16 ugh, even worse Dec 07 13:43:18 well, I can only suggest you may be blitzing the registers when doing raw reads Dec 07 13:43:35 or writes Dec 07 13:43:37 there's a new gpio block API that might suit your needs Dec 07 13:44:28 or if you're feeling hardcore use the PRU Dec 07 13:44:39 *cough* Dec 07 13:44:48 panto, please don't mystify it Dec 07 13:44:53 jackmitchell, I doubt it since the error shows up when the input is changed, for example I were to send 8 over the bank which is the address of the interrupt pin, then the interrupt is triggered, and if i were to send 8 + 64 which would be an interrupt plus 64 as my word, then it won't, and I can repeat in any order and the results are reproducable Dec 07 13:45:16 dvance_, a few lines of code might help us Dec 07 13:45:26 panto, as mranostay found out, pru is trivial to leverage. Dec 07 13:45:35 if the punk can do, everyone can! Dec 07 13:45:55 Lol, PRU is my next performance step, for now just ARM CPU processing Dec 07 13:46:06 Ok, how should I show you some code? Dec 07 13:46:12 pastebin? Dec 07 13:46:23 dvance_: I'm not sure sorry, but I can pipe in that I have done memory mapped GPIO with interrupts from user space without issue Dec 07 13:46:32 So what code do you want to see :) Dec 07 13:46:33 so it is possible Dec 07 13:46:40 the access code Dec 07 13:46:48 For the data read? Dec 07 13:46:56 yes Dec 07 13:47:01 and the interrupt handling Dec 07 13:47:08 One sec Dec 07 13:47:55 dvance_, you said "not real time compatible"...and so it should be pointed out that neither is doing stuff in the kernel regardless of api. Dec 07 13:48:05 depending on your definition of real time ;) Dec 07 13:48:12 the a8 is not a real-time cpu Dec 07 13:48:19 even better Dec 07 13:48:24 stupid caches Dec 07 13:48:36 and mmu Dec 07 13:48:42 stupid pipelines Dec 07 13:48:50 it's ruined everything ;) Dec 07 13:48:51 stupid performance Dec 07 13:49:01 ok so the interrupt registration is here Dec 07 13:49:08 oh wait, there was some point to those things..gotcha Dec 07 13:49:13 hehe Dec 07 13:49:27 the trouble with application processors is that the worst case is _much_ worse than the average case Dec 07 13:49:33 Guys I am aware of that, I meant it won't play nice with Xenomai -- you'll get context switches Dec 07 13:49:35 and very difficult to calculate Dec 07 13:49:51 pastebin.com/QmsHLgn6 Dec 07 13:49:59 Is the interrupt registration Dec 07 13:50:03 mru, true, but it turns out 99.9% of the times you don't care about real-time performance Dec 07 13:50:05 One sec for handling Dec 07 13:50:16 panto: for applications, no Dec 07 13:50:34 I never suggested these cpus were a bad idea Dec 07 13:50:38 not as such Dec 07 13:50:47 they're not suited for certain use cases Dec 07 13:50:57 and the interrupt handlers: http://pastebin.com/q2v3UtgC Dec 07 13:52:42 I've omitted the definitions of the addresses and stuff Dec 07 13:52:51 how do irq_Channel/irq_Symbol get called? Dec 07 13:53:06 mdp, ??? Dec 07 13:53:24 ret = rtdm_irq_request(&intrSymbol, irqSymbol, irq_Symbol, 0, "IntrRxSym", NULL); Dec 07 13:53:36 They're registered as interrupt handlers, so they are called by the scheduler Dec 07 13:53:41 ioread32/iowrite32 are useless Dec 07 13:53:42 once the IRQ is generated Dec 07 13:53:43 I see Dec 07 13:54:01 you're reading well known little endian registers on a little endian cpu Dec 07 13:54:20 and you're ok with the indeterministic amount of time that passes between the time the irq fires and when this executes, right? Dec 07 13:54:23 panto, what do you mean by that? Dec 07 13:54:39 I am not OK with it, but I have accepted that fact :) Dec 07 13:54:57 dvance_: acceptance is the first step, yes Dec 07 13:55:21 ioread32 is implying you're accessing a little endian register from a portable driver Dec 07 13:55:31 mpd, yepp :) that's my next step is either using the PRU or interfacing with an FPGA using some FIFOs Dec 07 13:55:33 I doubt this driver is portable to a powerpc, no? Dec 07 13:56:09 panto, sure, I am not so interested in whether the data is read correctly right now, but why the interrupt is not generated Dec 07 13:56:11 err, wait Dec 07 13:56:25 dvance_: just be sure to NOT use a gpio bank when you do it in the PRU Dec 07 13:56:32 I am not trying to achieve portability :) Dec 07 13:57:12 mdp, why should I not use a GPIO bank in the PRU? I would like to read some 32 bit words into the PRU if possible :) Dec 07 13:58:16 Anyway, what's more important right now is why when the GPIO bank reads something else other than just the interrupt pin going to HIGH it does not trigger the IRQ Dec 07 13:58:26 dvance_, you lose determinism, but if you need to read a complete 32-bit chunk with no external logic then it's a bit better than from the arm at least Dec 07 13:59:21 mdp, I don't understand? Do I not need to access the GPIO banks through the PRU so that it can read from them? Or is it possible to mux them to the PRU? Dec 07 13:59:25 dvance_, is that SDR? Dec 07 13:59:30 SDR? Dec 07 13:59:36 software defined radio? Dec 07 13:59:47 bitbanged sdr? Dec 07 13:59:54 Yeah, let's call it that :P I am not at liberty to discuss what exactly it is I suppose Dec 07 14:00:10 dvance_, if you can develop your interface using only _PRU_ pins then you can avoid using the GPIO banks that are out on the SoC crossbar Dec 07 14:00:14 It's a prototype that I'm brewing at our lab here, so it's custom Dec 07 14:00:19 why are you disabling the interrupt? Dec 07 14:00:34 are your interrupt edge or level sensitive? Dec 07 14:00:37 So that the interrupt handler does not get called while the interrupt is being handled? Dec 07 14:00:39 *interrupts Dec 07 14:00:49 dvance_, there is a distinct difference, but best discussed after you guys work on your ARM/GPIO stuff Dec 07 14:00:55 s/on/out/ Dec 07 14:01:00 that is handled automatically Dec 07 14:01:02 edge, as you can see the interrupts are triggered on RISINGDETECT Dec 07 14:01:29 you're not stopping the interrupts Dec 07 14:01:33 you're clearing the status Dec 07 14:01:52 ugh, no scratch that Dec 07 14:02:19 Yeah, the documentation is a bit confusing on which register does what exactly Dec 07 14:02:48 well, look at drivers/gpio/gpio-omap.c Dec 07 14:03:39 looks like you need to do a read afterwards at least Dec 07 14:04:36 flushing writes to device memory? Dec 07 14:04:36 it looks it's more complex than just banging at the register Dec 07 14:04:49 right Dec 07 14:05:05 yeah, a read after a write makes sure the write is flushed out Dec 07 14:05:06 so I guess the back to back writes cancel each other Dec 07 14:05:22 if it's a buffered mapping, yes Dec 07 14:05:32 I don't think that's the issue Dec 07 14:05:39 I'll give you an example Dec 07 14:06:16 From BeagleBone1, I set GPIO2 = 8; BeagleBone2 reads that and generates interrupt Dec 07 14:06:19 All is well Dec 07 14:06:41 On BB1, I set GPIO = 8 + 64 (so flag + word); BB2 does not understand Dec 07 14:06:46 panto, typical posted write issue.. Dec 07 14:07:14 dvance_, the h/w is much more complex now than it used to be Dec 07 14:07:43 have you checked with a scope what the GPIO values are on the wire? Dec 07 14:07:45 panto, yes? I do understand the concept of buffered writes etc Dec 07 14:07:57 Yes, I have Dec 07 14:08:12 Well, I did earlier, Dec 07 14:08:15 Let me do it again Dec 07 14:10:03 IMHO, that disabling of interrupt in the handler is racy Dec 07 14:12:00 looking at the gpio-omap.c it's quite more elaborate Dec 07 14:12:15 plus I don't see where you ack the interrupt Dec 07 14:12:57 ok, you disable the interrupt (supposedly) at the start of the handler and then re-enable it at the exit Dec 07 14:13:05 where do you ack the interrupt you just received? Dec 07 14:13:38 err, wait Dec 07 14:15:18 I hate digital probe interfaces :( Dec 07 14:15:33 panto, the ack doesn't happen because it's not flushed...seems pretty clear Dec 07 14:16:33 yeah Dec 07 14:16:50 the gpio block docs are a bit wonky or it just me? Dec 07 14:16:52 I believe you need to read the same reg to flush the transaction onto the L4 Dec 07 14:17:13 which is why that's done in lots of drivers for irq handling Dec 07 14:17:40 I *think* some say you can read back any register in the region though Dec 07 14:17:50 which made me wonder about his read from datain Dec 07 14:18:14 panto, should be very familiar from PCI-land ;) Dec 07 14:18:24 meh ;) Dec 07 14:18:35 ok, I need to do some work now Dec 07 14:19:06 mdp: the arm arm should tell you that Dec 07 14:19:46 I don't understand why you should be doing an additional read to flush anything Dec 07 14:19:49 dvance_: in summary, you need to grok when/why omap-gpio.c does those flushes and duplicate...as you are reinventing the wheel here Dec 07 14:20:05 mru, right Dec 07 14:20:06 hence why everyone is telling you to use gpiolib interfaces Dec 07 14:20:16 The code on the receiver side does exactly the same whether an 8 or an 8+64 was sent Dec 07 14:20:28 and the results are different Dec 07 14:20:39 well, it's ok to avoid gpiolib if you have some performance enhancement to get the last 10% Dec 07 14:20:41 wait, wait Dec 07 14:20:44 i.e. when only 8 is sent an IRQ is generated, and when an 8+64 it is not Dec 07 14:20:57 you have a common interrupt handler for all the gpio interrupt sources? Dec 07 14:21:15 No, you can see in the code there are two interrupt handlers registered Dec 07 14:21:39 yes, but I also see you clear the status of both the GPIOs in every one Dec 07 14:21:40 as I tried to explain is what I am trying to do is transmit word + flag, where the flag is triggering the appropriate handler on the receiver Dec 07 14:21:55 I do because it is a common bus for both types of symbols Dec 07 14:22:01 you don't get it Dec 07 14:22:10 so I would like to do word + 8 for one type and word + 16 for the other Dec 07 14:22:12 you have two interrupt handlers Dec 07 14:22:25 one for each GPIO IRQ source Dec 07 14:22:32 if I do 0 + 8 or 0 + 16 -- > all is good Dec 07 14:22:40 panto, good catch Dec 07 14:22:49 but instead of clearing the interrupt that's the handler is handling you clear either Dec 07 14:22:53 but if I do X + 8 or X + 16 where X is non-zero, it does not generate the IRQ Dec 07 14:23:03 that's what I'm explaining to you right now Dec 07 14:23:49 do you understand why it doesn't work? Dec 07 14:24:25 It's a sequential transmission it's some A symbols followed by B symbols, so what I am trying to do by clearing both is to drop a symbol if the processing is not done for the previous one Dec 07 14:24:43 forget anything about symbols, transmission or whatever Dec 07 14:24:48 Nope, you've got me confused :) Dec 07 14:24:54 Ok, I'm listening Dec 07 14:24:58 you were confused to begin with :) Dec 07 14:25:06 ok, you have two interrupt sources Dec 07 14:25:27 you also have a method that generates the interrupts pretty much at the same time Dec 07 14:25:43 no Dec 07 14:25:55 I don't have a method that generates them at the same time Dec 07 14:26:10 See that's the thing, I'll try to be more clear Dec 07 14:26:17 you don't have to Dec 07 14:26:34 Interrupt A is on pin 3 which in decimal is 8; interrup B is on pin 4 which is 16 Dec 07 14:26:41 We're clear on that right? Dec 07 14:26:57 you're not helping me explain to you why it doesn't work Dec 07 14:27:03 What I want to do is read a word that is simultaneously sent with the interrupt Dec 07 14:27:19 Ok, I'll let you finish then Dec 07 14:28:57 first of all it doesn't seem you're acking any interrupt Dec 07 14:29:12 you are fiddling with the interrupt enable disable registers Dec 07 14:29:47 and you're not even doing proper flushing writes Dec 07 14:30:42 I have no idea how the gpio h/w block will behave when you bang on it like this Dec 07 14:30:47 it's not designed to do that Dec 07 14:31:06 results are 'boundenldy undefined' Dec 07 14:31:25 So how should I be doing it then? Dec 07 14:31:55 look at the drivers/gpio/gpio-omap.c Dec 07 14:32:04 the bone's GPIO block is the same as OMAP4 Dec 07 14:32:41 look at _clear_gpio_irqbank() Dec 07 14:32:59 it's called by gpio_ack_irq Dec 07 14:33:34 I really doubt you need to handle the enable/disable irq like this in the handler Dec 07 14:34:19 Well, I think I do, because otherwise my interrupt handler will be interrupted to handle the next interrupt Dec 07 14:34:39 doubt it Dec 07 14:34:58 most OSes disable reentrancy of interrupt handlers Dec 07 14:35:12 Well, if the time between two interrupts is smaller than the processing time it certainly will be Dec 07 14:35:31 Well, I am not sure Xenomai does that Dec 07 14:35:54 Btw these interrupts are not even seen by the standard Linux scheduler Dec 07 14:36:21 that's irrelevant Dec 07 14:36:35