On 19.04.2023 15:40:24, Mendez, Judith wrote: > 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? It is a recommendation on how to get around the hardware limitation, instead of falling back to polling. > 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. Of course, the feasibility of this approach depends on your system design. > > > > > 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! I would like to have the DT bindings in place, as handling legacy DT without poll interval adds unnecessary complexity. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Attachment:
signature.asc
Description: PGP signature
