Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6eb588ef-ab12-186d-b0d3-35fc505a225a@ti.com>
Date:   Tue, 18 Apr 2023 11:15:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [RFC PATCH 0/5] Enable multiple MCAN on AM62x
To:     Marc Kleine-Budde <mkl@pengutronix.de>
References: <20230413223051.24455-1-jm@ti.com>
 <20230414-tubular-service-3404c64c6c62-mkl@pengutronix.de>
Content-Language: en-US
From:   "Mendez, Judith" <jm@ti.com>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        <linux-can@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Wolfgang Grandegger <wg@grandegger.com>,
        Andrew Davis <afd@ti.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Nishanth Menon <nm@ti.com>,
        Chandrasekar Ramakrishnan <rcsekar@samsung.com>,
        <linux-can@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <devicetree@vger.kernel.org>, <netdev@vger.kernel.org>
In-Reply-To: <20230414-tubular-service-3404c64c6c62-mkl@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@app.fastmail.com/T/
> 
> Marc
> 

regards,
Judith