CAN-FD Transceiver Limitations

Hi All,

The various CAN transceivers I've seen that support CAN-FD appear to be
fairly limited in terms of their supported max speed. I've seen some
transceivers that only support upto 2 Mbps while others support up to  5
Mbps. This is a problem when the SoC's CAN IP can support even higher
values than the transceiver.

Ideally I would think the MCAN driver should at the very least know what
the maximum speed supported by the transceiver it is connected to.
Therefore, either throwing an error if a request for a speed above the
transceiver capability or lower the requested speed to what ever the
transceiver is capability of doing.

In either case I do not know if it makes sense to add a DT property
within the MCAN driver or create another subnode that contains this
information. For example I see some ethernet drivers support
"fixed-link" subnode which is trying to solve a similar issue. Should I
go with that approach? If so would it make sense to reuse fixed-link
even though majority of its properties aren't applicable? Or should I
create something similar such as fixed-can-transceiver?

On Wed, Jun 28, 2017 at 05:14:42PM -0500, Franklin S Cooper Jr wrote:

Hi All,

The various CAN transceivers I've seen that support CAN-FD appear to be
fairly limited in terms of their supported max speed. I've seen some
transceivers that only support upto 2 Mbps while others support up to  5
Mbps. This is a problem when the SoC's CAN IP can support even higher
values than the transceiver.

Ideally I would think the MCAN driver should at the very least know what
the maximum speed supported by the transceiver it is connected to.
Therefore, either throwing an error if a request for a speed above the
transceiver capability or lower the requested speed to what ever the
transceiver is capability of doing.

Hi Franklin

In either case I do not know if it makes sense to add a DT property
within the MCAN driver or create another subnode that contains this
information. For example I see some ethernet drivers support
"fixed-link" subnode which is trying to solve a similar issue.

Hi Franklin

I would say fixed-link is trying to solve a different issue. You use
fixed-link when you don't have a PHY connected to the Ethernet MAC. A
MAC driver will normally tell the PHY driver what speeds its supports,
and ask the PHY to negotiate a speed both the MAC and PHY supports
with the peer device. The MAC then gets told of the resulting speed.
If this PHY does not exist, you cannot ask it to perform auto-neg, you
have no idea what the peer is capable of. Hence you add a virtual PHY
using fixed-link, which always returns the same speed. This works
because if you don't have a PHY, the MAC is generally connected to
another MAC on the same board, typically an Ethernet switch. Hence the
speed is a board property and fixed.

You appear to have a different issue. I don't know the CAN
subsystem. Is the transceiver part of the model? Is there an API
between the CAN-MAC and the CAN-transceiver? It sounds like you need
to add an API call from the MAC driver to the transceiver driver to
ask it what it is capable of. I don't see this as being a DT property.
The transceiver should know its own capabilities. And you have to
think about non-DT systems, e.g. CAN devices on USB dongles.

      Andrew

Hi Andrew

On 06/29/2017 09:21 AM, Andrew Lunn wrote:

On Wed, Jun 28, 2017 at 05:14:42PM -0500, Franklin S Cooper Jr wrote:

quoted

Hi All,

The various CAN transceivers I've seen that support CAN-FD appear to be
fairly limited in terms of their supported max speed. I've seen some
transceivers that only support upto 2 Mbps while others support up to  5
Mbps. This is a problem when the SoC's CAN IP can support even higher
values than the transceiver.

Ideally I would think the MCAN driver should at the very least know what
the maximum speed supported by the transceiver it is connected to.
Therefore, either throwing an error if a request for a speed above the
transceiver capability or lower the requested speed to what ever the
transceiver is capability of doing.

Hi Franklin

quoted

In either case I do not know if it makes sense to add a DT property
within the MCAN driver or create another subnode that contains this
information. For example I see some ethernet drivers support
"fixed-link" subnode which is trying to solve a similar issue.

Hi Franklin

I would say fixed-link is trying to solve a different issue. You use
fixed-link when you don't have a PHY connected to the Ethernet MAC. A
MAC driver will normally tell the PHY driver what speeds its supports,
and ask the PHY to negotiate a speed both the MAC and PHY supports
with the peer device. The MAC then gets told of the resulting speed.
If this PHY does not exist, you cannot ask it to perform auto-neg, you
have no idea what the peer is capable of. Hence you add a virtual PHY
using fixed-link, which always returns the same speed. This works
because if you don't have a PHY, the MAC is generally connected to
another MAC on the same board, typically an Ethernet switch. Hence the
speed is a board property and fixed.

You appear to have a different issue. I don't know the CAN
subsystem. Is the transceiver part of the model? Is there an API
between the CAN-MAC and the CAN-transceiver? It sounds like you need
to add an API call from the MAC driver to the transceiver driver to
ask it what it is capable of. I don't see this as being a DT property.
The transceiver should know its own capabilities. And you have to
think about non-DT systems, e.g. CAN devices on USB dongles.

Transceivers for CAN are not apart of any model. Traditional CAN didn't
have a problem because all transceivers from my understanding supported
the maximum speed of 1 Mbps defined by the spec. However, with the
introduction of CAN Flexible Datarate mode it seems that for
transceivers that supported CAN-FD the maximum supported speeds vary.

Unfortunately, their is no way to communicate with the transceiver to
understand its capabilities. You don't program it or configure a
transceiver. It simply has a fixed configuration. Now that I think of it
you also can't determine if the transceiver supports CAN-FD in the first
place. IP that supports CAN-FD is backwards compatible with standard
CAN. Therefore, its feasible that you may even use a transceiver that
doesn't support CAN-FD. So I would think something like the below would
be needed.

mcan@0 {
	...
	fixed-transceiver {
	      max-canfd-speed = <2000>
	};
	...
};

So the mcan driver can then check for this subnode and if found read in
the max canfd speed that is supported. A value of 0 could be used to
indicate that CAN-FD isn't supported by the transceiver.

      Andrew

Transceivers for CAN are not apart of any model. Traditional CAN didn't
have a problem because all transceivers from my understanding supported
the maximum speed of 1 Mbps defined by the spec. However, with the
introduction of CAN Flexible Datarate mode it seems that for
transceivers that supported CAN-FD the maximum supported speeds vary.

So transceivers are dumb devices, nothing to configure, so no need to
have a driver for them.

Now that I think of it
you also can't determine if the transceiver supports CAN-FD in the first
place. IP that supports CAN-FD is backwards compatible with standard
CAN. Therefore, its feasible that you may even use a transceiver that
doesn't support CAN-FD. So I would think something like the below would
be needed.

mcan@0 {
	...
	fixed-transceiver {
	      max-canfd-speed = <2000>
	};
	...
};

Are there likely to be other transceiver properties? Adding a subnode
may not make sense if this is going to be the only property.

Also, 2KHz is not very fast :-)

Taking a quick look in Documentation/devicetree/bindings/net/can, it
seems a bit of a wild west. No standardization, no central binding
which CAN drivers are expected to support, etc. This sounds like a
generic problem, not an mcan problem. So document this property
centrally, implement the parsing of it centrally, etc, to encourage
other CAN drivers to use it, rather than re-invent the wheel.

	   Andrew

+device tree mailing list

Hi Andrew
On 06/29/2017 10:41 AM, Andrew Lunn wrote:

quoted

Transceivers for CAN are not apart of any model. Traditional CAN didn't
have a problem because all transceivers from my understanding supported
the maximum speed of 1 Mbps defined by the spec. However, with the
introduction of CAN Flexible Datarate mode it seems that for
transceivers that supported CAN-FD the maximum supported speeds vary.

So transceivers are dumb devices, nothing to configure, so no need to
have a driver for them.

quoted

Now that I think of it
you also can't determine if the transceiver supports CAN-FD in the first
place. IP that supports CAN-FD is backwards compatible with standard
CAN. Therefore, its feasible that you may even use a transceiver that
doesn't support CAN-FD. So I would think something like the below would
be needed.

mcan@0 {
	...
	fixed-transceiver {
	      max-canfd-speed = <2000>
	};
	...
};

Are there likely to be other transceiver properties? Adding a subnode
may not make sense if this is going to be the only property.

Also, 2KHz is not very fast :-)

Taking a quick look in Documentation/devicetree/bindings/net/can, it
seems a bit of a wild west. No standardization, no central binding
which CAN drivers are expected to support, etc. This sounds like a
generic problem, not an mcan problem. So document this property
centrally, implement the parsing of it centrally, etc, to encourage
other CAN drivers to use it, rather than re-invent the wheel.

As of now its the only property that I think is needed. In general from
past experience and threads it seems that people are fairly adamant
about having DT mimic hardware as closely as possible. So since from a
hardware perspective the transceiver is an external device that is
connected to the CAN IP it would make sense for a subnode to be used to
model it. But either way works for me. If the device tree folks do not
care for subnode to be created then I can just add a property.

Also I agree that attempting to make this optional property/subnode
generic to all of CAN would be preferable. Another not sure if its
feasible yet without standardization being first forced across all CAN
drivers.

	   Andrew

Also I agree that attempting to make this optional property/subnode
generic to all of CAN would be preferable. Another not sure if its
feasible yet without standardization being first forced across all CAN
drivers.

It should be. All you need to do is add an
of_get_can_maxspeed(struct device_node *np)
for drivers to call.

If it finds the property, return its value, otherwise return the
standardised 1Mbps.

And you probably want to do the verify in can_changelink(), by adding
the max speed into the can_priv structure somewhere.

    Andrew

quoted

quoted

mcan@0 {
	...
	fixed-transceiver {
	      max-canfd-speed = <2000>
	};
	...
};

Since when would a transceiver support different speeds for CAN & CANFD?
No transceivers were available, but they are now.
I see no datalink problem applying 2MBit for regular CAN with apropriate
physical layer, and CAN does not predefine the physical layer
(advise != define).

IMHO,
	fixed-transceiver {
		max-arbitration-speed = <2000000>
		max-data-speed = <4000000>
	};
is way better to describe the hardware.
Regular CAN chips would not consider max-data-speed...

Kind regards,
Kurt

On 06/29/2017 05:41 PM, Andrew Lunn wrote:

quoted

Transceivers for CAN are not apart of any model. Traditional CAN didn't
have a problem because all transceivers from my understanding supported
the maximum speed of 1 Mbps defined by the spec. However, with the
introduction of CAN Flexible Datarate mode it seems that for
transceivers that supported CAN-FD the maximum supported speeds vary.

So transceivers are dumb devices, nothing to configure, so no need to
have a driver for them.

Yes and no.

CAN transceivers are usually quite dumb, but most of them have some sort
of "enable" pin. This pin is currently modelled as a regulator. Which
fits nicely, as there dual transceivers with only one enable pin.

However there are more complicated transceivers with two pins, that
implement a state machine, where you can query the chip for various
error conditions and can configure remote wakeup, etc... So in the
future a proper driver might be implemented.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |