Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2477753pxj; Sat, 19 Jun 2021 13:37:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhdVG0SHq8gxRQO9UjBU0vpp5RYPJTlGm/e54QoCHX548RledSaUd5d8wCBRupTennk0Cq X-Received: by 2002:a5d:8242:: with SMTP id n2mr13587413ioo.198.1624135034185; Sat, 19 Jun 2021 13:37:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624135034; cv=none; d=google.com; s=arc-20160816; b=ceTbgDUaKucnzW2aGlpVff6pYBZnfoSA7Yj7HpBqIRQcU9z70l+j3kcSmu3eOBw/kF cCPq/9qeMVNztZhGgwVdwI5I/xUT6DFbvExlt4OgqvHfNeo5rHZYdxcR2RE+0fLsYUoA PcnDZLTNNkQRfPwhl0Ovb11zUJc5saofyE8DvzWr1/2CJOqj3Eklxyzpz6DkbjQVMY40 cO3/i6wgBI7jG48dgJ50hAHf7CdHa61Z1S9nWeh+4bjEPlbAvvZCvUHU1wIaR9hpMoYh nvi9kv9KvBfVlCiElCtTFfM2vcmpm5oCdUtir7OVq6wLzAiZzgNamn0V7NI/RkgboFaZ 6SPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=iZW6Zpj0RS7GgzSmosFJHa7lEYP0RhRLyukHmUW8wKI=; b=luRL116Ss36Y4tFeHyHBWI95eppuxsvehyuw7UXmcPgk3MM1UnvG44uXqvk9CPe7rT Cu/JffbnWDYxeHTLJUmMGPraskVa+TwqswL3Jy0mttAZ/wWo+H8k/+u0WaNPPwuCie53 VyxWu70sDqrLoKik893rAvPCS3lCmX8mZyv0oHrGqRL1I5YG7OT08hkLHetJuTYowdCG Fsn1eO0+wfNpmkr//Y+1S7pt5B+R2MUvIMlmhOMC+CqFpnYBBqgwpb7vsDTU0bP8+qFc dY4VJrSAItw8SG/fh6YGPJDMpV3S4yFzq9ZlmjzZBEl5IympZ31MhY5JZRUA0yvqKO/N upbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 15si7752904ilz.158.2021.06.19.13.37.01; Sat, 19 Jun 2021 13:37:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234172AbhFSMhO convert rfc822-to-8bit (ORCPT + 99 others); Sat, 19 Jun 2021 08:37:14 -0400 Received: from mail-lj1-f175.google.com ([209.85.208.175]:44791 "EHLO mail-lj1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234148AbhFSMhN (ORCPT ); Sat, 19 Jun 2021 08:37:13 -0400 Received: by mail-lj1-f175.google.com with SMTP id d2so17970549ljj.11; Sat, 19 Jun 2021 05:35:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6I2FWb7mQ/8/cNGUfD+T2KExB3NTxaQoGVuBZhhJFdQ=; b=igiULZhtz8+3FMj25Zp6CXmJ/V6kvf/DZPLj3RYStiKHeIQzlqIfutyIqUIcm69tW3 gQDXq6ui0fRKP7aLtsRsKy8fL7oVWjBip+ROOml6q7WOcktzYjnCOpNUP9XbCPAYPsmc mSJzSYW0ZiwDg5wvHiStlAb/s9RuhB/DIoZ1vHT872ceQ9QDsNuVA5w0+fCq2klHRTl2 Fds+ebDgCNbFQ7hlKUtzFERlUsrqQ9o1DLrubKvgZHYXXjZYTAlOCEj0YPUERSZJfJ7Q XEg16Hj5UIaUcoxNBWwTnmiAmTnVImULF1QPUcXeI7BrubkqyEdsxowR+aWhyOkWoSRb yPgg== X-Gm-Message-State: AOAM530cXQRzW00H2PI2459ykBpszNUQ7Ko5dGQBlrFjbKm7OWRGOD+5 ctxbmpUUcYuYaNqRBIzpK4qYMztl0LTIHjeyX2w= X-Received: by 2002:a2e:8699:: with SMTP id l25mr13273570lji.315.1624106100118; Sat, 19 Jun 2021 05:35:00 -0700 (PDT) MIME-Version: 1.0 References: <20210603151550.140727-1-mailhol.vincent@wanadoo.fr> <20210603151550.140727-3-mailhol.vincent@wanadoo.fr> <20210618093424.xohvsqaaq5qf2bjn@pengutronix.de> <20210618124447.47cy7hyqp53d4tjh@pengutronix.de> In-Reply-To: From: Vincent MAILHOL Date: Sat, 19 Jun 2021 21:34:50 +0900 Message-ID: Subject: Re: CAN-FD Transmitter Delay Compensation (TDC) on mcp2518fd To: =?UTF-8?Q?Stefan_M=C3=A4tje?= Cc: "mkl@pengutronix.de" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-can@vger.kernel.org" , "socketcan@hartkopp.net" , "thomas.kopp@microchip.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat. 19 Jun 2021 à 00:55, Stefan Mätje wrote: > Am Freitag, den 18.06.2021, 23:27 +0900 schrieb Vincent MAILHOL: > > On Fri. 18 Jun 2021 at 21:44, Marc Kleine-Budde wrote: > > > On 18.06.2021 20:17:51, Vincent MAILHOL wrote: > > > > > > I just noticed in the mcp2518fd data sheet: > > > > > > > > > > > > > bit 14-8 TDCO[6:0]: Transmitter Delay Compensation Offset bits; > > > > > > > Secondary Sample Point (SSP) Two’s complement; offset can be > > > > > > > positive, > > > > > > > zero, or negative. > > > > > > > > > > > > > > 011 1111 = 63 x TSYSCLK > > > > > > > ... > > > > > > > 000 0000 = 0 x TSYSCLK > > > > > > > ... > > > > > > > 111 1111 = –64 x TSYSCLK > > > > > > > > > > > > Have you takes this into account? > > > > > > > > > > I have not. And I fail to understand what would be the physical > > > > > meaning if TDCO is zero or negative. > > > > > > The mcp25xxfd family data sheet says: > > > > > > > SSP = TDCV + TDCO > > > > > TDCV indicates the position of the bit start on the RX pin. > > > > > > If I understand correctly in automatic mode TDCV is measured by the CAN > > > controller and reflects the transceiver delay. > > > > Yes. I phrased it poorly but this is what I wanted to say. It is > > the delay to propagate from the TX pin to the RX pin. > > > > If TDCO = 0 then SSP = TDCV + 0 = TDCV thus the measurement > > occurs at the bit start on the RX pin. > > > > > I don't know why you want > > > to subtract a time from that.... > > > > > > The rest of the relevant registers: > > > > > > > TDCMOD[1:0]: Transmitter Delay Compensation Mode bits; Secondary Sample > > > > Point (SSP) > > > > 10-11 = Auto; measure delay and add TDCO. > > > > 01 = Manual; Do not measure, use TDCV + TDCO from register > > > > 00 = TDC Disabled > > > > > > > > TDCO[6:0]: Transmitter Delay Compensation Offset bits; Secondary Sample > > > > Point (SSP) > > > > Two’s complement; offset can be positive, zero, or negative. > > > > 011 1111 = 63 x TSYSCLK > > > > ... > > > > 000 0000 = 0 x TSYSCLK > > > > ... > > > > 111 1111 = –64 x TSYSCLK > > > > > > > > TDCV[5:0]: Transmitter Delay Compensation Value bits; Secondary Sample > > > > Point (SSP) > > > > 11 1111 = 63 x TSYSCLK > > > > ... > > > > 00 0000 = 0 x TSYSCLK > > > > Aside from the negative TDCO, the rest is standard stuff. We can > > note the absence of the TDCF but that's not a blocker. > > > > > > > If TDCO is zero, the measurement occurs on the bit start when all > > > > > the ringing occurs. That is a really bad choice to do the > > > > > measurement. If it is negative, it means that you are measuring the > > > > > previous bit o_O !? > > > > > > I don't know... > > > > > > > > Maybe I am missing something but I just do not get it. > > > > > > > > > > I believe you started to implement the mcp2518fd. > > > > > > No I've just looked into the register description. > > > > OK. For your information, the ETAS ES58x FD devices do not allow > > the use of manual mode for TDCV. The microcontroller from > > Microchip supports it but ETAS firmware only exposes the > > automatic TDCV mode. So it can not be used to test what would > > occur if SSP = 0. > > > > I will prepare a patch to allow zero value for both TDCV and > > TDCO (I am a bit sad because I prefer the current design, but if > > ISO allows it, I feel like I have no choice). However, I refuse > > to allow the negative TDCO value unless someone is able to > > explain the rationale. > > Hi, > > perhaps I can shed some light on the idea why it is a good idea to allow > negative TDC offset values. Therefore I would describe the TDC register > interface of the ESDACC CAN-FD controller of our company (see > https://esd.eu/en/products/esdacc). Thanks for joining the conversation. I am happy to receive help from more experts! > Register description of TDC-CAN-FD register (reserved bits not shown): > > bits [5..0], RO: TDC Measured (TDCmeas) > Currently measured TDC value, needs baudrate to be set and CAN traffic > > bits [21..16], R/W: TDC offset (TDCoffs) > Depending on the selected mode (see TDC mode) > - Auto TDC, automatic mode (default) > signed offset onto measured TDC (TDCeff = TDCmeas + TDCoffs), > interpreted as 6-bit two's complement value > - Manual TDC > absolute unsigned offset (TDCeff = TDCoffs), > interpreted as 6-bit unsigned value > - Other modes > ignored > In either case TDC offset is a number of CAN clock cycles. > > bits [31..30], R/W: TDC mode > 00 = Auto TDC > 01 = Manual TDC > 10 = reserved > 11 = TDC off First remark is that you use different naming than what I witnessed so far in other datasheets. Let me try to give the equivalences between your device and the struct can_tdc which I proposed in my patches. The Left members are ESDACC CAN-FD registers, the right members are variables from Socket CAN. ** Auto TDC ** TDCoffs = struct can_tdc::tdco ** Manual TDC ** TDCoffs = struct can_tdc::tdcv + struct can_tdc::tdco In both cases, TDCeff corresponds to the SSP position. > So in automatic mode the goal is to be able to move the real sample point > forward and(!) backward from the measured transmitter delay. Therefore the > TDCoffs is interpreted as 6-bit two's complement value to make negative offsets > possible and to decrease the effective (used) TDCeff below the measured value > TDCmeas. > > As far as I have understood our FPGA guy the TDCmeas value is the number of > clock cycles counted from the start of transmitting a dominant bit until the > dominant state reaches the RX pin. Your definition of TDCmeas is consistent with the definition of TDCV in socket CAN. What I miss to understand is what does it mean to subtract from that TDCmeas/TDCV value. If you subtract from it, it means that TDCeff/SSP is sampled before the signal reaches the RX pin. Correct? > During the data phase the sample point is controlled by the tseg values set for > the data phase but is moved additionally by the number of clocks specified by > TDCeff (or SSP in the mcp2518fd case). Here I do not follow you. The SSP, as specified in ISO 11898-1 is "specified by its distance from the start of the bit time". Either you do not use TDC and the measurement is done on the SP according to the tseg values, either you do use TDC and the measurement is done on the SSP according to the TDC values. There is no mention of mixing the tseg and tdc values. P.S.: don't hesitate to invite your FPGA guy to this thread! Yours sincerely, Vincent