Hi Oliver, On 05/10/2010 07:09 PM, Oliver Hartkopp wrote: > On 10.05.2010 10:14, Wolfgang Grandegger wrote: >> On 05/09/2010 11:57 PM, Klaus Hitschler wrote: > >>> But if the same scenario runs on a multicore machine it may be that the >>> driver's non-interrupt-handler code runs in parallel on one core and the >>> driver's interrupt handler code runs on another core. >>> >>> If both code paths access the SJA1000's command register it can >>> happen that a >>> second command register access hits a bus cycle later after the >>> first command >>> register access. With PCI this may be down to 33 nsec. > > Hi Wolfgang, > >> The patch Oliver posted, as a general solution, is too heavy, at least >> for embedded systems. We need a more sophisticated and lighter solution, >> e.g. only for SMP systems and PCI, adding a >> ndelay(internalclock-period-in-ns) after a command register write, using >> a dedicated callback for command register writes, like Oliver suggested. > > i wonder whether it is enough just to settle the register write of the > command register by adding the ndelay().
We need some protection, of course. Also, ndelay() is not available on all archs and might be mapped to udelay(1). In the patch you posted, an extra read is done for that purpose, I assume. > Especially as the command register is used within the hard-irq context > (on CAN-frame or CAN-error reception) AND within softirq/process context > when sending CAN-frames. > > IMHO the ndelay() is generally necessary for the register access on fast > PCI adapters that go down to 33ns. > > But IMO additionally the tx path should probably generally take the > hands of the chip, when the used hard-irq for rx operations is active. > > I would suggest sja1000_interrupt() and sja1000_start_xmit() not to run > together. What about some _bh-locking in sja1000_start_xmit() ??? Yes, fine, especially if it does solve the issue with the command register as well? Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
