Re: [PATCH 0/8] RFC: more flexcan cleanups and SW FIFO IRQ offloading

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

On 09/03/2015 10:17 AM, Tom Evans wrote:
> On 03/09/15 16:58, Marc Kleine-Budde wrote:
>> On 09/03/2015 08:32 AM, David Jander wrote:
>>>>> this series adds a software FIFO implementation and switches
> 
> Thank you both for explaining that.
> 
> It seems fairly bulletproof as long as it doesn't overflow. There are 64 
> buffers, so 32 in the first half, so that handles a 1.5ms interrupt latency.
> 
> A shame Freescale didn't think of that method instead of requiring the driver 
> run quicksort somewhere.
> 
>  > In an atomic operation, the MB's that have been served are
>  > now disabled.
> 
> That's the sort of tricky operation that exposes nasty silicon bugs. I'd 
> suggest that this mode be made easy to turn off in case some chip variant has 
> a problem like htis.

This mode is only enabled on imx6, vybid and newer, as all the other
cores cannot receive RTR frames in the non FIFO mode.

> This feature looks to be enabled as a "QUIRK" of the CPU.

The quirk to enable the non FIFO mode, a.k.a. SW_FIFO is called
FLEXCAN_QUIRK_USE_SW_FIFO. See patch 7/8 where it is enabled on imx6 and
vybrid.

> In an old generation kernel this might be optionally enabled in the .config 
> file, as NAPI is in the 2.6.35 FEC drivers I'm stuck with using at the moment 
> on the i.MX53. In the current kernel, could this mode of operation (and/or 
> hardware FIFO using NAPI) be made configurable in the Device Tree instead?

Since 4.0 or something you really want to use NAPI, otherwise the order
of the packages is not guaranteed by the networking stack. So in both
case we use NAPI, but read the CAN frames in the hard IRQ context.
Either with the traditional FIFO (on that powerpc, imx25, imx35, imx53
and imx28) or the non-FIFO mode (imx6, vybrid).

With the current implementation, when enabling FLEXCAN_QUIRK_USE_SW_FIFO
on mx28, the controller doesn't receive RTR and extended CAN frames. RTR
is a known issue for the older cores, whie extended frames is probably a
configuration issue.

Given that the extended frame issue is fixed, you might want to
sacrifice RTR reception (because you don't need it) for bigger buffers
you can either patch the driver (adding the FLEXCAN_QUIRK_USE_SW_FIFO),
add a device tree option (convince the reviewers that this not a
confiuration option but a hardware description) or make it a new
CAN_CTRLMODE, so that it can be configured from the userspace.

According to the documentation both the normal FIFO and the mailboxes
can be used for RX at the same time, we can try to setup filters, so
that the FIFO is used for RTR messages only, while the normal mailboxes
are used for the non RTR messages. In order to merge these two together
we probably need to evaluate the timestamps.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]