Hello Marc,
On 4/19/2023 1:10 AM, Marc Kleine-Budde wrote:
On 18.04.2023 11:15:35, Mendez, Judith wrote:
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.
Once you have a proper IRQ de-multiplexer, you can integrate it into the
system with a DT change only. No need for changes in the m_can driver.
Is this a recommendation for the current patch?
The reason I am asking is because adding firmware for the M4 to forward
a mailbox with the IRQ to the A53 sounds like a good idea and we have
been juggling the idea, but it is not an ideal solution if customers are
using the M4 for other purposes like safety.
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.
Have you seen my suggestion of the poll-interval?
Some Linux input drivers have the property poll-interval, would it make
sense to ass this here too?
Looking at some examples, I do think we could implement this
poll-interval attribute, then read in the driver and initialize the
hrtimer based on this. I like the idea to submit as a future
optimization patch, thanks!
regards,
Judith
