IRC logs for #openrisc Wednesday, 2017-07-05

--- Log opened Wed Jul 05 00:00:00 2017
stekernblueCmd: ;)02:05
stekernI got a similar mail from greg kh after my first commit (for categorisation purposes)02:08
blueCmdyes, that one04:47
shornestekern: hello, as mentioned before I have SMP kernel running, but there are some times I get issues with locking around the ipi code09:30
shorneits maybe related to how qemu works09:31
shornebut it looks also related to this wait code09: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
shornenow sure if you remember it...09:31
shorneBut I was looking for a way to elimitate the wait. I was thinking a slight change in the IPI. I got an idea from Alpha09:32
shornewhere instead of having a Pending flag and one IPI at a time09:32
shornethe IPI operations would be a bitmask. i.e.09:32
shorneIPI_RESCHEDULE   1<<009:33
shorneIPI_CALL_FUNC   1<<109:33
shornethen to raise IPI we could do cmpxchg09:34
shorneand to clear ipi do cmpxchg(ops, 0)09:34
shorneI 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
shorneAlso, one downside is we would lose the sender_cpu, since you can be sure which cpu sent which bit op.  But its not really important09:38
promachdoes openrisc have its own internal scope like chipscope ?23:01
shornestekern: I implemented that bit set for IPI, didnt have to change hardware. it works well, no timeouts no delays23:21
shornepromach: most people use verilator to debug openrisc as the wave level23:22
shorneI havent really done before but wallento would be our expert23:23
promachshorne: I will come back later23:26
shornestekern: that is the patch, I am just concerned, the atomic ops are not going to really be synchronized between CPUs23:31
shornebut I think its OK with my semantics23:31
shorneCPUa set ops, raise IPI - CPUb23:33
shornesorry... maybe not23:33
shornecurrently I have23:33
shorneCPU[a] set ops, raise IPI - CPU[b] clear ops, clear IPI23:33
shorneI probably want23:33
shorneCPU[a] set ops, raise IPI - CPU[b] clear IPI, clear ops23:34
shorneAlso... for timer sync, I found mips and x86 have some cpu boot code that syncrhonizes timers between CPUs23:54
shorneI think I will try to switch to that out for openrisc timer sync23:55
--- Log closed Thu Jul 06 00:00:01 2017

Generated by 2.15.2 by Marius Gedminas - find it at!