Message-ID: <64bf8703-c80c-4a96-a5ad-0efc48bf0541@hartkopp.net>
Date: Mon, 28 Jul 2025 20:14:22 +0200
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Vincent Mailhol <mailhol@...nel.org>,
 Marc Kleine-Budde <mkl@...gutronix.de>,
 Stéphane Grosjean <stephane.grosjean@...-networks.com>
Cc: Vincent Mailhol <mailhol.vincent@...adoo.fr>,
 Robert Nawrath <mbro1689@...il.com>, linux-can@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] can: canxl: add CANXL_PMS flag

Hi Vincent,

On 28.07.25 18:23, Vincent Mailhol wrote:
> The Transceiver Mode Switching (TMS) indicates whether the CAN XL
> controller shall use the PWM or NRZ encoding during the data phase.
> 
> Contrarily to CAN FD's BRS flag, CAN XL does not have an explicit bit
> on the bus to indicate the TMS. Instead, this is done implicitly: the
> transceiver will automatically detect TMS on the fly if the frequency
> on the ADH bit is higher than the nominal frequency and this until the
> DAH bit on which the frequency returns to back normal. For this
> reason, the TMS is something which, same as the BRS, should be
> configurable at the frame level and not at the netlink level.
> 
> The term "transceiver mode switching" is used in both ISO 11898-1 and
> CiA 612-2 (although only the latter one uses the abbreviation TMS). We
> adopt the same naming convention here for consistency.
> 
> Add the CANXL_TMS flag to the canxl_frame->flags list.
> 
> Signed-off-by: Vincent Mailhol <mailhol@...nel.org>
> ---
> The CAN XL did not make it on time for the 6.17 merge windows, sorry
> for that.

Yes. I'm a bit sad about that.

> Regardless, I finally went through the CiA 612-2 document. I
> have the PWM verification and automatic calculation working fine
> locally.
> 
> But before that, I want to sort out this TMS thing. That is why I am
> sending this unique patch. Once this discussion reaches an end, I will
> fine tune my work-in-progress accordingly.
> 
> Looking at the past exchanges, this TMS was the missing piece. I was
> already troubled by this when reading ISO 11898-1. That document makes
> it clear that the TMS can be deactivated but does not clearly point
> out at which level (netlink or frame). The CiA 612-2 clarified this.
> 
> So this CANXL_TMS flag partially replaces the CAN_CTRLMODE_XL_TRX. I
> say partially because I still do not fully understand if there should
> be an option to fully deactivate the TMS at the netlink level.
> 
> My gut felling is that the TMS is intended to work in a similar
> fashion as the CAN FD's BRS. In CAN FD, we do not have a
> CAN_CTRLMODE_FD_BRS to tell that FD should operate only using the
> nominal bittiming. And so, I do not get why CAN XL should be different
> and have a CAN_CTRLMODE_XL_TMS (or CAN_CTRLMODE_XL_TRX).
> 
> Stéphane and Oliver: maybe the datasheet of your CAN XL board have
> some additional insights? Did you see a register allowing to globally
> deactivate the TMS (i.e. not only at the frame level)?

You can take a look at the XCAN manual 
https://github.com/linux-can/can-doc/blob/master/x_can/xcan_user_manual_v350.pdf

And I have a XCANB specification which is a simple (non-DMA) CAN XL 
controller.

The TMS switching is only possible in netlink level and there's no 
TMS-style bit in the CAN XL frame layout that is pushed into the 
controller to send a CAN XL frame => there is not TMS-bit analogue to 
the BRS-bit your were searching for.

Therefore this patch is obsolete.

Btw. while we are at it: I would suggest for a name change of

CAN_CTRLMODE_XL_TRX

to

CAN_CTRLMODE_XL_TMS

as it makes clear how the controller should manage the PWM mode.

"CAN_CTRLMODE_XL_TRX" would mean "there is a CAN XL PWM enabled 
transceiver" available which tells nothing about whether the PWM mode is 
used or not.

Best regards,
Oliver

> 
> Finally, on a side not, now that I have my kernel.org account, I am
> changing my e-mail address from mailhol.vincent@...adoo.fr to
> mailhol@...nel.org. 

Nice!

> The wanadoo.fr address was my first email which I
> created when I was a kid and have a special meaning to me, but it is
> restricted to maximum 50 messages per hour which starts to be
> problematic on threads with many people CC-ed.
> ---
>   include/uapi/linux/can.h | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
> index 42abf0679fb4854cfa4f29a575e49527461a20f3..4a81500c1a06a69707accbf66224da7285d9d282 100644
> --- a/include/uapi/linux/can.h
> +++ b/include/uapi/linux/can.h
> @@ -193,6 +193,7 @@ struct canfd_frame {
>   #define CANXL_XLF 0x80 /* mandatory CAN XL frame flag (must always be set!) */
>   #define CANXL_SEC 0x01 /* Simple Extended Content (security/segmentation) */
>   #define CANXL_RRS 0x02 /* Remote Request Substitution */
> +#define CANXL_TMS 0x04 /* Transceiver Mode Switching (fast mode using PWM encoding) */
>   
>   /* the 8-bit VCID is optionally placed in the canxl_frame.prio element */
>   #define CANXL_VCID_OFFSET 16 /* bit offset of VCID in prio element */
> 
> ---
> base-commit: fa582ca7e187a15e772e6a72fe035f649b387a60
> change-id: 20250727-can_tms-4bd8510bc9ce
> 
> Best regards,

Powered by blists - more mailing lists