CAN-FD Transceiver Limitations

CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

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?

CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

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?

Re: CAN-FD Transceiver Limitations

[Andrew Lunn]

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

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

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:
>> 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.

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
> 

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

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:
>> 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.

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
> 

Re: CAN-FD Transceiver Limitations

[Andrew Lunn]

> 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

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

+device tree mailing list

Hi Andrew
On 06/29/2017 10:41 AM, Andrew Lunn wrote:
>> 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.

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
> 

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

+device tree mailing list

Hi Andrew
On 06/29/2017 10:41 AM, Andrew Lunn wrote:
>> 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.

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
> 

Re: CAN-FD Transceiver Limitations

[Andrew Lunn]

> 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

Re: CAN-FD Transceiver Limitations

[Kurt Van Dijck]

> >>
> >> 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

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>>>
>>>> mcan@0 {
>>>> 	...
>>>> 	fixed-transceiver {
>>>> 	      max-canfd-speed = <2000>
>>>> 	};
>>>> 	...
>>>> };
> 
> Since when would a transceiver support different speeds for CAN & CANFD?

When I say CAN I'm referring to CAN 2.0 specification which mentioned
speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.

> 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...

What is arbitration speed?

Also if I understand you correctly then I agree drivers for traditional
CAN wouldn't care about this subnode. Although it may be helpful for
max-data-speed to become max-canfd-speed or something along those lines.
Just so the property's purpose is clear.
> 
> Kind regards,
> Kurt
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>>>
>>>> mcan@0 {
>>>> 	...
>>>> 	fixed-transceiver {
>>>> 	      max-canfd-speed = <2000>
>>>> 	};
>>>> 	...
>>>> };
> 
> Since when would a transceiver support different speeds for CAN & CANFD?

When I say CAN I'm referring to CAN 2.0 specification which mentioned
speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.

> 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...

What is arbitration speed?

Also if I understand you correctly then I agree drivers for traditional
CAN wouldn't care about this subnode. Although it may be helpful for
max-data-speed to become max-canfd-speed or something along those lines.
Just so the property's purpose is clear.
> 
> Kind regards,
> Kurt
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CAN-FD Transceiver Limitations

[Kurt Van Dijck]

> On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
> >>>>
> >>>> mcan@0 {
> >>>> 	...
> >>>> 	fixed-transceiver {
> >>>> 	      max-canfd-speed = <2000>
> >>>> 	};
> >>>> 	...
> >>>> };
> > 
> > Since when would a transceiver support different speeds for CAN & CANFD?
> 
> When I say CAN I'm referring to CAN 2.0 specification which mentioned
> speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.

linux-can is not necessarily restricted to CAN 2.0B?

> 
> > 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...
> 
> What is arbitration speed?

CANFD remains similar during the arbitration phase (when the CAN id is
sent on the wire), and after that allows to switch to a higher 'data'
speed because the round-trip wire restrictions during arbitration
don't apply anymore.

> 
> Also if I understand you correctly then I agree drivers for traditional
> CAN wouldn't care about this subnode. Although it may be helpful for
> max-data-speed to become max-canfd-speed or something along those lines.
> Just so the property's purpose is clear.

Transceivers exist that don't support 1MB either.
naming the speeds max-arbitration-speed and max-data-speed makes this
OF nodes usable for that kind of CAN 2.0 restrtications too.

Of course, CAN 2.0 chips only consider max-arbitration-speed as that
applies to the whole wire bitstream, where as CANFD considers both.

What I understand of your proposal is that max-arbitration-speed is
'fixed to 1MB anyway', and that assumption has been proven not
universally applicable with CAN2.0 transceivers already.

I found the name 'max-canfd-speed' a bit dubious as CANFD relies on
'flexible datarate'. transceivers may not necessarily support the same
speed for both arbitration and data.
So I propose to replace it with 'max-data-speed'

Kind regards,
Kurt

> > 
> > Kind regards,
> > Kurt
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

Hi Kurt,

On 06/30/2017 03:09 AM, Kurt Van Dijck wrote:
>> On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>>>>>
>>>>>> mcan@0 {
>>>>>> 	...
>>>>>> 	fixed-transceiver {
>>>>>> 	      max-canfd-speed = <2000>
>>>>>> 	};
>>>>>> 	...
>>>>>> };
>>>
>>> Since when would a transceiver support different speeds for CAN & CANFD?
>>
>> When I say CAN I'm referring to CAN 2.0 specification which mentioned
>> speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.
> 
> linux-can is not necessarily restricted to CAN 2.0B?
> 
>>
>>> 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...
>>
>> What is arbitration speed?
> 
> CANFD remains similar during the arbitration phase (when the CAN id is
> sent on the wire), and after that allows to switch to a higher 'data'
> speed because the round-trip wire restrictions during arbitration
> don't apply anymore.
> 
>>
>> Also if I understand you correctly then I agree drivers for traditional
>> CAN wouldn't care about this subnode. Although it may be helpful for
>> max-data-speed to become max-canfd-speed or something along those lines.
>> Just so the property's purpose is clear.
> 
> Transceivers exist that don't support 1MB either.
> naming the speeds max-arbitration-speed and max-data-speed makes this
> OF nodes usable for that kind of CAN 2.0 restrtications too.
> 
> Of course, CAN 2.0 chips only consider max-arbitration-speed as that
> applies to the whole wire bitstream, where as CANFD considers both.
> 
> What I understand of your proposal is that max-arbitration-speed is
> 'fixed to 1MB anyway', and that assumption has been proven not
> universally applicable with CAN2.0 transceivers already.
> 
> I found the name 'max-canfd-speed' a bit dubious as CANFD relies on
> 'flexible datarate'. transceivers may not necessarily support the same
> speed for both arbitration and data.
> So I propose to replace it with 'max-data-speed'

Thanks for the explanation. Makes sense.
> 
> Kind regards,
> Kurt
> 
>>>
>>> Kind regards,
>>> Kurt
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CAN-FD Transceiver Limitations

[Franklin S Cooper Jr]

Hi Kurt,

On 06/30/2017 03:09 AM, Kurt Van Dijck wrote:
>> On 06/29/2017 05:36 PM, Kurt Van Dijck wrote:
>>>>>>
>>>>>> mcan@0 {
>>>>>> 	...
>>>>>> 	fixed-transceiver {
>>>>>> 	      max-canfd-speed = <2000>
>>>>>> 	};
>>>>>> 	...
>>>>>> };
>>>
>>> Since when would a transceiver support different speeds for CAN & CANFD?
>>
>> When I say CAN I'm referring to CAN 2.0 specification which mentioned
>> speeds upto 1 Mbit/s. While CAN FD supports higher bitrates.
> 
> linux-can is not necessarily restricted to CAN 2.0B?
> 
>>
>>> 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...
>>
>> What is arbitration speed?
> 
> CANFD remains similar during the arbitration phase (when the CAN id is
> sent on the wire), and after that allows to switch to a higher 'data'
> speed because the round-trip wire restrictions during arbitration
> don't apply anymore.
> 
>>
>> Also if I understand you correctly then I agree drivers for traditional
>> CAN wouldn't care about this subnode. Although it may be helpful for
>> max-data-speed to become max-canfd-speed or something along those lines.
>> Just so the property's purpose is clear.
> 
> Transceivers exist that don't support 1MB either.
> naming the speeds max-arbitration-speed and max-data-speed makes this
> OF nodes usable for that kind of CAN 2.0 restrtications too.
> 
> Of course, CAN 2.0 chips only consider max-arbitration-speed as that
> applies to the whole wire bitstream, where as CANFD considers both.
> 
> What I understand of your proposal is that max-arbitration-speed is
> 'fixed to 1MB anyway', and that assumption has been proven not
> universally applicable with CAN2.0 transceivers already.
> 
> I found the name 'max-canfd-speed' a bit dubious as CANFD relies on
> 'flexible datarate'. transceivers may not necessarily support the same
> speed for both arbitration and data.
> So I propose to replace it with 'max-data-speed'

Thanks for the explanation. Makes sense.
> 
> Kind regards,
> Kurt
> 
>>>
>>> Kind regards,
>>> Kurt
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CAN-FD Transceiver Limitations

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 1278 bytes --]

On 06/29/2017 05:41 PM, Andrew Lunn wrote:
>> 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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]