| Message ID | 20230808044529.25925-1-hnagalla@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | TI K3 M4F support on AM64x and AM62x SoCs | expand |
On 23:45-20230807, Hari Nagalla wrote: > The following series introduces K3 M4F remoteproc driver support for > AM64x and AM62x SoC families. These SoCs have a ARM Cortex M4F core in > the MCU voltage domain. For safety oriented applications, this core is > operated independently with out any IPC to other cores on the SoC. > However, for non safety applications, some customers use it as a remote > processor and so linux remote proc support is extended to the M4F core. > > See AM64x Technical Reference Manual (SPRUIM2C – SEPTEMBER 2021) for > further details: https://www.ti.com/lit/pdf/SPRUIM2 > > Hari Nagalla (3): > dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs > arm64: dts: ti: k3-am62 : Add M4F remote proc node > arm64: dts: ti: k3-am64 : Add M4F remote proc node > > Martyn Welch (2): > remoteproc: k3: Split out functions common with M4 driver > remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem > > .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 136 ++++ > arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 12 + > .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 + > arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 12 + > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 18 + > arch/arm64/boot/dts/ti/k3-am642-sk.dts | 18 + > drivers/remoteproc/Kconfig | 13 + > drivers/remoteproc/Makefile | 3 +- > drivers/remoteproc/ti_k3_common.c | 513 +++++++++++++++ > drivers/remoteproc/ti_k3_common.h | 108 ++++ > drivers/remoteproc/ti_k3_dsp_remoteproc.c | 598 +----------------- > drivers/remoteproc/ti_k3_m4_remoteproc.c | 333 ++++++++++ > 12 files changed, 1213 insertions(+), 570 deletions(-) > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml > create mode 100644 drivers/remoteproc/ti_k3_common.c > create mode 100644 drivers/remoteproc/ti_k3_common.h > create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c Please keep the device tree seperate from driver changes. ordering of patches should be: a) binding b) driver updates c) mark device tree changes in the same series (if you are posting) as "DONOTMERGE" to help driver maintainers understand that the dts come in via SoC tree (most maintainers do not need this, but it keeps things sane and adjust your expectation that this will hit the same window as the driver changes).