christian pellegrin wrote:
> On Mon, Feb 1, 2010 at 8:19 AM, christian pellegrin <[email protected]> 
> wrote:

>> even with the MERR handling (but can you confirm this?). The first
>> thing that comes to my mind is using the standard netdev tx watchdog
>> to restart it, but I don't know it's an elegant solution.
> 
> After a second thought and after reading the chapter about one shot
> mode on a CAN book I've understood that this is mode is all about real
> time behavior. So I think it's better to give a precise control to the
> user of write syscall on when the packets can be send. So in
> CAN_ONE_SHOT_MODE frame transmit returns error until the TX buffer is
> free. There is no netif queue flow control, so a write in a busy loop
> can happily overload the system.

Hm. This is not really a 'usual' behaviour, people expect from socket
communication (or even from chardev drivers).

Especially OSM is "fire-and-forget" by design. Busy-Waiting on application
level for OSM messages looks strange to me. What would happen in multi-user
applications then?

> Unfortunately I don't see any other
> way to get a feedback in one shot mode after a lost arbitration (the
> basic problem is that the mcp2515 doesn't have a "tx buffer free"
> interrupt but a "frame txed" one) after studying the data sheet of the
> mcp can controller (message error could be trapped by MERR interrupt
> but lost of arbitration cannot).

As i understood the situation, you do not get any interrupt when the OSM
transmission fails on the bus, right?

Then i would tend to remove the OSM functionality as long as the driver is not
able to handle the descibed problem in OSM mode on the bus.

Regarding the missing tx interrupt the use of the "standard netdev tx timeout"
IMO could be the right approach to catch this *special* MCP251x problem. Btw.
there had been several "netdev tx timeout" issues on netdev-ML in the last
year and i don't know if "tx timeout" has a general problem or if there had
been changes in the timer infrastructure the drivers had to follow ...

Regards,
Oliver

> -                     netif_wake_queue(net);
> +                     if (!(priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)) {
> +                             netif_wake_queue(net);
> +                     }

Ugh! ;-)
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to