can: flexcan: Ancient Freescale Reference FlexCAN Driver and bug fixes so it works.
mkl at pengutronix.de
Thu Dec 10 04:44:20 PST 2015
On 12/10/2015 12:44 PM, Tom Evans wrote:
> I've just had to delve back into the deep murky past and try to get
> Freescale's Kernel 2.6.35 FlexCAN driver working. That's because the
> only code base that supports Freescale's Video Hardware is that one and
> we need working video.
2.6.x I feel your pain. Another option would be to port the flexcan
driver to that old kernel. But I'm getting off topic here :)
> I'm suggesting this code as an "historical reference" that might be
> useful for anyone looking for simple/simplistic ways to handle a FlexCAN
> port. It isn't like the driver actually works fully. It can't have ever
> been tested very much. Which is why I've had to fix it.
> It has the Driver, Register handling and Message Buffer handling split
> into three separate source files, which is a useful simplification.
> It can't be configured with "canconfig", but exposes a huge number of
> variables in the sysfs which is actually quite powerful and extendable.
> Freescale's "2.6.35_maintain" kernel consists of 2.6.35 plus about 1200
> Freescale patches which basically replace all the hardware drivers.
> The source for this driver in this tree (until someone renames it to NXP):
> The Driver is in the expected place:
> 1 - It defaults to 32 receive and 32 transmit MBs, but that can be changed.
> 2 - It can't receive in order, but you'd only need to sort on the
> timestamps to fix that (or use the FIFO).
In order reception is crucial.
> 3 - It can't transmit in order either (unless you drop it to one
> transmit MB), but a simple change to the Transmit MB assignment would
> fix that.
> 4 - It supports FIFO mode, but it doesn't work at all. The FIFO hardware
> gets so badly screwed by the driver that it has to be power-cycled to
> get it working again.
> 5 - Transmit doesn't work either. If you push it it'll start sending ONE
> Message per SECOND. That's an easy fix by changing the code to actually
> unblock the netif queue instead of what it does.
> 6 - The sysfs variable that reserves receive message buffers is named to
> reserve transmit buffers, it messes up if the DLC is over 8 (because it
> doesn't call get_can_dlc()), the Dump routines don't work properly,
> off-by-one bug, comparison-reversal bug and so on.
> 7 - The only good thing about it is that it doesn't use NAPI, so when
> fixed it doesn't drop messages when you try to use MMC/eMMC/ESDHC.
> FIFO bug documented and fixed here:
> Transmit bug documented and fixed here (and the other ones listed), also
> MMC/eMMC problem:
> Patches to fix all of it on the end of this thread:
If there's interest in working with this prehistoric kernel, why isn't
there anyone that picks up all the patches and add them to a git repo.
fsl doesn't seem to care either, maybe unless you're using their newest
just my 2¢,
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 |
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: OpenPGP digital signature
More information about the linux-arm-kernel