mbox series

[v10,0/2] Enable multiple MCAN on AM62x

Message ID 20230707204714.62964-1-jm@ti.com
Headers show
Series Enable multiple MCAN on AM62x | expand

Message

Judith Mendez July 7, 2023, 8:47 p.m. UTC 
On AM62x there are two MCANs 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.

This solution instantiates a hrtimer with 1 ms polling interval
for MCAN device when there is no hardware interrupt property in
DTB MCAN node. The 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.
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.

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.

v9:
Link: https://lore.kernel.org/linux-can/20230419223323.20384-1-jm@ti.com/T/#t

v8:
Link: https://lore.kernel.org/linux-can/20230530224820.303619-1-jm@ti.com/T/#t

v7:
Link: https://lore.kernel.org/linux-can/20230523023749.4526-1-jm@ti.com/T/#t

v6:
Link: https://lore.kernel.org/linux-can/20230518193613.15185-1-jm@ti.com/T/#t

v5:
Link: https://lore.kernel.org/linux-can/20230510202952.27111-1-jm@ti.com/T/#t

v4:
Link: https://lore.kernel.org/linux-can/c3395692-7dbf-19b2-bd3f-31ba86fa4ac9@linaro.org/T/#t

v2:
Link: https://lore.kernel.org/linux-can/20230424195402.516-1-jm@ti.com/T/#t

V1:
Link: https://lore.kernel.org/linux-can/19d8ae7f-7b74-a869-a818-93b74d106709@ti.com/T/#t

RFC:
Link: https://lore.kernel.org/linux-can/52a37e51-4143-9017-42ee-8d17c67028e3@ti.com/T/#t

v10:
- set irq=0 during declaration
- return irq error value instead of -EINVAL;
v9:
- Change add MS to HRTIMER_POLL_INTERVAL
- Change syntax from "= 0" to "!"
v8:
- Cancel hrtimer after interrupts in m_can_stop
- Move assignment of hrtimer_callback to m_can_class_register()
- Initialize irq = 0 if polling mode is used
v7:
- Clean up m_can_platform.c after removing poll-interval
v6:
- Move hrtimer stop/start function calls to m_can_open and m_can_close to
support power suspend/resume
v5:
- Remove poll-interval in bindings
- Change dev_dbg to dev_info if hardware int exists and polling
is enabled
v4:
- Wrong patches sent
v3:
- Update binding poll-interval description
- Add oneOf to select either
interrupts/798d276b39e984345d52b933a900a71fa0815928
v2:
- Add poll-interval property to bindings and MCAN DTB node
- Add functionality to check for 'poll-interval' property in MCAN node 
- Bindings: add an example using poll-interval
- Add 'polling' flag in driver to check if device is using polling method
- Check for timer polling and hardware interrupt cases, default to
hardware interrupt method
- Change ns_to_ktime() to ms_to_ktime()

Judith Mendez (2):
  dt-bindings: net: can: Remove interrupt properties for MCAN
  can: m_can: Add hrtimer to generate software interrupt

 .../bindings/net/can/bosch,m_can.yaml         | 20 ++++++++++--
 drivers/net/can/m_can/m_can.c                 | 32 ++++++++++++++++++-
 drivers/net/can/m_can/m_can.h                 |  3 ++
 drivers/net/can/m_can/m_can_platform.c        | 21 +++++++++---
 4 files changed, 69 insertions(+), 7 deletions(-)


base-commit: e1f6a8eaf1c271a0158114a03e3605f4fba059ad

Comments

Marc Kleine-Budde July 10, 2023, 9:57 a.m. UTC | #1 
On 07.07.2023 15:47:12, Judith Mendez wrote:
> On AM62x there are two MCANs 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.
> 
> This solution instantiates a hrtimer with 1 ms polling interval
> for MCAN device when there is no hardware interrupt property in
> DTB MCAN node. The 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.
> 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.

Latency

> 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

However

> load increases at 0.5 ms.
> 
> 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.
> 
> v9:
> Link: https://lore.kernel.org/linux-can/20230419223323.20384-1-jm@ti.com/T/#t
> 
> v8:
> Link: https://lore.kernel.org/linux-can/20230530224820.303619-1-jm@ti.com/T/#t
> 
> v7:
> Link: https://lore.kernel.org/linux-can/20230523023749.4526-1-jm@ti.com/T/#t
> 
> v6:
> Link: https://lore.kernel.org/linux-can/20230518193613.15185-1-jm@ti.com/T/#t
> 
> v5:
> Link: https://lore.kernel.org/linux-can/20230510202952.27111-1-jm@ti.com/T/#t
> 
> v4:
> Link: https://lore.kernel.org/linux-can/c3395692-7dbf-19b2-bd3f-31ba86fa4ac9@linaro.org/T/#t

The link doesn't point to v4, fixed.

> v2:
> Link: https://lore.kernel.org/linux-can/20230424195402.516-1-jm@ti.com/T/#t
> 
> V1:
> Link: https://lore.kernel.org/linux-can/19d8ae7f-7b74-a869-a818-93b74d106709@ti.com/T/#t

Was there a v1? That link doesn't point to it, removed.

> 
> RFC:
> Link: https://lore.kernel.org/linux-can/52a37e51-4143-9017-42ee-8d17c67028e3@ti.com/T/#t

Doesn't point to RFC, fixed.

Applied to linux-can-next/testing.

Thanks,
Marc
Francesco Dolcini July 14, 2023, 9:59 a.m. UTC | #2 
Hello Mark,

On Mon, Jul 10, 2023 at 11:57:51AM +0200, Marc Kleine-Budde wrote:
> On 07.07.2023 15:47:12, Judith Mendez wrote:
> > On AM62x there are two MCANs 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.
...

> Applied to linux-can-next/testing.

Did you forgot to push your changes out? Nothing here
git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git

Francesco
Marc Kleine-Budde July 17, 2023, 3:14 p.m. UTC | #3 
On 14.07.2023 11:59:47, Francesco Dolcini wrote:
> Hello Mark,
> 
> On Mon, Jul 10, 2023 at 11:57:51AM +0200, Marc Kleine-Budde wrote:
> > On 07.07.2023 15:47:12, Judith Mendez wrote:
> > > On AM62x there are two MCANs 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.
> ...
> 
> > Applied to linux-can-next/testing.
> 
> Did you forgot to push your changes out? Nothing here
> git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git

Sorry for the delay. I've not updated the testing branch on
linux-can-next.

regards,
Marc