Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Oliver Hartkopp]

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