IRC logs for #openrisc Sunday, 2014-05-18

--- Log opened Sun May 18 00:00:53 2014
stekernblueCmd: while waiting for the "big SMP patch", I give you a couple of minor cleanup/preparation patches:07:00
stekernblueCmd: feeling generous today, and I promised to be transparent:
stekernstill a bit of stubs in there, so it's not quite booting with the second cpu yet08:28
stekernbut, I think I've killed most of the bugs in the stuff that *is* implemented...08:29
olofkDoes Linux have any regression tests to help implementing stuff like this?08:44
olofkDoes it have any tests at all?08:44
stekernif it boots, it works, right?08:58
olofkIf it boots, ship it09:01
stekernI think there are a couple of build-bots that run all sorts of tests and stuff, but not anything "official" like the gcc one I think09:02
stekernbesides, I think Linux development model depends on a large amount of users that test, report and/or fix bugs09:03
stekernwhich of course have it's sides...09:03
olofkYes. It's probably difficult to do unit testing on the hw-specific drivers09:06
olofkAnd you won't catch system-level performance regressions with unit test eithers09:06
olofkBut maybe file system code and stuff like that could probably benefit from some test cases09:07
blueCmdmake randconf!09:33
blueCmdor maybe make randconfig09:33
blueCmdstekern: secondary = "not primary"?09:37
blueCmdi.e. you have one primary core and can have multiple secondary cores09:38
stekern!boot_cpu is perhaps the most correct description10:05
blueCmdwell the code makes sense and AFAICS the logic checks out10:29
blueCmdolofk: so. upstreaming gcc..10:40
stekernhmm, I'm thinking we should have hw support for the inter-processor interrupts14:30
stekerndon't have anything concrete in mind yet, so I just throw it out like that for possible feedback and ideas ;)14:31
stekernone option would of course be a completely generic core that can be written to over the wb bus that generates an irq signal14:32
stekernwe already have the interrupt-generator core that we've been using for test purposes14:33
stekernI think it's probably better to make a pure "IPI" core18:28
olofkstekern: Yes. I'm all for a proper Interrupt controller as well18:29
olofkBut are there any additional requirements for multicore?18:30
stekernwhat I'm after now is "sw interrupts, signaled from one core to another/others, with a "message"18:31
olofkLike a mailbox?18:31
olofkWell, you need interrupt for that as well of course18:32
stekernso, I'm thinking, each core has its own control reg and its own status reg18:32
olofkFor masking and reading and setting level/edge and things like that?18:33
stekernyou write cpu # (let's say upper 16-bits) and "message" (let's say lower 16-bits) to the control reg18:33
stekernthen irq # goes high to cpu #18:34
stekernand in cpu # status reg is high 16-bit sender cpu, low 16-bit "message"18:34
olofkIf you want messages, my idea is more like:18:37
stekernI think I mixed the upper and lower bits, but you get the point18:37
olofk1) Sender CPU writes message and destination to mailbox18:37
olofk2) Receiving CPU gets a mailbox IRQ18:37
olofk3) Receiveing CPU get the message18:37
stekernhow is that different ;)18:38
olofkNo limits on message length18:39
olofkmailbox is a separate core from the interrupt controller18:39
stekernok, I'm not sure I need "messages", more an irq with some data stuck onto it18:39
olofkoh... I see now that our ideas were a bit more similar than I first thought :)18:40
olofkYes, I don't really understand your use case18:40
stekern...that of course doesn't mean that the mailbox idea should be dismissed18:40
stekernlet me paste a random Linux IPI handler:
stekernthe things in the "switch (which)" is what I want as "data" attached to the IRQ18:41
stekernit's basically an "irq number container"18:43
stekernso, what I want, is to generate a specific IRQ to another core18:44
olofkah ok18:45
stekern...but, then my description of my possible implementation got a bit more generic, since you could basically send "whatever" in that 16-bit container.18:46
olofkIf we don't expect too many CPUs, the easiest way would probably be a full IRQ matrix between the CPUs18:46
stekernhmmm... maybe, but I don't see that being much easier than a couple of regs18:47
olofkNo, probably not, but I already drifted away a bit here, and came up with a few other features :)18:48
stekernlike? ;)18:48
olofkLike how to handle IRQ migration18:48
olofkAnd isolating CPUs18:49
stekernhmm, yeah, but that's more of a job for a possible "proper Interrupt controller"18:50
stekern(of which the IPI core could be a part of)18:50
olofkWhen you say registers btw, do you mean SPRs?18:55
olofkOr do you mean a separate core?18:55
stekernno, just WB accessable registers18:55
olofkWould that be handled with a driver and be included in the dts?18:56
stekernyup, something like that18:56
olofkThen we can always switch if we find the time do to a more full blown interrupt controller later on18:57
stekernyeah, I'm trying to make this generic, so the interrupt controller register itself into the generic code as an IPI handler18:57
stekern(that's how arm (and some others) do it)18:58
stekernarm have their gic18:58
olofkGeneric Interrupt Controller?18:59
stekernto be more precise, here is where the gic register itself to the SMP code as an "IPI handler":
stekernso the "IPI core" driver would basically just do that19:01
stekernsomething like this:
stekern...completely untested20:05
olofkahh.. I didn't know you could define several localparam at once20:07
olofkBut it's the same way for regs and wires, so why not20:08
stekernmmm, I don't like wires and regs defined like that though ;)20:12
olofkIt might be an idea to inhibit writes if there is already a pending irq20:12
olofkhaha. Me neither, but it looked good for localparams in this case20:13
stekernyes, I think it's good for grouping them together. Makes enum-like params almost look like enums.20:13
stekern(inhibit writes) hmm... perhaps.. we could also add a "IRQ pending" bit to the status reg, and it can be handled in sw20:15
stekernI think the "IRQ pending" bit in the status reg is a good idea either way20:16
olofkNot sure I have thought this through, but I'm worried that you may get zombie irqs if you write to the control register multiple times with different dest cores20:18
stekernnot sure what a zombie irq is, but if you do that, you'll fire off multiple irqs to multiple cores20:19
stekerneach dest core has it own status reg20:19
olofkI just made up zombie irq because I couldn't come up with a better name :)20:21
olofkok, looking a bit more, the problem is rather that another core can overwrite the pending irq20:22
stekernyes, a "mailbox fifo" would of course remove that problem20:23
stekern...but then the core is suddenly a lot more complicated20:23
olofkAgree, but couldn't you just stall the write until the IRQ is cleared20:24
stekernso, I've added a "IRQ pending" bit to the status reg, that is directly connected to the irq output20:24
olofkOr raise the rty line, if anyone listens to that :)20:24
stekernthat way, a irq generating cpu can first check the dest cpu's status reg for old pending IRQs before issuing a new20:25
olofkSo it's up th sw to poll the status reg first. That works just as fine20:25
stekernI think that's better, then the generating cpu at least have a chance to do something else useful while it's waiting for the dest cpu to handle old irqs20:26
olofkAhh that's true. Delaying the ack in this case is just mean20:27
stekern...instead of waiting for a stalled wb bus20:27
olofkAnd we are nice people20:27
stekernwe are... or at least we try to make people believe that ;)20:27
olofkWhy don't you add an IRQ instead of polling? ;)20:27
stekernit'll be in the "fancy, can do it all controller"20:28
olofkYep. The Turing complete IRQ controller with a built-in Forth interpreter20:28
stekernin that, you'll be able to reroute the negated irq to yourself20:28
olofkI'm going to write the first interrupt controller with an app store20:29
blueCmdolofk: haha21:13
-!- Netsplit *.net <-> *.split quits: poke53281, fotis2, pgavin, Findeton, blueCmd, olofk, imphil, mdeininger, ams, phoohb, (+20 more, use /NETSPLIT to show all of them)22:14
-!- Netsplit over, joins: Findeton, knz, O01eg, pgavin, skip_, blueCmd, ssvb, wallento, zama, fotis2 (+20 more)22:20
--- Log closed Mon May 19 00:00:55 2014

Generated by 2.15.2 by Marius Gedminas - find it at!