On 1/15/21 5:30 PM, Vincent MAILHOL wrote: >>>>>>> I would just like your opinion on one topic: the tdco is specific >>>>>>> to CAN FD. If we add it, we have two choices: >>>>>>> 1. put it in struct can_bittiming: that will mean that we will >>>>>>> have an unused field for classical CAN (field bittiming of >>>>>>> struct can_priv). >>>>>>> 2. put it in struct can_priv (but outside of struct >>>>>>> can_bittiming): no unused field but less pretty. >>>>>> >>>>>> 3. Deprecate struct can_bittiming as the user space interface >>>>>> and transfer each member individually via netlink. Extend >>>>>> the kernel-only can_bittiming by the tdc related >>>>>> parameters, and add these to the new netlink interface. >>> >>> Wow, didn't see that third option coming! >>> >>> By "extend the kernel-only can_bittiming by the tdc related >>> parameters" do you mean to still use a single struct >>> can_bittiming for classical CAN and CAN FD with the tdc >>> parameters in both (a bit like what I suggested in 1.)? >> >> Let's put it this way, we need 3. in order to implement 1. As we need a stable >> userspace ABI. > > I was not familiar enough with the netlink interface to foresee > all those dependencies but thanks to your explanations, now > everything starts to make sense. >> Option 4: >> We can introduce a struct can_bitiming_fd with the first member being the struct >> can_bitiming and add tdc related variables after that. This way we can use the >> same function to calculate the bit timing on both CAN and CAN-FD. > > While option 3 is slightly easier, my preference will go to option 4. We still need the netlink enhancement from option 3. >> What about future developments? >> >> Does anyone have a clue about CAN-XL? Will we ever see real HW? > > Recent news would suggest that CiA will release the CAN XL > specification this year: > https://www.can-cia.org/news/cia-in-action/view/a-bright-future-for-can/2021/1/2/ Thanks, I've missed this. >> Or will >> 10Base-T1 and 100Base-T1 take the market? > > My guts tell me that 100Base-T1 will take the market for > autonomous driving (camera, Lidar...) and that CAN(-FD) has still > a bright future for safety critical domains, at least in the next > decade. There are already automotive equipment out there, that uses CAN-FD and 100Base-T1. Wakeup via CAN-FD, once alive do other stuff via 100Base-T1. > Will CAN XL find its place or will it meet the same > destiny as flexray? I do not know. But once the specification and > the first hardware are out, we would probably start to implement > it in Socket CAN before knowing if it will win the market :) > > Nonetheless, if we follow your idea of transferring each member > individually via netlink, then we will have enough flexibility to > adjust the new kernel only can_bitiming structures to our liking. ACK >> There are also these new transceivers in development that should be better >> suited for "special" bus setups. > > Do these require additional bittiming parameters? Don't know - haven't had one of those in my hands, yet. They are called "CAN SIC Transceivers" the slides promise Signal Improvement and former "Ringing Suppression". Back to TDC, which values do you want to provide to user space? >> + netdev_vdbg(netdev, >> + "Transmitter Delay Compensation = %d\n", >> + tx_conf_msg->tdc); >> + netdev_vdbg(netdev, >> + "Transmitter Delay Compensation Offset = %d\n", >> + le16_to_cpu(tx_conf_msg->tdco)); >> + netdev_vdbg(netdev, >> + "Transmitter Delay Compensation Filter = %d\n", >> + le16_to_cpu(tx_conf_msg->tdcf)); Can we describe them in a HW independent way? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
