Messages in this thread | | | Date | Wed, 19 Apr 2023 15:40:24 -0500 | Subject | Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x | From | "Mendez, Judith" <> |
| |
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
| |