Hello Marc, On Tuesday 22 of March 2022 10:22:12 Marc Kleine-Budde wrote: > > We have HW timestamping implemented for actual stable CTU CAN FD IP core > > version, support for variable number of TX buffers which count can be > > parameterized up to 8 in the prepared version and long term desire to > > configurable-SW defined multi-queue which our HW interface allows to > > dynamically server by á TX buffers. But plan is to keep combinations > > of the design and driver compatible from the actual revision. > > Is the number of RX and TX buffers and TX queues auto detectable by > software, or do we need DT bindings for this? we plan to count info available through field in the registers. See paragraph 3.1.39 TXTB_INFO http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf The bits are read as zeros on the older version so if the zero is found older default 4 will be chosen by the driver. So I prefer no side information channel DTC etc. Even on the actual PCI integration you can read number of channels from the support PCI BAR range and locate actual cores on the other BAR. > The net-next merge window closed with Monday evening, so this driver > will go into net-next for v5.19. My shame. I hoped to get driver into mainline till Embedded World Conference 2022 where we participate with our RISC-V education tools and materials so that I could report to others in the RISC-V camp and even CiA that we are finally easily to use. On the other hand more time gives time for better review and possible cleanup. But I would wait with features addition till some base accepted to the next or mainline. I hope that interfaces will not change too much before inclusion that actual tested code can get in. > > > BTW: The PROP_SEG/PHASE_SEG1 issue is known: > > > > +A curious reader will notice that the durations of the segments > > > > PROP_SEG +and PHASE_SEG1 are not determined separately but rather > > > > combined and +then, by default, the resulting TSEG1 is evenly divided > > > > between PROP_SEG +and PHASE_SEG1. > > > > > > and the flexcan IP core in CAN-FD mode has the same problem. When > > > working on the bit timing parameter, I'll plan to have separate > > > PROP_SEG/PHASE_SEG1 min/max in the kernel, so that the bit timing > > > algorithm can take care of this. > > > > Hmm, when I have thought about that years ago I have not noticed real > > difference when time quanta is move between PROP_SEG and PHASE_SEG1. > > So for me it had no influence on the algorithm computation and > > could be done on the chip level when minimal and maximal sum is > > respected. But may it be I have overlooked something and there is > > difference for CAN FD. May it be my colleagues Jiri Novak and > > Ondrej Ille are more knowable. > > Jiri, Ondrej, I'm interested in details :) > > > As for the optimal timequantas per bit value, I agree that it > > is not so simple. In the fact SJW and even tipple-sampling > > should be defined in percentage of bit time > > I thought of specifying SJW in a relative value, too. > > > and then all should be optimized together > > SJW has no influence on the bit rate and sample point. Although SJW is > max phase seg 2, so it's maximum is influenced by the sample point. > > > and even combination with slight bitrate error should be preferred > > against other exact matching when there is significant difference in > > the other parameters values. > > Since linux-4.8, i.e. > > | 7da29f97d6c8 can: dev: can-calc-bit-timing(): better sample point > | calculation > > the algorithm optimizes for best bit minimal absolute bit rate error > first and then for minimal sample point error. The sample point must be > <= the nominal sample point. I have some experiments where the algorithm > optimizes the absolute sample point error. Yes but you do not need exact bitrate even when it is available. I do no look into standards now, but I think 1% error should not be a problem. May it be even 3% error when whole jitter and clocks frequency errors fit below it should work (5 (bit stuff) x 3% = 15% is less than 100% - 80% (typical SP) and with well tuned SF even 25 or 50% of the last bit could be accepted that communication can at leas sometimes succeed). So allow error of 0.1% as better than too low or too high TQ per bit or strange SJW can be acceptable. On the other hand if CAN is used with time triggered stuff or keep/ synchronize whole plant global time then 0.1% is too much. So at the end in this case really tuning for concrete application comes into play. But in kernel algorithm is there to make most common usages easy... > For more complicated bit timing optimization you need to combine the > bitrate error and the sample point error into a function that needs to > be minimized. Yes. > > By the way we have received report from Andrew Dennison about > > successful integration of CTU CAN FD into Litex based RISC-V > > system. Tested with the Linux our Linux kernel driver. > > That sounds interesting! I hope that community joint forces can reach state where CAN FD will be solved on all FPGA and combinations easily and open source way. We need to find way for funding of certification and long term sustainability. But at least our previous release and actual public code is game level save point. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: pisa@xxxxxxxxxxxxxxxx Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://dce.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
