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 :-)
Can your CAN chip receive RTR frames and put them to software without the
hardware transmitting something?
> >
> >
> > No it's not.
> >
> > Remember that you're working in a multi-user system now, and therefore it's
> > not defined what all of your user-apps need from the specific CAN bus.
> >
> > For that reason the implementation of efficient filters is done in the
> > soft-IRQ that's called right after the (hard-) interrupt routine of the CAN
> > driver.
> >
> > 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.
As oliver mentioned, different applications may need different filters on the
mailbox.
If 2 applications use different filters, you cannot tell if a frame that
matched the
first filter would not match the second. So, software filtering is still
required.
The existing software filters are, IMO, way more powerfull that what I have
seen from
hardware filters.
=> rule 2: use software filtering.
>
> >> My question is, did I miss something, is there any way to configure the
> >> h/w for this purpose. Is it a good idea if I cook up a sysfs interface
> >> for my driver for this.
> >
> >
> > The problem is, that a filtering on driver level affects *every* user in the
> > system.
>
> Yes, messages rejected by hardware filters are lost.
>
> > So far no one discovered a problem with the irq-load of CAN drivers in his
> > system. We've been running a 133MHz PowerPC with four SJA1000 controllers
> > for
> > years ...
>
> Interrupt load might be an issue, especially on load end systems.
>
> > If you really(!) get into problems, we should discuss a netlink
> > configuration
> > option for driver-level CAN-ID filtering (also abstracted from "mailboxes").
>
> Yes.
>
> > 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)
>
> Wolfgang.
Kurt
> _______________________________________________
> Socketcan-users mailing list
> Socketcan-users@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/socketcan-users
_______________________________________________
Socketcan-users mailing list
Socketcan-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-users
