From: Oliver Hartkopp <socketcan@hartkopp.net>
To: "Vincent Mailhol" <mailhol@kernel.org>,
"Marc Kleine-Budde" <mkl@pengutronix.de>,
"Stéphane Grosjean" <stephane.grosjean@hms-networks.com>
Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
Robert Nawrath <mbro1689@gmail.com>,
linux-can@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] can: canxl: add CANXL_PMS flag
Date: Mon, 28 Jul 2025 20:14:22 +0200 [thread overview]
Message-ID: <64bf8703-c80c-4a96-a5ad-0efc48bf0541@hartkopp.net> (raw)
In-Reply-To: <20250729-can_tms-v1-1-21d0195d1dd0@kernel.org>
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@kernel.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@wanadoo.fr to
> mailhol@kernel.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,
next prev parent reply other threads:[~2025-07-28 18:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-28 16:23 Vincent Mailhol
2025-07-28 18:14 ` Oliver Hartkopp [this message]
2025-07-30 14:15 ` Vincent Mailhol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64bf8703-c80c-4a96-a5ad-0efc48bf0541@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mailhol@kernel.org \
--cc=mbro1689@gmail.com \
--cc=mkl@pengutronix.de \
--cc=stephane.grosjean@hms-networks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®