Message ID | 20230427204540.3126234-1-dario.binacchi@amarulasolutions.com (mailing list archive) |
---|---|
Headers | show |
Series | can: bxcan: add support for single peripheral configuration | expand |
On 27.04.2023 22:45:35, Dario Binacchi wrote: > > The series adds support for managing bxCAN controllers in single peripheral > configuration. > Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral > configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 > in dual peripheral configuration and CAN3 in single peripheral > configuration: > - Dual CAN peripheral configuration: > * CAN1: Primary bxCAN for managing the communication between a secondary > bxCAN and the 512-byte SRAM memory. > * CAN2: Secondary bxCAN with no direct access to the SRAM memory. > This means that the two bxCAN cells share the 512-byte SRAM memory and > CAN2 can't be used without enabling CAN1. > - Single CAN peripheral configuration: > * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and > 512-byte SRAM memory. This really looks good! Great work! Who takes the DT changes? I can take the whole series. regards, Marc
On 27.04.2023 23:08:57, Marc Kleine-Budde wrote: > On 27.04.2023 22:45:35, Dario Binacchi wrote: > > > > The series adds support for managing bxCAN controllers in single peripheral > > configuration. > > Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral > > configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 > > in dual peripheral configuration and CAN3 in single peripheral > > configuration: > > - Dual CAN peripheral configuration: > > * CAN1: Primary bxCAN for managing the communication between a secondary > > bxCAN and the 512-byte SRAM memory. > > * CAN2: Secondary bxCAN with no direct access to the SRAM memory. > > This means that the two bxCAN cells share the 512-byte SRAM memory and > > CAN2 can't be used without enabling CAN1. > > - Single CAN peripheral configuration: > > * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and > > 512-byte SRAM memory. > > This really looks good! Great work! Who takes the DT changes? I can take > the whole series. I've upstreamed the DT changes for the first bxCAN driver, so I'll take them this time, too. Marc
On 27.04.2023 22:45:35, Dario Binacchi wrote: > > The series adds support for managing bxCAN controllers in single peripheral > configuration. > Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral > configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 > in dual peripheral configuration and CAN3 in single peripheral > configuration: > - Dual CAN peripheral configuration: > * CAN1: Primary bxCAN for managing the communication between a secondary > bxCAN and the 512-byte SRAM memory. > * CAN2: Secondary bxCAN with no direct access to the SRAM memory. > This means that the two bxCAN cells share the 512-byte SRAM memory and > CAN2 can't be used without enabling CAN1. > - Single CAN peripheral configuration: > * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and > 512-byte SRAM memory. > > The driver has been tested on the stm32f769i-discovery board with a > kernel version 5.19.0-rc2 in loopback + silent mode: > > ip link set can[0-2] type can bitrate 125000 loopback on listen-only on > ip link set up can[0-2] > candump can[0-2] -L & > cansend can[0-2] 300#AC.AB.AD.AE.75.49.AD.D1 Applied to linux-can-next. Thanks, Marc