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().
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() ???
Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
