On Mon, May 10, 2010 at 07:09:02PM +0200, 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().
>
> 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() ???
The txpath should prevent the hardirq to run? Then bh-locking
would not be sufficient.
Maybe I missed something.
>
> Regards,
> Oliver
> _______________________________________________
> Socketcan-core mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/socketcan-core
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
