Hi Marc, > Il 05/03/2021 14:01 Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> ha scritto: > > > Hello, > > this series picks up Dario Binacchi's patches and adds some cleanup > patches in front. > > The D_CAN controller supports up to 128 messages. Until now the driver > only managed 32 messages although Sitara processors and DRA7 SOC can > handle 64. > > The series was tested on a beaglebone board. > > Note: > I have not changed the type of tx_field (belonging to the c_can_priv > structure) to atomic64_t because I think the atomic_t type has size > of at least 32 bits on x86 and arm, which is enough to handle 64 > messages. > http://marc.info/?l=linux-can&m=139746476821294&w=2 reports the results > of tests performed just on x86 and arm architectures. > > Changes in v6: > - make patches > [PATCH v5 0/11] can: c_can: add support to 64 message objects > [PATCH v5 0/11] can: c_can: add support to 64 message objects > separate again, they have been squashed accidentally > > Changes in v5: > - Add cleanup patches > - alloc_c_can_dev(): make use of struct_size() > > Changes in v4: > - Restore IF_RX interface. > - Add a comment to clarify why IF_RX interface is used instead of IF_TX. > - Use GENMASK() for setting msg_obj_rx_mask. > - Use BIT() for setting single bits and GENMASK() for setting masks. > > Changes in v3: > - Use unsigned int instead of int as type of the msg_obj_* fields > in the c_can_priv structure. > - Replace (u64)1 with 1UL in msg_obj_rx_mask setting. > - Use unsigned int instead of int as type of the msg_obj_num field > in c_can_driver_data and c_can_pci_data structures. > > Changes in v2: > - Fix compiling error reported by kernel test robot. > - Add Reported-by tag. > - Pass larger size to alloc_candev() routine to avoid an additional > memory allocation/deallocation. > - Add message objects number to PCI driver data. I tested the patch series on a custom board having two CAN ports. I connected the CAN1 port to the CAN2 port with a cable. Then I opened two terminals. On one I issued a dump command and on the other the transmit command used in the tests described in https://marc.info/?l=linux-can&m=139746476821294&w=2. Terminal-1: $ ip link set can1 type can bitrate <bitrate> $ ip link set up can1 $ candump -t can1 >/tmp/can-test-<bitrate>/out Terminal-2 $ ip link set can0 type can bitrate <bitrate> $ ip link set up can0 $ time cangen can0 -g0 -p1 -I5A5 -L0 -x -n 1000000 Then I applied the following commands to the file generated by the dump command: $ wc -l </tmp/can-test-<bitrate> # ca $ egrep -v ' can1 5A5 \[0\]' /tmp/can-test-<bitrate> | wc -l # cb I repeated the tests for 1000000, 500000, 250000 and 125000 bitrates, before and after applying the series. Here are the results. Before applying the series: bitrate time ca cb 125000 6m 45.22s 1000000 0 250000 3m 25.94s 1000000 0 500000 1m 45.62s 1000000 0 1000000 1m 9.28s 1000000 0 After applying the series: bitrate time ca cb 125000 6m 42.71s 1000000 0 250000 3m 23.28s 1000000 0 500000 1m 44.04s 1000000 0 1000000 1m 8.44s 1000000 0 Thanks and regards, Dario
