Re: CAN-FD Transceiver Limitations

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

[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