Re: can problems on socfpga [was Re: [PATCH v2 4/6] ARM: socfpga: dts: add can0+1]

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 26.04.2014 22:31, Pavel Machek wrote:
> On Sat 2014-04-26 11:36:46, Pavel Machek wrote:
>> Hi!
>>
>>> To get this working well, I had to install a few of the patches that
>>> Benedict Spranger submitted ([PATCH 05/16] c_can: use 32 bit access for
>>> D_CAN) on 9/9/2013.
>>>
>>> I have the patches on our rocketboard branch
>>> (rocketboards.org/gitweb/?p=linux-socfpga-git;a=summary)
>>>
>>> I planned to upstream these changes but there have been some major
>>> changes to CAN recently that may require some refactoring.
>>
>> I ported those changes to 3.15-rc2 (but can't test them at the
>> moment).
> 
> Ok, it seems it is possible to test CAN without actual can hardware
> using loopback:
> 
> ip link set can0 up type can bitrate 125000 loopback on
> ifconfig can0 up
> candump can0 &
> cansend can0 "123#DEADBEEF"
> 
> Moreover, it seems that previous two patches do the trick. Packets are
> now echoed as expected. (Ok, small question is "why twice", but I
> guess that's just CAN...?)

Usually the CAN frame is echo'ed back when the CAN frame is successfully sent
on the medium (tx ok interrupt, see: echo skb functionality in
drivers/net/can/dev.c and in can.txt for multiuser capabilites).

The second CAN frame is obviouly created by some rx interrupt which occurs due
to the loopback functionality inside the C_CAN controller - which is usually
not enabled.

So it's a correct behaviour.

Best regards,
Oliver

> 
> root@sockit:~# ip link set can0 up type can bitrate 125000 loopback on
> c_can_platform ffc00000.d_can can0: setting BTR=1c31 BRPE=0000
> root@sockit:~# ifconfig can0 up
> root@sockit:~# candump can0 &
> root@sockit:~# cansend can0 "123#DEADBEEF"
>   can0  123   [4]  DE AD BE EF
>   can0  123   [4]  DE AD BE EF
> root@sockit:~# 
> 
> Best regards,
> 								Pavel
>