Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x

[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@xxxxxxxxxxxxxxxx/T/
>
> Marc

regards,
Judith