Messages in this thread | | | Subject | Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates | From | Oliver Hartkopp <> | Date | Thu, 19 Oct 2017 22:17:11 +0200 |
| |
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
| |