Hello, Thanks for quick reply.
On Mon, May 10, 2010 at 3:46 PM, christian pellegrin <[email protected]> wrote: > > On Mon, May 10, 2010 at 1:47 PM, Fawad Lateef <[email protected]> wrote: > > Hello, > > > > Hi, > > > > > It will be good if I can get some hints on this issue. > > > > I think that trying to replace spi_sync with spi_async in mcp251x.c > is like trying to replace the engine in a car: it's better to know a > bit about engines and cars otherwise the result will be a disaster. > Obviously, I am not replacing spi_sync with spi_async only :) > That said it's a nice thing to rewrite the driver without the need of > deferred work (that is need by spi_sync) but be prepared to have a > rather complicated switch-based state machine to handle the > communications (I don't see other ways to do it). Think twice about > the various kinds of SPI drivers you will have beneath and how much > you will gain in performance and lose in term of interrupt latency of > the whole system. Especially the mcp2510 case will be quite > complicated. So I think you should post your code because it isn't > just a matter of "M-X replace-string spi_sync spi_async", otherwise we > cannot help. > I am trying to re-write (modify) driver's tx and rx processing paths _but_ initially doing most of the work (calling spi_async and others) from work-queue to avoid extra complications added from interrupt-contexts and completion function is doing only what is necessary (in xmit case its doing nothing although I tried to issue async write for TXREQ from here but that also resulted in crash). I will post code here asap as at the moment my modifications are still not finished on rx path and code needs cleanup before posting. > BTW: what motivates your work? > I already have async driver which is modified version of around 1-year old socket-can driver and works very well in our required work-load without dropping any packets as compare to synchronous driver. But the problem is: that driver don't do proper error handling especially in case of floating CAN-bus it just lock-down whole system due to its continuous interrupt processing (and crashes kernel if bus is attached to CAN device when system is locked). So now rather fixing that issue in old driver, I took latest svn-tree and trying to make it asynchronous. My current approach is to leave all the rx error processing as it is in work-handler but do normal-packets processing without deferring them. Any comment on this ? > -- > Christian Pellegrin, see http://www.evolware.org/chri/ > "Real Programmers don't play tennis, or any other sport which requires > you to change clothes. Mountain climbing is OK, and Real Programmers > wear their climbing boots to work in case a mountain should suddenly > spring up in the middle of the computer room." Thanks, -- Fawad Lateef _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
