| Message ID | 20230501224624.13866-1-jm@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enable multiple MCAN on AM62x | expand |
On 17:46-20230501, Judith Mendez wrote: > Add an overlay for main domain MCAN on AM62x SK. The AM62x > SK board does not have on-board CAN transceiver so instead > of changing the DTB permanently, add an overlay to enable > MAIN domain MCAN and support for 1 CAN transceiver. > > This DT overlay can be used with the following EVM: > Link: https://www.ti.com/tool/TCAN1042DEVM > > Signed-off-by: Judith Mendez <jm@ti.com> > --- > Changelog: > v3: > 1. Add link for specific board > > arch/arm64/boot/dts/ti/Makefile | 2 ++ > .../boot/dts/ti/k3-am625-sk-mcan-main.dtso | 35 +++++++++++++++++++ > 2 files changed, 37 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am625-sk-mcan-main.dtso > > diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile > index c83c9d772b81..abe15e76b614 100644 > --- a/arch/arm64/boot/dts/ti/Makefile > +++ b/arch/arm64/boot/dts/ti/Makefile > @@ -9,8 +9,10 @@ > # alphabetically. > > # Boards with AM62x SoC > +k3-am625-sk-mcan-dtbs := k3-am625-sk.dtb k3-am625-sk-mcan-main.dtbo NAK. https://lore.kernel.org/all/4e406c96-3f47-1695-324f-a9e45be8c142@ti.com/ Same reasons - we don't want specific instance based overlays please - that would'nt make sense - maxbitrate will depend on transceiver so it has nothing to do with mcan-main or mcan-mcu and has everything to do with the board that is plugged in. > dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb > +dtb-$(CONFIG_ARCH_K3) += k3-am625-sk-mcan.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk.dtb > > # Boards with AM62Ax SoC > diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk-mcan-main.dtso b/arch/arm64/boot/dts/ti/k3-am625-sk-mcan-main.dtso > new file mode 100644 > index 000000000000..0a7b2f394f87 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am625-sk-mcan-main.dtso If you are going down this road: am625-sk-tcan10242d.dsto (enable main and mcu?) or something reasonable. Though looking at the pins, I fail to see how this physically plugs into AM625-SK (I am hoping the answer isn't breadboard or jumper wires..). > @@ -0,0 +1,35 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/** > + * DT overlay for MCAN transceiver in main domain on AM625 SK > + * > + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > + */ > + > +/dts-v1/; > +/plugin/; > + > +#include "k3-pinctrl.h" > + > +&{/} { > + transceiver1: can-phy0 { > + compatible = "ti,tcan1042"; > + #phy-cells = <0>; > + max-bitrate = <5000000>; > + }; > +}; > + > +&main_pmx0 { > + main_mcan0_pins_default: main-mcan0-pins-default { > + pinctrl-single,pins = < > + AM62X_IOPAD(0x1dc, PIN_INPUT, 0) /* (E15) MCAN0_RX */ > + AM62X_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (C15) MCAN0_TX */ > + >; > + }; > +}; > + > +&main_mcan0 { > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&main_mcan0_pins_default>; > + phys = <&transceiver1>; > +}; > -- > 2.17.1 >
On 02/05/2023 00: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. > > This solution instantiates a hrtimer with 1 ms polling interval > for MCAN device when there is no hardware interrupt and there is > poll-interval 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. > > 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. > > 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': > Link: https://lore.kernel.org/lkml/775ec9ce-7668-429c-a977-6c8995968d6e@app.fastmail.com/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 > > Changes since v3: > - Wrong patch sent, resend correct patch series Sending patchsets every 10 minutes does not help us... Best regards, Krzysztof