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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230419-stretch-tarantula-e0d21d067483-mkl@pengutronix.de>
Date:   Wed, 19 Apr 2023 08:10:24 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     "Mendez, Judith" <jm@...com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        Andrew Davis <afd@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Nishanth Menon <nm@...com>,
        Chandrasekar Ramakrishnan <rcsekar@...sung.com>,
        devicetree@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x

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.

> > > 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?

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   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)