Hi Kurt,
Kurt Van Dijck wrote:
> On Tue, Apr 27, 2010 at 09:48:23AM +0200, Wolfgang Grandegger wrote:
>> Oliver Hartkopp wrote:
>>> Subhasish Ghosh wrote:
>>>
>>>> The CAN controller that I am using allows configuring per-mailbox IDs.
>>>> CAN being a broadcast network, this feature reduces the interrupts to
>>>> the processor.
>>>>
>>>> From Documentation/can.txt, what I understand is that the socketcan
>>>> interface does not provide any mechanism to configure the h/w for this
>>>> purpose (chapter 6.3).
>>>>
>>>> Instead, the h/w is configured to receive all identifiers and the
>>>> filtering is done on the stack (like ti_hecc.c) and to avoid hogging the
>>>> processor some interrupt mitigation techniques like NAPI is implemented.
>>>>
>>>> Isn't this a work around?
> I think the mailbox infrastructure is a workaround to sell CAN chips
> without the requirement for a decent software infrastructure :-)
It's mainly for systems based on micro-controllers or even less
intelligent logic.
> Can your CAN chip receive RTR frames and put them to software without the
> hardware transmitting something?
I remember heavy head and stomach ache while fighting with the i82527
long time ago.
...
>>> Having a generic CAN driver interface is one of the major motivations for
>>> SocketCAN. You really don't want to have hardware-specific ("N mailboxes")
>>> configuration interfaces which leads into a maintenance hell.
>> Yes, I also do not see a generic way yet to support per mailbox (or
>> message object) filtering.
> Ack.
>
> I've had some experience with the CAN chip within the c167 infineon cpu,
> which I
> believe is similar to the bosch cc770 can chip.
> Such setup with different 'mailboxes' only worked when there is a system-wide
> policy defined which CAN id go via which mailbox.
>
> a small piece of history:
> Before I found that such policy is _really_ required (although I found this
> nowhere
> in the datasheets), I ran into a race condition of the hardware (!).
> If you put (in that specific CAN chip) 2 different CANids in TX mailboxes,
> but whose
> CANids do match within the global receive mask, and the lowest CAN id is put
> in a
> mailbox after the higher(=lower priority on CAN) CANid, then the CAN chip
> would send
> the higher priority CAN id first (=good), but fails to find the correct TX
> mailbox
> in the CAN chip. Instead, it marks the first matched mailbox(= higher CAN id,
> which
> was not sent!) as transmitted. Subsequently, it finds the second mailbox
> (with the
> CANid that was just sent) as wanting transmission ......
>
> I'm not sure on the precise relationship between CAN id's, or how to configure
> the mailboxes (its about 8years ago).
> Anyway, I ended up in a CAN frame sent back to back because I used >1 TX
> mailbox.
>
> => rule 1: only use 1 tx mailbox.
Yes, and furthermore, full featured support for the i82527 is not really
possible.
...
>>> But please check if it's really needed and if you probably have a different
>>> view on the general approach of SocketCAN now.
>> Some kind of generic hardware filter support might be useful for some
>> corner cases, I think. Does anyone else find it useful?
> I have long stopped using hardware filters.
> Please note this is only my experience.
> If a decent netlink based mechanism would emerge, not affecting
> the software filters, and not trying to be intelligent, but just relaying
> a system wide policy into a CAN chip, then it would not hurt?
> And chips implementing it, could then at least measure their performance gain
> (and
> see if it was worth the effort). (This last issue could be measured with some
> quick sysfs properties too)
I agree, only some simple and general filtering does have a chance to
get accepted. Something which could be supported by most CAN controllers
is global filtering via global mask and id.
Wolfgang.
_______________________________________________
Socketcan-users mailing list
Socketcan-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-users
