lkml.org 
[lkml]   [2017]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From
Date
On 10/19/2017 09:54 PM, Mario Hüttel wrote:
> On 10/19/2017 08:35 PM, Oliver Hartkopp wrote:

>> We already have this 'dsample-point' implemented in the ip tool:
>>
>> $ ip link set vcan0 type can help
>> Usage: ip link set DEVICE type can
>>     [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
>>     [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
>>        phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
>>
>>     [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] |  <<-- here!
>>     [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1
>>        dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ]
>>
>> But AFAIK m_can is not using that value in m_can_set_bittiming().
>>
> Actually I need some clarification. The sample point of the can core is
> between the two time segments.
> I always thought that the "sample point" options of the ip tool are used
> in the internal
> calculation of the two timing segments and is therefore no individual value.

You are right.

See picture at http://www.bittiming.can-wiki.info/

Usually you can give the bitrate and the sample point (which is at 75%
aka 0.750 by default) and then the kernel-internal bitrate calculating
algorithm calculates the tq prop-seg phase-seg1 phase-seg2 stuff.

Alternatively you can provide the tq prop-seg phase-seg1 phase-seg2
stuff on your own which is set to the CAN controller registers then.

For that reason my remark "m_can is not using that value" was wrong as
m_can just uses the tq prop-seg phase-seg1 phase-seg2 stuff - either
from the bitrate calculation or provided by the user.

Thanks for the question ;-)

Best,
Oliver

\
 
 \ /
  Last update: 2017-10-22 17:29    [W:0.438 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site