[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f916786-7a91-9265-7b43-635d022c61ab@hartkopp.net>
Date: Thu, 19 Oct 2017 22:17:11 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Mario Hüttel <mario.huettel@....net>,
Marc Kleine-Budde <mkl@...gutronix.de>,
Sekhar Nori <nsekhar@...com>,
Franklin S Cooper Jr <fcooper@...com>,
"Yang, Wenyou" <Wenyou.Yang@...rochip.com>, wg@...ndegger.com,
quentin.schulz@...e-electrons.com, edumazet@...gle.com,
linux-can@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Wenyou Yang <wenyou.yang@...el.com>,
Dong Aisheng <b29396@...escale.com>,
"Quadros, Roger" <rogerq@...com>
Subject: Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
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
Powered by blists - more mailing lists