lkml.org 
[lkml]   [2023]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC PATCH 0/5] Enable multiple MCAN on AM62x
    From
    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

    \
     
     \ /
      Last update: 2023-04-18 18:17    [W:5.958 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site