| --- Log opened Wed Jul 05 00:00:00 2017 | ||
| stekern | blueCmd: ;) | 02:05 |
|---|---|---|
| stekern | I got a similar mail from greg kh after my first commit (for categorisation purposes) | 02:08 |
| blueCmd | yes, that one | 04:47 |
| shorne | stekern: hello, as mentioned before I have SMP kernel running, but there are some times I get issues with locking around the ipi code | 09:30 |
| shorne | its maybe related to how qemu works | 09:31 |
| shorne | but it looks also related to this wait code | 09:31 |
| shorne | while (--retry && ompic_readreg(ompic_base, OMPIC_IPI_STAT(dst_cpu)) & OMPIC_IPI_STAT_IRQ_PENDING) { udelay(1); | 09:31 |
| shorne | 09:31 | |
| shorne | now sure if you remember it... | 09:31 |
| shorne | But I was looking for a way to elimitate the wait. I was thinking a slight change in the IPI. I got an idea from Alpha | 09:32 |
| shorne | where instead of having a Pending flag and one IPI at a time | 09:32 |
| shorne | the IPI operations would be a bitmask. i.e. | 09:32 |
| shorne | IPI_RESCHEDULE 1<<0 | 09:33 |
| shorne | IPI_CALL_FUNC 1<<1 | 09:33 |
| shorne | then to raise IPI we could do cmpxchg | 09:34 |
| shorne | and to clear ipi do cmpxchg(ops, 0) | 09:34 |
| shorne | http://elixir.free-electrons.com/linux/latest/source/arch/alpha/kernel/smp.c#L509 | 09:37 |
| shorne | I will have to change hardware a bit, but do you think it makes sense? It would be nice to remove that delay. And I think it would simplify things a bit. | 09:38 |
| shorne | Also, one downside is we would lose the sender_cpu, since you can be sure which cpu sent which bit op. But its not really important | 09:38 |
| promach | does openrisc have its own internal scope like chipscope ? | 23:01 |
| shorne | stekern: I implemented that bit set for IPI, didnt have to change hardware. it works well, no timeouts no delays | 23:21 |
| shorne | promach: most people use verilator to debug openrisc as the wave level | 23:22 |
| shorne | I havent really done before but wallento would be our expert | 23:23 |
| promach | shorne: I will come back later | 23:26 |
| shorne | https://github.com/stffrdhrn/linux/commit/aa078a6eb34dfcd45dde606f92a47d6b1571b4dd | 23:31 |
| shorne | stekern: that is the patch, I am just concerned, the atomic ops are not going to really be synchronized between CPUs | 23:31 |
| shorne | but I think its OK with my semantics | 23:31 |
| shorne | CPUa set ops, raise IPI - CPUb | 23:33 |
| shorne | sorry... maybe not | 23:33 |
| shorne | currently I have | 23:33 |
| shorne | CPU[a] set ops, raise IPI - CPU[b] clear ops, clear IPI | 23:33 |
| shorne | I probably want | 23:33 |
| shorne | CPU[a] set ops, raise IPI - CPU[b] clear IPI, clear ops | 23:34 |
| shorne | https://github.com/stffrdhrn/linux/commit/ab7822e7d8ccbedd29557bdbadf7318ec41ccc3b | 23:39 |
| shorne | updated | 23:39 |
| shorne | Also... for timer sync, I found mips and x86 have some cpu boot code that syncrhonizes timers between CPUs | 23:54 |
| shorne | I think I will try to switch to that out for openrisc timer sync | 23:55 |
| --- Log closed Thu Jul 06 00:00:01 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!