* CAN-FD Transceiver Limitations @ 2017-06-28 22:14 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-28 22:14 UTC (permalink / raw) To: linux-can, netdev, wg, mkl 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* CAN-FD Transceiver Limitations @ 2017-06-28 22:14 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-28 22:14 UTC (permalink / raw) To: linux-can, netdev, wg, mkl 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-28 22:14 ` Franklin S Cooper Jr (?) @ 2017-06-29 14:21 ` Andrew Lunn 2017-06-29 14:49 ` Franklin S Cooper Jr -1 siblings, 1 reply; 16+ messages in thread From: Andrew Lunn @ 2017-06-29 14:21 UTC (permalink / raw) To: Franklin S Cooper Jr; +Cc: linux-can, netdev, wg, mkl 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 14:21 ` Andrew Lunn @ 2017-06-29 14:49 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 14:49 UTC (permalink / raw) To: Andrew Lunn; +Cc: linux-can, netdev, wg, mkl 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations @ 2017-06-29 14:49 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 14:49 UTC (permalink / raw) To: Andrew Lunn; +Cc: linux-can, netdev, wg, mkl 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 14:49 ` Franklin S Cooper Jr (?) @ 2017-06-29 15:41 ` Andrew Lunn 2017-06-29 16:36 ` Franklin S Cooper Jr 2017-07-10 14:58 ` Marc Kleine-Budde -1 siblings, 2 replies; 16+ messages in thread From: Andrew Lunn @ 2017-06-29 15:41 UTC (permalink / raw) To: Franklin S Cooper Jr; +Cc: linux-can, netdev, wg, mkl > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 15:41 ` Andrew Lunn @ 2017-06-29 16:36 ` Franklin S Cooper Jr 2017-07-10 14:58 ` Marc Kleine-Budde 1 sibling, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 16:36 UTC (permalink / raw) To: Andrew Lunn; +Cc: linux-can, netdev, wg, mkl, devicetree +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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations @ 2017-06-29 16:36 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 16:36 UTC (permalink / raw) To: Andrew Lunn; +Cc: linux-can, netdev, wg, mkl, devicetree +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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 16:36 ` Franklin S Cooper Jr (?) @ 2017-06-29 17:19 ` Andrew Lunn -1 siblings, 0 replies; 16+ messages in thread From: Andrew Lunn @ 2017-06-29 17:19 UTC (permalink / raw) To: Franklin S Cooper Jr; +Cc: linux-can, netdev, wg, mkl, devicetree > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 16:36 ` Franklin S Cooper Jr (?) (?) @ 2017-06-29 22:36 ` Kurt Van Dijck [not found] ` <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> -1 siblings, 1 reply; 16+ messages in thread From: Kurt Van Dijck @ 2017-06-29 22:36 UTC (permalink / raw) To: Franklin S Cooper Jr; +Cc: Andrew Lunn, linux-can, netdev, wg, mkl, devicetree > >> > >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>]
* Re: CAN-FD Transceiver Limitations [not found] ` <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> @ 2017-06-29 23:14 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 23:14 UTC (permalink / raw) To: Andrew Lunn, linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations @ 2017-06-29 23:14 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-29 23:14 UTC (permalink / raw) To: Andrew Lunn, linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <d5c2e2f2-8b74-58e1-0cc8-727ba39bd14c-l0cyMroinI0@public.gmane.org>]
* Re: CAN-FD Transceiver Limitations [not found] ` <d5c2e2f2-8b74-58e1-0cc8-727ba39bd14c-l0cyMroinI0@public.gmane.org> @ 2017-06-30 8:09 ` Kurt Van Dijck [not found] ` <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Kurt Van Dijck @ 2017-06-30 8:09 UTC (permalink / raw) To: Franklin S Cooper Jr Cc: Andrew Lunn, linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org>]
* Re: CAN-FD Transceiver Limitations [not found] ` <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> @ 2017-06-30 17:51 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-30 17:51 UTC (permalink / raw) To: Andrew Lunn, linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations @ 2017-06-30 17:51 ` Franklin S Cooper Jr 0 siblings, 0 replies; 16+ messages in thread From: Franklin S Cooper Jr @ 2017-06-30 17:51 UTC (permalink / raw) To: Andrew Lunn, linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: CAN-FD Transceiver Limitations 2017-06-29 15:41 ` Andrew Lunn 2017-06-29 16:36 ` Franklin S Cooper Jr @ 2017-07-10 14:58 ` Marc Kleine-Budde 1 sibling, 0 replies; 16+ messages in thread From: Marc Kleine-Budde @ 2017-07-10 14:58 UTC (permalink / raw) To: Andrew Lunn, Franklin S Cooper Jr; +Cc: linux-can, netdev, wg [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-07-10 14:58 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-28 22:14 CAN-FD Transceiver Limitations Franklin S Cooper Jr 2017-06-28 22:14 ` Franklin S Cooper Jr 2017-06-29 14:21 ` Andrew Lunn 2017-06-29 14:49 ` Franklin S Cooper Jr 2017-06-29 14:49 ` Franklin S Cooper Jr 2017-06-29 15:41 ` Andrew Lunn 2017-06-29 16:36 ` Franklin S Cooper Jr 2017-06-29 16:36 ` Franklin S Cooper Jr 2017-06-29 17:19 ` Andrew Lunn 2017-06-29 22:36 ` Kurt Van Dijck [not found] ` <20170629223551.GA6568-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> 2017-06-29 23:14 ` Franklin S Cooper Jr 2017-06-29 23:14 ` Franklin S Cooper Jr [not found] ` <d5c2e2f2-8b74-58e1-0cc8-727ba39bd14c-l0cyMroinI0@public.gmane.org> 2017-06-30 8:09 ` Kurt Van Dijck [not found] ` <20170630080906.GA26712-W3bwb+3xS1LIj2mJfgo99rBP9FGTfoIhIWnq8iejnXE@public.gmane.org> 2017-06-30 17:51 ` Franklin S Cooper Jr 2017-06-30 17:51 ` Franklin S Cooper Jr 2017-07-10 14:58 ` Marc Kleine-Budde
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.