Messages in this thread | | | Date | Tue, 18 Apr 2023 11:15:35 -0500 | Subject | Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x | From | "Mendez, Judith" <> |
| |
Hello Marc,
On 4/14/2023 12:49 PM, Marc Kleine-Budde wrote: > On 13.04.2023 17:30:46, Judith Mendez wrote: >> On AM62x there is one MCAN in MAIN domain and two in MCU domain. >> The MCANs in MCU domain were not enabled since there is no >> hardware interrupt routed to A53 GIC interrupt controller. >> Therefore A53 Linux cannot be interrupted by MCU MCANs. > > Is this a general hardware limitation, that effects all MCU domain > peripherals? Is there a mailbox mechanism between the MCU and the MAIN > domain, would it be possible to pass the IRQ with a small firmware on > the MCU? Anyways, that's future optimization. >
This is a hardware limitation that affects AM62x SoC and has been carried over to at least 1 other SoC. Using the MCU is an idea that we have juggled around for a while, we will definitely keep it in mind for future optimization. Thanks for your feedback.
>> This solution instantiates a hrtimer with 1 ms polling interval >> for a MCAN when there is no hardware interrupt. This hrtimer >> generates a recurring software interrupt which allows to call the >> isr. The isr will check if there is pending transaction by reading >> a register and proceed normally if there is. >> >> On AM62x this series enables two MCU MCAN which will use the hrtimer >> implementation. MCANs with hardware interrupt routed to A53 Linux >> will continue to use the hardware interrupt as expected. >> >> Timer polling method was tested on both classic CAN and CAN-FD >> at 125 KBPS, 250 KBPS, 1 MBPS and 2.5 MBPS with 4 MBPS bitrate >> switching. >> >> Letency and CPU load benchmarks were tested on 3x MCAN on AM62x. >> 1 MBPS timer polling interval is the better timer polling interval >> since it has comparable latency to hardware interrupt with the worse >> case being 1ms + CAN frame propagation time and CPU load is not >> substantial. Latency can be improved further with less than 1 ms >> polling intervals, howerver it is at the cost of CPU usage since CPU >> load increases at 0.5 ms and lower polling periods than 1ms. > > Some Linux input drivers have the property poll-interval, would it make > sense to ass this here too? > >> Note that in terms of power, enabling MCU MCANs with timer-polling >> implementation might have negative impact since we will have to wake >> up every 1 ms whether there are CAN packets pending in the RX FIFO or >> not. This might prevent the CPU from entering into deeper idle states >> for extended periods of time. >> >> This patch series depends on 'Enable CAN PHY transceiver driver': >> https://lore.kernel.org/lkml/775ec9ce-7668-429c-a977-6c8995968d6e@app.fastmail.com/T/ > > Marc >
regards, Judith
| |