On Sat, Jul 24, 2010 at 7:10 PM, Wolfgang Grandegger <[email protected]>wrote:
> On 07/24/2010 07:47 PM, Fawad Lateef wrote: > > Hello Everyone, > > > > Recently I spent long-time in rewriting and testing rx and tx processing > for > > mcp251x driver (especifically for AT91 and MCP2515) which now use > > Asynchronous mode in normal conditions which is fast and if there is some > > MERRF error then it switches to slow path which is Synchronous and later > > switch back fast/Async path when error condition is removed. Moreover it > > does bus recovery through restart-ms if BUS goes offline and this > continues > > till BUS becomes online. There isn't any sort of hanging in any case. > > > > On Sat, Jul 24, 2010 at 4:14 PM, Alexander Holler <[email protected] > >wrote: > > > >> Am 24.07.2010 17:01, schrieb Alexander Holler: > >> > >> > >> That doesn't help. The irq isn't trigger by MERR but the loop in the > IRQ > >>> will not be left if that bit is set. Clearing the bit doesn't help, > >>> either clearing it doesn't work, or the bit will get set again almost > >>> right after it was cleared. > >>> > >> > >> The datasheet says > >> > >> "Once an interrupt flag is set by the device, the flag can not be reset > by > >> the MCU until the interrupt condition is removed." > >> > >> So it's likely that this bit can' be cleared until the error has gone > away > >> (even if it isn't used as trigger). > >> > >> > >> Regards, > >> > >> Alexander > >> > > > > At the moment that driver code is very ugly thats why I haven't posted it > on > > mailing-list yet. On monday I can post it if someone want to test it > (kindly > > let me know); although I will post cleaned-up patch some time later. > > I'm curious why you did re-write the driver. Did you try the mcp251x > driver from the mainline kernel? What problems did you encounter? > > Thanks, > > Wolfgang. > I used latest socket-can from git (and I think this is same as the driver in latest kernel, right ?). I found that this synchronous driver is not giving performance according to our requirements and if bus is overloaded when generating packets from other CAN controller like from PEAK or CAN-Modul then system response to external events like ssh takes too much time in responding. Almost a year ago one of our engineer wrote Asynchronous driver using old mcp251x driver which performs very well, but error handling in that was very bad which lock-down the system. So recently referencing that Async driver I re-wrote tx and rx path (sort of merging our Async and latest Sync processing) in latest mcp251x driver from socket-can. Now till now everything is very well with modified driver. -- Fawad Lateef
_______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
