Hi Klaus, On 05/09/2010 11:57 PM, Klaus Hitschler wrote: > Hi Oliver, > > this is not a special Peak problem, the behavior can hit all SJA1000 chips > conected to fast hardware busses. > > When the command register is written it needs a little bit of time - about > 125 > nsec - to digest the command. 125 nsecs are a long time for modern > processors. > (see SJA1000 manual, 6.4.4)
OK. > If the SJA1000 is used on a single core machine the driver's code is solely > interrupted by the same core. In this scenario the switch into the interrupt > handler may take the necessary time. > > 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. A PCI write cycle does take more than *1* PCI clock cycle. Do we have a system to reproduce the problem? On what hardare did the problem show up? > Then it seems that the last register access never had happend. > > So you need some mechanism to prevent this situation. I've done it with > guarded_write() in my driver's code. > > I appreciate if you adopt the socketcan's SJA1000 code, so I need not to > worry > about this when I link this code part to future drivers. 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. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
