[PATCH 4/7] remoteproc: keystone: Use devm_pm_runtime_enable() helper
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index 033e573544fef..f457cadc1fae0 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -410,12 +410,13 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
return PTR_ERR(ksproc->reset);
/* enable clock for accessing DSP internal memories */
- pm_runtime_enable(dev);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
+
ret = pm_runtime_resume_and_get(dev);
- if (ret < 0) {
- dev_err(dev, "failed to enable clock, status = %d\n", ret);
- goto disable_rpm;
- }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to enable clock\n");
ret = keystone_rproc_of_get_memories(pdev, ksproc);
if (ret)
@@ -475,8 +476,6 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
gpiod_put(ksproc->kick_gpio);
disable_clk:
pm_runtime_put_sync(dev);
-disable_rpm:
- pm_runtime_disable(dev);
return ret;
}
@@ -487,7 +486,6 @@ static void keystone_rproc_remove(struct platform_device
*pdev)
rproc_del(ksproc->rproc);
gpiod_put(ksproc->kick_gpio);
pm_runtime_put_sync(>dev);
- pm_runtime_disable(>dev);
}
static const struct of_device_id keystone_rproc_of_match[] = {
--
2.39.2
[PATCH 2/7] remoteproc: keystone: Use devm_rproc_alloc() helper
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index 81b179e269a1e..8f0f7a4cfef26 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -384,8 +384,8 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
if (!fw_name)
return -ENOMEM;
- rproc = rproc_alloc(dev, dev_name(dev), _rproc_ops, fw_name,
- sizeof(*ksproc));
+ rproc = devm_rproc_alloc(dev, dev_name(dev), _rproc_ops,
+fw_name, sizeof(*ksproc));
if (!rproc)
return -ENOMEM;
@@ -396,13 +396,11 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
ret = keystone_rproc_of_get_dev_syscon(pdev, ksproc);
if (ret)
- goto free_rproc;
+ return ret;
ksproc->reset = devm_reset_control_get_exclusive(dev, NULL);
- if (IS_ERR(ksproc->reset)) {
- ret = PTR_ERR(ksproc->reset);
- goto free_rproc;
- }
+ if (IS_ERR(ksproc->reset))
+ return PTR_ERR(ksproc->reset);
/* enable clock for accessing DSP internal memories */
pm_runtime_enable(dev);
@@ -467,8 +465,6 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
pm_runtime_put_sync(dev);
disable_rpm:
pm_runtime_disable(dev);
-free_rproc:
- rproc_free(rproc);
return ret;
}
@@ -480,7 +476,6 @@ static void keystone_rproc_remove(struct platform_device
*pdev)
gpiod_put(ksproc->kick_gpio);
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
- rproc_free(ksproc->rproc);
of_reserved_mem_device_release(>dev);
}
--
2.39.2
[PATCH 3/7] remoteproc: keystone: Use devm action to release reserved memory
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index 8f0f7a4cfef26..033e573544fef 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -358,6 +358,13 @@ static int keystone_rproc_of_get_dev_syscon(struct
platform_device *pdev,
return 0;
}
+static void keystone_rproc_mem_release(void *data)
+{
+ struct device *dev = data;
+
+ of_reserved_mem_device_release(dev);
+}
+
static int keystone_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -434,8 +441,14 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
goto disable_clk;
}
- if (of_reserved_mem_device_init(dev))
+ ret = of_reserved_mem_device_init(dev);
+ if (ret) {
dev_warn(dev, "device does not have specific CMA pool\n");
+ } else {
+ ret = devm_add_action_or_reset(dev, keystone_rproc_mem_release,
dev);
+ if (ret)
+ return ret;
+ }
/* ensure the DSP is in reset before loading firmware */
ret = reset_control_status(ksproc->reset);
@@ -459,7 +472,6 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
return 0;
release_mem:
- of_reserved_mem_device_release(dev);
gpiod_put(ksproc->kick_gpio);
disable_clk:
pm_runtime_put_sync(dev);
@@ -476,7 +488,6 @@ static void keystone_rproc_remove(struct platform_device
*pdev)
gpiod_put(ksproc->kick_gpio);
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
- of_reserved_mem_device_release(>dev);
}
static const struct of_device_id keystone_rproc_of_match[] = {
--
2.39.2
[PATCH 6/7] remoteproc: keystone: Use devm_gpiod_get() helper
Use device life-cycle managed GPIO get function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index e65f99b1bf379..da5d5969829fb 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -440,7 +440,7 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
if (ksproc->irq_fault < 0)
return ksproc->irq_fault;
- ksproc->kick_gpio = gpiod_get(dev, "kick", GPIOD_ASIS);
+ ksproc->kick_gpio = devm_gpiod_get(dev, "kick", GPIOD_ASIS);
ret = PTR_ERR_OR_ZERO(ksproc->kick_gpio);
if (ret)
return dev_err_probe(dev, ret, "failed to get gpio for virtio
kicks\n");
@@ -457,27 +457,19 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
/* ensure the DSP is in reset before loading firmware */
ret = reset_control_status(ksproc->reset);
if (ret < 0) {
- dev_err(dev, "failed to get reset status, status = %d\n", ret);
- goto release_mem;
+ return dev_err_probe(dev, ret, "failed to get reset status\n");
} else if (ret == 0) {
WARN(1, "device is not in reset\n");
keystone_rproc_dsp_reset(ksproc);
}
ret = rproc_add(rproc);
- if (ret) {
- dev_err(dev, "failed to add register device with remoteproc
core, status = %d\n",
- ret);
- goto release_mem;
- }
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to register device with
remoteproc core\n");
platform_set_drvdata(pdev, ksproc);
return 0;
-
-release_mem:
- gpiod_put(ksproc->kick_gpio);
- return ret;
}
static void keystone_rproc_remove(struct platform_device *pdev)
@@ -485,7 +477,6 @@ static void keystone_rproc_remove(struct platform_device
*pdev)
struct keystone_rproc *ksproc = platform_get_drvdata(pdev);
rproc_del(ksproc->rproc);
- gpiod_put(ksproc->kick_gpio);
}
static const struct of_device_id keystone_rproc_of_match[] = {
--
2.39.2
[PATCH 7/7] remoteproc: keystone: Use devm_rproc_add() helper
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index da5d5969829fb..27ebe6661b0b7 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -463,22 +463,13 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
keystone_rproc_dsp_reset(ksproc);
}
- ret = rproc_add(rproc);
+ ret = devm_rproc_add(dev, rproc);
if (ret)
return dev_err_probe(dev, ret, "failed to register device with
remoteproc core\n");
- platform_set_drvdata(pdev, ksproc);
-
return 0;
}
-static void keystone_rproc_remove(struct platform_device *pdev)
-{
- struct keystone_rproc *ksproc = platform_get_drvdata(pdev);
-
- rproc_del(ksproc->rproc);
-}
-
static const struct of_device_id keystone_rproc_of_match[] = {
{ .compatible = "ti,k2hk-dsp", },
{ .compatible = "ti,k2l-dsp", },
@@ -490,7 +481,6 @@ MODULE_DEVICE_TABLE(of, keystone_rproc_of_match);
static struct platform_driver keystone_rproc_driver = {
.probe = keystone_rproc_probe,
- .remove_new = keystone_rproc_remove,
.driver = {
.name = "keystone-rproc",
.of_match_table = keystone_rproc_of_match,
--
2.39.2
[PATCH 1/7] remoteproc: keystone: Use devm_kasprintf() to build name string
This is simpler and removes the need to assume the id length to be 1
digit, which then removes a W=1 compile warning about the same.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index 7e57b90bcaf85..81b179e269a1e 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -366,8 +366,6 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
struct rproc *rproc;
int dsp_id;
char *fw_name = NULL;
- char *template = "keystone-dsp%d-fw";
- int name_len = 0;
int ret = 0;
if (!np) {
@@ -382,11 +380,9 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
}
/* construct a custom default fw name - subject to change in future */
- name_len = strlen(template); /* assuming a single digit alias */
- fw_name = devm_kzalloc(dev, name_len, GFP_KERNEL);
+ fw_name = devm_kasprintf(dev, GFP_KERNEL, "keystone-dsp%d-fw", dsp_id);
if (!fw_name)
return -ENOMEM;
- snprintf(fw_name, name_len, template, dsp_id);
rproc = rproc_alloc(dev, dev_name(dev), _rproc_ops, fw_name,
sizeof(*ksproc));
--
2.39.2
[PATCH 5/7] remoteproc: keystone: Use devm action to call PM runtime put sync
This helps prevent mistakes like putting out of order in cleanup functions
and forgetting to put sync on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/keystone_remoteproc.c | 34
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index f457cadc1fae0..e65f99b1bf379 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -365,6 +365,13 @@ static void keystone_rproc_mem_release(void *data)
of_reserved_mem_device_release(dev);
}
+static void keystone_rproc_pm_runtime_put(void *data)
+{
+ struct device *dev = data;
+
+ pm_runtime_put_sync(dev);
+}
+
static int keystone_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -417,30 +424,26 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return dev_err_probe(dev, ret, "failed to enable clock\n");
+ ret = devm_add_action_or_reset(dev, keystone_rproc_pm_runtime_put, dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to add disable pm devm
action\n");
ret = keystone_rproc_of_get_memories(pdev, ksproc);
if (ret)
- goto disable_clk;
+ return ret;
ksproc->irq_ring = platform_get_irq_byname(pdev, "vring");
- if (ksproc->irq_ring < 0) {
- ret = ksproc->irq_ring;
- goto disable_clk;
- }
+ if (ksproc->irq_ring < 0)
+ return ksproc->irq_ring;
ksproc->irq_fault = platform_get_irq_byname(pdev, "exception");
- if (ksproc->irq_fault < 0) {
- ret = ksproc->irq_fault;
- goto disable_clk;
- }
+ if (ksproc->irq_fault < 0)
+ return ksproc->irq_fault;
ksproc->kick_gpio = gpiod_get(dev, "kick", GPIOD_ASIS);
ret = PTR_ERR_OR_ZERO(ksproc->kick_gpio);
- if (ret) {
- dev_err(dev, "failed to get gpio for virtio kicks, status =
%d\n",
- ret);
- goto disable_clk;
- }
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get gpio for virtio
kicks\n");
ret = of_reserved_mem_device_init(dev);
if (ret) {
@@ -474,8 +477,6 @@ static int keystone_rproc_probe(struct platform_device
*pdev)
release_mem:
gpiod_put(ksproc->kick_gpio);
-disable_clk:
- pm_runtime_put_sync(dev);
return ret;
}
@@ -485,7 +486,6 @@ static void keystone_rproc_remove(struct platform_device
*pdev)
rproc_del(ksproc->rproc);
gpiod_put(ksproc->kick_gpio);
- pm_runtime_put_sync(>dev);
}
static const struct of_device_id keystone_rproc_of_match[] = {
--
2.39.2
[PATCH v11 8/9] arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 6bb1ad2e56ec2..23915641115b1 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -101,6 +101,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a310 {
no-map;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@a400 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa400 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@a410 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa410 0x00 0xf0>;
+ no-map;
+ };
+
rtos_ipc_memory_region: ipc-memories@a500 {
reg = <0x00 0xa500 0x00 0x0080>;
alignment = <0x1000>;
@@ -769,6 +781,13 @@ _r5fss1_core1 {
<_r5fss1_core1_memory_region>;
};
+_m4fss {
+ mboxes = <_cluster6 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
_ln_ctrl {
idle-states = ;
};
--
2.39.2
[PATCH v11 9/9] arm64: defconfig: Enable TI K3 M4 remoteproc driver
From: Hari Nagalla Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 7d32fca649965..33b0487b0d607 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1383,6 +1383,7 @@ CONFIG_QCOM_Q6V5_PAS=m CONFIG_QCOM_SYSMON=m CONFIG_QCOM_WCNSS_PIL=m CONFIG_TI_K3_DSP_REMOTEPROC=m +CONFIG_TI_K3_M4_REMOTEPROC=m CONFIG_TI_K3_R5_REMOTEPROC=m CONFIG_RPMSG_CHAR=m CONFIG_RPMSG_CTRL=m -- 2.39.2
[PATCH v11 6/9] arm64: dts: ti: k3-am64: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index ec17285869da6..b98e8ad453289 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -160,4 +160,17 @@ mcu_esm: esm@410 {
reg = <0x00 0x410 0x00 0x1000>;
ti,esm-pins = <0>, <1>;
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ resets = <_reset 9 1>;
+ firmware-name = "am64-mcu-m4f0_0-fw";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ status = "disabled";
+ };
};
--
2.39.2
[PATCH v11 5/9] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 44ff67b6bf1e4..6957b3e44c82f 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -56,6 +56,18 @@ linux,cma {
linux,cma-default;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb0 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc0 0x00 0xe0>;
+ no-map;
+ };
+
secure_tfa_ddr: tfa@9e78 {
reg = <0x00 0x9e78 0x00 0x8>;
alignment = <0x1000>;
@@ -464,6 +476,13 @@ mbox_m4_0: mbox-m4-0 {
};
};
+_m4fss {
+ mboxes = <_cluster0 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
{
bootph-all;
status = "okay";
--
2.39.2
[PATCH v11 3/9] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 +++
3 files changed, 681 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index dda2ada215b7c..0f0862e20a932 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -340,6 +340,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..09f0484a90e10
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,667 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+#define K3_M4_IRAM_DEV_ADDR 0x0
+#define K3_M4_DRAM_DEV_ADDR 0x3
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memory regions data
+ * @num_rmems: number of reserved memory regions
+ * @reset: reset control handle
+ * @tsp: TI-SCI processor control handle
+ * @ti_sci: TI-SCI handle
+ * @ti_sci_id: TI-SCI device identifier
+ * @mbox: mailbox channel handle
+ * @client: mailbox client to request the mailbox channel
+ *
[PATCH v11 1/9] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 ++
1 file changed, 125 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0..2bd0752b6ba9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla
+ - Mathieu Poirier
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - ti,am64-m4fss
+
+ power-domains:
+maxItems: 1
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+items:
+ - const: iram
+ - const: dram
+
+ resets:
+maxItems: 1
+
+ firmware-name:
+maxItems: 1
+description: Name of firmware to load for the M4F core
+
+ mboxes:
+description:
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+maxItems: 1
+
+ memory-region:
+description:
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. Optional memory regions available for firmware
+ specific purposes.
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
+maxItems: 8
+items:
+ - description: regions used for DMA allocations like vrings, vring
buffers
+ and memory dedicated to firmware's specific purposes.
+additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cb0 0x00 0x10>;
+no-map;
+};
+
+mcu_m4fss_memory_region: m4f-memory@9cc0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cc0 0x00 0xe0>;
+no-map;
+};
+};
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mailbox0_cluster0: mailbox-0 {
+#mbox-cells = <1>;
+};
+
+remoteproc@500 {
+compatible = "ti,am64-m4fss";
+reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+reg-names = "iram", "dram";
+resets = <_reset 9 1>;
+firmware-name = "am62-mcu-m4f0_0-fw";
+mboxes = <_cluster0>, <_m4_0>;
+memory-region = <_m4fss_dma_memory_region>,
+<_m4fss_memory_region>;
+ti,sci = <>;
+ti,sci-dev-id = <9>;
+ti,sci-proc-ids = <0x18 0xff>;
+ };
+};
--
2.39.2
[PATCH v11 0/9] TI K3 M4F support on AM62 and AM64 SoCs
Hello all, This is the continuation of the M4F RProc support series from here[0]. I'm helping out with the upstream task for Hari and so versions (v8+) is a little different than the previous(v7-) postings[0]. Most notable change I've introduced being the patches factoring out common support from the current K3 R5 and DSP drivers have been dropped. I'd like to do that re-factor *after* getting this driver in shape, that way we have 3 similar drivers to factor out from vs trying to make those changes in parallel with the series adding M4 support. Anyway, details on our M4F subsystem can be found the the AM62 TRM in the section on the same: AM62x Technical Reference Manual (SPRUIV7A – MAY 2022) https://www.ti.com/lit/pdf/SPRUIV7A Thanks, Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/ Changes for v11: - Added patch [2/9] factoring out a common function - Addressed comments by Mathieu from v10 - Rebased on v6.11-rc1 - Small reworks in driver for readability Changes for v10: - Rebased on v6.10-rc3 - Added AM64 M4 support in DT - Addressed comments by Mathieu from v9 Changes for v9: - Fixed reserved-memory.yaml text in [1/5] - Split dts patch into one for SoC and one for board enable - Corrected DT property order and formatting [4/5][5/5] Andrew Davis (1): remoteproc: k3: Factor out TI-SCI processor control OF get function Hari Nagalla (7): dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs arm64: dts: ti: k3-am62: Add M4F remoteproc node arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node arm64: dts: ti: k3-am64: Add M4F remoteproc node arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node arm64: defconfig: Enable TI K3 M4 remoteproc driver Martyn Welch (1): remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 + .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 + arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 + arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 + arch/arm64/boot/dts/ti/k3-am642-sk.dts| 19 + arch/arm64/configs/defconfig | 1 + drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +- drivers/remoteproc/ti_k3_m4_remoteproc.c | 667 ++ drivers/remoteproc/ti_k3_r5_remoteproc.c | 28 +- drivers/remoteproc/ti_sci_proc.h | 26 + 13 files changed, 918 insertions(+), 54 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c -- 2.39.2
[PATCH v11 7/9] arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 44ecbcf1c8447..93e2e6f8a07be 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -99,6 +99,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a310 {
no-map;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@a400 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa400 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@a410 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa410 0x00 0xf0>;
+ no-map;
+ };
+
rtos_ipc_memory_region: ipc-memories@a500 {
reg = <0x00 0xa500 0x00 0x0080>;
alignment = <0x1000>;
@@ -678,6 +690,13 @@ _r5fss1_core1 {
<_r5fss1_core1_memory_region>;
};
+_m4fss {
+ mboxes = <_cluster6 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
{
status = "okay";
/* PWM is available on Pin 1 of header J3 */
--
2.39.2
[PATCH v11 2/9] remoteproc: k3: Factor out TI-SCI processor control OF get function
Building the TSP structure is common for users of the TI-SCI processor
control interface. Factor out this function and put it with the rest
of the TI-SCI processor control functions.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +--
drivers/remoteproc/ti_k3_r5_remoteproc.c | 28 +--
drivers/remoteproc/ti_sci_proc.h | 26 +
3 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index a22d41689a7d2..1585769092924 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -636,32 +636,6 @@ static void k3_dsp_release_tsp(void *data)
ti_sci_proc_release(tsp);
}
-static
-struct ti_sci_proc *k3_dsp_rproc_of_get_tsp(struct device *dev,
- const struct ti_sci_handle *sci)
-{
- struct ti_sci_proc *tsp;
- u32 temp[2];
- int ret;
-
- ret = of_property_read_u32_array(dev->of_node, "ti,sci-proc-ids",
-temp, 2);
- if (ret < 0)
- return ERR_PTR(ret);
-
- tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
- if (!tsp)
- return ERR_PTR(-ENOMEM);
-
- tsp->dev = dev;
- tsp->sci = sci;
- tsp->ops = >ops.proc_ops;
- tsp->proc_id = temp[0];
- tsp->host_id = temp[1];
-
- return tsp;
-}
-
static int k3_dsp_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -711,7 +685,7 @@ static int k3_dsp_rproc_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(kproc->reset),
"failed to get reset\n");
- kproc->tsp = k3_dsp_rproc_of_get_tsp(dev, kproc->ti_sci);
+ kproc->tsp = ti_sci_proc_of_get_tsp(dev, kproc->ti_sci);
if (IS_ERR(kproc->tsp))
return dev_err_probe(dev, PTR_ERR(kproc->tsp),
"failed to construct ti-sci proc
control\n");
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 39a47540c5900..dd6294ab81e2e 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -1533,32 +1533,6 @@ static int k3_r5_core_of_get_sram_memories(struct
platform_device *pdev,
return 0;
}
-static
-struct ti_sci_proc *k3_r5_core_of_get_tsp(struct device *dev,
- const struct ti_sci_handle *sci)
-{
- struct ti_sci_proc *tsp;
- u32 temp[2];
- int ret;
-
- ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
-temp, 2);
- if (ret < 0)
- return ERR_PTR(ret);
-
- tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
- if (!tsp)
- return ERR_PTR(-ENOMEM);
-
- tsp->dev = dev;
- tsp->sci = sci;
- tsp->ops = >ops.proc_ops;
- tsp->proc_id = temp[0];
- tsp->host_id = temp[1];
-
- return tsp;
-}
-
static int k3_r5_core_of_init(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -1633,7 +1607,7 @@ static int k3_r5_core_of_init(struct platform_device
*pdev)
goto err;
}
- core->tsp = k3_r5_core_of_get_tsp(dev, core->ti_sci);
+ core->tsp = ti_sci_proc_of_get_tsp(dev, core->ti_sci);
if (IS_ERR(core->tsp)) {
ret = PTR_ERR(core->tsp);
dev_err(dev, "failed to construct ti-sci proc control, ret =
%d\n",
diff --git a/drivers/remoteproc/ti_sci_proc.h b/drivers/remoteproc/ti_sci_proc.h
index 778558abcdcc5..f3911ce75252e 100644
--- a/drivers/remoteproc/ti_sci_proc.h
+++ b/drivers/remoteproc/ti_sci_proc.h
@@ -28,6 +28,32 @@ struct ti_sci_proc {
u8 host_id;
};
+static inline
+struct ti_sci_proc *ti_sci_proc_of_get_tsp(struct device *dev,
+ const struct ti_sci_handle *sci)
+{
+ struct ti_sci_proc *tsp;
+ u32 temp[2];
+ int ret;
+
+ ret = of_property_read_u32_array(dev_of_node(dev), "ti,sci-proc-ids",
+temp, 2);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ tsp = devm_kzalloc(dev, sizeof(*tsp), GFP_KERNEL);
+ if (!tsp)
+ return ERR_PTR(-ENOMEM);
+
+ tsp->dev = dev;
+ tsp->sci = sci;
+ tsp->ops = >ops.proc_ops;
+ tsp->proc_id = temp[0];
+ tsp->host_id = temp[1];
+
+ return tsp;
+}
+
static inline int ti_sci_proc_request(struct ti_sci_proc *tsp)
{
int ret;
--
2.39.2
[PATCH v11 4/9] arm64: dts: ti: k3-am62: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..7f6f0007e8e81 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,17 @@ mcu_mcan1: can@4e18000 {
bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
status = "disabled";
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ resets = <_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ status = "disabled";
+ };
};
--
2.39.2
Re: [PATCH v7 3/3] vdpa/mlx5: Add the support of set mac address
> +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev, struct
> vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct virtio_net_config *config;
> + struct mlx5_core_dev *pfmdev;
> + struct mlx5_vdpa_dev *mvdev;
> + struct mlx5_vdpa_net *ndev;
> + struct mlx5_core_dev *mdev;
> + int err = -EINVAL;
I would say this should also be EOPNOTSUPP.
> +
> + mvdev = to_mvdev(dev);
> + ndev = to_mlx5_vdpa_ndev(mvdev);
> + mdev = mvdev->mdev;
> + config = >config;
> +
> + down_write(>reslock);
> + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> + if (!err)
> + ether_addr_copy(config->mac, add_config->net.mac);
> + }
> +
> + up_write(>reslock);
> + return err;
Andrew
---
pw-bot: cr
Re: [PATCH v7 2/3] vdpa_sim_net: Add the support of set mac address
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev, struct
> vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(>mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + ether_addr_copy(vio_config->mac, config->net.mac);
> + mutex_unlock(>mutex);
> + return 0;
> + }
> +
> + mutex_unlock(>mutex);
> + return -EINVAL;
EOPNOTSUPP would be more appropriate.
Andrew
Re: [PATCH v7 1/3] vdpa: support set mac address from vdpa tool
> +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> + struct genl_info *info)
> +{
> + struct vdpa_dev_set_config set_config = {};
> + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> + struct nlattr **nl_attrs = info->attrs;
> + const u8 *macaddr;
> + int err = -EINVAL;
> +
> + down_write(>cf_lock);
> + if (nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> +
> + if (is_valid_ether_addr(macaddr)) {
> + ether_addr_copy(set_config.net.mac, macaddr);
> + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
ether_addr_copy() and memcpy()?
> + if (mdev->ops->dev_set_attr) {
> + err = mdev->ops->dev_set_attr(mdev, vdev,
> + _config);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> +"device does not support
> changing the MAC address");
You would generally return EOPNOTSUPP in this case, not EINVAL.
Also, the device does not support setting attributes. Given the
generic name, i assume you plan to set other attributes in the future,
at which point this error message will be wrong.
Andrew
[PATCH] rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table
Module aliases are used by userspace to identify the correct module to
load for a detected hardware. The currently supported RPMSG device IDs for
this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev".
Use the helper macro MODULE_DEVICE_TABLE(rpmsg) to export the correct
supported IDs. And while here, to keep backwards compatibility we also add
the other ID "rpmsg_chrdev" so that it is also still exported as an alias.
This has the side benefit of adding support for some legacy firmware
which still uses the original "rpmsg_chrdev" ID. This was the ID used for
this driver before it was upstreamed (as reflected by the module alias).
Signed-off-by: Andrew Davis
---
drivers/rpmsg/rpmsg_char.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index eec7642d26863..96fcdd2d7093c 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -522,8 +522,10 @@ static void rpmsg_chrdev_remove(struct rpmsg_device *rpdev)
static struct rpmsg_device_id rpmsg_chrdev_id_table[] = {
{ .name = "rpmsg-raw" },
+ { .name = "rpmsg_chrdev" },
{ },
};
+MODULE_DEVICE_TABLE(rpmsg, rpmsg_chrdev_id_table);
static struct rpmsg_driver rpmsg_chrdev_driver = {
.probe = rpmsg_chrdev_probe,
@@ -565,6 +567,5 @@ static void rpmsg_chrdev_exit(void)
}
module_exit(rpmsg_chrdev_exit);
-MODULE_ALIAS("rpmsg:rpmsg_chrdev");
MODULE_DESCRIPTION("RPMSG device interface");
MODULE_LICENSE("GPL v2");
--
2.39.2
Re: [PATH v5 2/3] vdpa_sim_net: Add the support of set mac address
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(>mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
ether_addr_copy()
Andrew
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
_config_dump(struct device *dev, void *data)
> {
> struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
> @@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
> .doit = vdpa_nl_cmd_dev_stats_get_doit,
> .flags = GENL_ADMIN_PERM,
> },
> + {
> + .cmd = VDPA_CMD_DEV_ATTR_SET,
> + .doit = vdpa_nl_cmd_dev_attr_set_doit,
> + .flags = GENL_ADMIN_PERM,
> + },
> };
>
> static struct genl_family vdpa_nl_family __ro_after_init = {
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 7977ca03ac7a..3511156c10db 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -582,11 +582,20 @@ void vdpa_set_status(struct vdpa_device *vdev, u8
> status);
> *@dev: vdpa device to remove
> *Driver need to remove the specified device by calling
> *_vdpa_unregister_device().
> + * @dev_set_attr: change a vdpa device's attr after it was create
> + *@mdev: parent device to use for device
The indentation looks a bit odd here.
Andrew
---
pw-bot: cr
Re: [PATH v5 0/3] vdpa: support set mac address from vdpa tool
On Tue, Jul 23, 2024 at 01:39:19PM +0800, Cindy Lu wrote: > Add support for setting the MAC address using the VDPA tool. > This feature will allow setting the MAC address using the VDPA tool. > For example, in vdpa_sim_net, the implementation sets the MAC address > to the config space. However, for other drivers, they can implement their > own function, not limited to the config space. > > Changelog v2 > - Changed the function name to prevent misunderstanding > - Added check for blk device > - Addressed the comments > Changelog v3 > - Split the function of the net device from vdpa_nl_cmd_dev_attr_set_doit > - Add a lock for the network device's dev_set_attr operation > - Address the comments > Changelog v4 > - Address the comments > - Add a lock for the vdap_sim?_net device's dev_set_attr operation > Changelog v5 > - Address the comments This history is to help reviewers of previous versions know if there comments have been addressed. Just saying 'Address the comments' is not useful. Please give a one line summary of each of the comment which has been addressed, maybe including how it was addressed. Andrew
Re: [PATCH] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 08, 2024 at 02:55:49PM +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 26ba7da6b410..f78701386690 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -3616,10 +3616,33 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> *v_mdev, struct vdpa_device *
> destroy_workqueue(wq);
> mgtdev->ndev = NULL;
> }
> +static int mlx5_vdpa_set_attr_mac(struct vdpa_mgmt_dev *v_mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct mlx5_vdpa_dev *mvdev = to_mvdev(dev);
> + struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> + struct mlx5_core_dev *mdev = mvdev->mdev;
> + struct virtio_net_config *config = >config;
> + int err;
> + struct mlx5_core_dev *pfmdev;
> +
> + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + if (!is_zero_ether_addr(add_config->net.mac)) {
Is the core happy to call into the driver without validating the MAC
address? Will the core pass the broadcast address? That is not
zero. Or a multicast address? Should every driver repeat the same
validation, and probably get it just as wrong?
Andrew
---
pw-bot: cr
Re: [PATCH v2] remoteproc: k3-dsp: Fix log levels where appropriate
On 6/26/24 2:14 PM, Garrett Giordano wrote: Driver was logging information as errors. Changed dev_err to dev_dbg where appropriate. Signed-off-by: Garrett Giordano --- Acked-by: Andrew Davis -v2 - Change from dev_info to dev_dbg - Drop k3-r5 PATCH --- drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c index 3555b535b168..a22d41689a7d 100644 --- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c +++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c @@ -327,7 +327,7 @@ static int k3_dsp_rproc_start(struct rproc *rproc) goto put_mbox; } - dev_err(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr); + dev_dbg(dev, "booting DSP core using boot addr = 0x%x\n", boot_addr); ret = ti_sci_proc_set_config(kproc->tsp, boot_addr, 0, 0); if (ret) goto put_mbox; -- 2.25.1
Re: [PATCH 4/4] remoteproc: k3-r5: support for graceful stop of remote cores
On 6/21/24 10:00 AM, Richard Genoud wrote:
Introduce software IPC handshake between the K3-R5 remote proc driver
and the R5 MCU to gracefully stop/reset the remote core.
Upon a stop request, K3-R5 remote proc driver sends a RP_MBOX_SHUTDOWN
mailbox message to the remote R5 core.
The remote core is expected to:
- relinquish all the resources acquired through Device Manager (DM)
- disable its interrupts
- send back a mailbox acknowledgment RP_MBOX_SHUDOWN_ACK
- enter WFI state.
Meanwhile, the K3-R5 remote proc driver does:
- wait for the RP_MBOX_SHUTDOWN_ACK from the remote core
- wait for the remote proc to enter WFI state
- reset the remote core through device manager
Based on work from: Hari Nagalla
Signed-off-by: Richard Genoud
---
drivers/remoteproc/omap_remoteproc.h | 9 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 40
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/omap_remoteproc.h
b/drivers/remoteproc/omap_remoteproc.h
index 828e13256c02..c008f11fa2a4 100644
--- a/drivers/remoteproc/omap_remoteproc.h
+++ b/drivers/remoteproc/omap_remoteproc.h
@@ -42,6 +42,11 @@
* @RP_MBOX_SUSPEND_CANCEL: a cancel suspend response from a remote processor
* on a suspend request
*
+ * @RP_MBOX_SHUTDOWN: shutdown request for the remote processor
+ *
+ * @RP_MBOX_SHUTDOWN_ACK: successful response from remote processor for a
+ * shutdown request. The remote processor should be in WFI state short after.
+ *
* Introduce new message definitions if any here.
*
* @RP_MBOX_END_MSG: Indicates end of known/defined messages from remote core
@@ -59,7 +64,9 @@ enum omap_rp_mbox_messages {
RP_MBOX_SUSPEND_SYSTEM = 0xFF11,
RP_MBOX_SUSPEND_ACK = 0xFF12,
RP_MBOX_SUSPEND_CANCEL = 0xFF13,
- RP_MBOX_END_MSG = 0xFF14,
+ RP_MBOX_SHUTDOWN= 0xFF14,
+ RP_MBOX_SHUTDOWN_ACK= 0xFF15,
+ RP_MBOX_END_MSG = 0xFF16,
};
#endif /* _OMAP_RPMSG_H */
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index a2ead87952c7..918a15e1dd9a 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -172,8 +173,23 @@ struct k3_r5_rproc {
struct k3_r5_core *core;
struct k3_r5_mem *rmem;
int num_rmems;
+ struct completion shutdown_complete;
};
+/*
+ * This will return true if the remote core is in Wait For Interrupt state.
+ */
+static bool k3_r5_is_core_in_wfi(struct k3_r5_core *core)
+{
+ int ret;
+ u64 boot_vec;
+ u32 cfg, ctrl, stat;
+
+ ret = ti_sci_proc_get_status(core->tsp, _vec, , , );
+
+ return !ret ? !!(stat & PROC_BOOT_STATUS_FLAG_R5_WFI) : false;
Too fancy for me :) Just return if (ret) right after get_status().
Looks like this function is called in a polling loop, if
ti_sci_proc_get_status() fails once, it won't get better,
no need to keep checking, we should just error out of
the polling loop.
Andrew
+}
+
/**
* k3_r5_rproc_mbox_callback() - inbound mailbox message handler
* @client: mailbox client pointer used for requesting the mailbox channel
@@ -209,6 +225,10 @@ static void k3_r5_rproc_mbox_callback(struct mbox_client
*client, void *data)
case RP_MBOX_ECHO_REPLY:
dev_info(dev, "received echo reply from %s\n", name);
break;
+ case RP_MBOX_SHUTDOWN_ACK:
+ dev_dbg(dev, "received shutdown_ack from %s\n", name);
+ complete(>shutdown_complete);
+ break;
default:
/* silently handle all other valid messages */
if (msg >= RP_MBOX_READY && msg < RP_MBOX_END_MSG)
@@ -634,6 +654,7 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
struct k3_r5_cluster *cluster = kproc->cluster;
struct device *dev = kproc->dev;
struct k3_r5_core *core1, *core = kproc->core;
+ bool wfi;
int ret;
@@ -650,6 +671,24 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
}
}
+ /* Send SHUTDOWN message to remote proc */
+ reinit_completion(>shutdown_complete);
+ ret = mbox_send_message(kproc->mbox, (void *)RP_MBOX_SHUTDOWN);
+ if (ret < 0) {
+ dev_err(dev, "Sending SHUTDOWN message failed: %d. Halting core
anyway.\n", ret);
+ } else {
+ ret = wait_for_completion_timeout(>shutdown_complete,
+ msecs_to_jiffies(1000));
+ if (ret == 0) {
+ dev_err(dev, "Timeout waiting SHUTDOWN_ACK message. Halting
core anyway.\n");
+ } else {
+ ret = readx_poll_timeout(k3_r5_is_co
Re: [PATCH v2 00/13] OMAP mailbox FIFO removal
On 6/26/24 9:39 AM, Dominic Rath wrote: On 13.06.2024 14:22, Andrew Davis wrote: We looked into this some time ago, and noticed that the IRQ approach caused problems in the virtio/rpmsg code. I'd like to understand if your change was for the same reason, or something else we missed before. It is most likely the same reason. Seems despite its name, rproc_vq_interrupt() cannot be called from an IRQ/atomic context. As the following backtrace shows, that function calls down into functions which are not IRQ safe. So we needed to keep it threaded: [ 5.389374] BUG: scheduling while atomic: (udev-worker)/232/0x00010002 [ 5.395917] Modules linked in: videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 phy_j721e_wiz display_connector omap_mailbox(+) videodev tps6594_i2c(+) videobuf2_common phy_can_transceiver at24 cd6 [ 5.433562] CPU: 0 PID: 232 Comm: (udev-worker) Not tainted 6.10.0-rc1-next-20240528-dirty #10 [ 5.442158] Hardware name: Texas Instruments AM69 SK (DT) [ 5.447540] Call trace: [ 5.449976] dump_backtrace+0x94/0xec [ 5.453640] show_stack+0x18/0x24 [ 5.456944] dump_stack_lvl+0x78/0x90 [ 5.460598] dump_stack+0x18/0x24 [ 5.463900] __schedule_bug+0x50/0x68 [ 5.467552] __schedule+0x80c/0xb0c [ 5.471029] schedule+0x34/0x104 [ 5.474243] schedule_preempt_disabled+0x24/0x40 [ 5.478845] rwsem_down_write_slowpath+0x31c/0x56c [ 5.483622] down_write+0x90/0x94 [ 5.486924] kernfs_add_one+0x3c/0x148 [ 5.490661] kernfs_create_dir_ns+0x50/0x94 [ 5.494830] sysfs_create_dir_ns+0x70/0x10c [ 5.498999] kobject_add_internal+0x98/0x26c [ 5.503254] kobject_add+0x9c/0x10c [ 5.506729] device_add+0xc0/0x790 [ 5.510120] rpmsg_register_device_override+0x10c/0x1c0 [ 5.515333] rpmsg_register_device+0x14/0x20 [ 5.519590] virtio_rpmsg_create_channel+0xb0/0x104 [ 5.524452] rpmsg_create_channel+0x28/0x60 [ 5.528622] rpmsg_ns_cb+0x100/0x1dc [ 5.532185] rpmsg_recv_done+0x114/0x2e4 [ 5.536094] vring_interrupt+0x68/0xa4 [ 5.539833] rproc_vq_interrupt+0x2c/0x48 [ 5.543830] k3_r5_rproc_mbox_callback+0x84/0x90 [ti_k3_r5_remoteproc] [ 5.550348] mbox_chan_received_data+0x1c/0x2c [ 5.554779] mbox_interrupt+0xa0/0x17c [omap_mailbox] [ 5.559820] __handle_irq_event_percpu+0x48/0x13c [ 5.564511] handle_irq_event+0x4c/0xac I looked into this a bit more closely, together with the colleague who implemented our internal workaround, and we came up with one more concern: Have you considered that this synchronous path from the (threaded) IRQ draining the mailbox down to the (potentially blocking) rpmsg_* calls might let the hardware mailbox grow full? From what I remember the vring (?) has room for 512 messages, but the hardware mailbox on e.g. the AM64x can only handle four messages. At least with the current implementation on TI's MCU+ SDK running on the R5f that could cause the R5f to block, waiting for room in the hardware mailbox, while there are plenty of vring buffers available. We would like to switch back to the non-threaded handler at some point. As you mention doing this in a threaded way increase the risk of the hardware message queue filling and blocking the remote side. (Plus the threaded handling can add latency to the message handling which should be avoided for real-time reasons) The fix might be to have rpmsg_recv_done() callback simply queue the message and then schedule another worker to actually do the next stage processing. That way complex actions on messages do not block vring_interrupt() which should be treated like an atomic context call. Anyway for now, I'd expect the much faster host core (2xA53 @ 1GHZ in AM64) to be able to outpace the R5s and keep the mailbox drained. Are you actually running into this issue or is the concern based on ensuring RT performance(not blocking on mailbox queue filled) on the R5 side? Andrew Best Regards, Dominic
Re: [PATCH v7 00/38] kmsan: Enable on s390
On Fri, 21 Jun 2024 13:34:44 +0200 Ilya Leoshkevich wrote: > v6 -> v7: Drop the ptdump patch. > All patches are reviewed. I added v7 to mm.git (and hence linux-next).
Re: [PATCH v2 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe
On 6/21/24 6:14 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests for mbox handle later during rproc start/attach. This also
allows to defer remoteproc driver's probe if mailbox is not probed yet.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 74 +---
1 file changed, 26 insertions(+), 48 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 26362a509ae3c..7e02e3472ce25 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -194,6 +194,10 @@ static void k3_r5_rproc_mbox_callback(struct mbox_client
*client, void *data)
const char *name = kproc->rproc->name;
u32 msg = omap_mbox_message(data);
+ /* Do not forward message to a detached core */
s/to/from
This is the receive side from the core.
+ if (kproc->rproc->state == RPROC_DETACHED)
+ return;
+
Do we need a similar check when sending messages to the core in
k3_r5_rproc_kick()? No one should be sending anything as they
all should have detached at this point, but something to double
check on.
Will add this in the next revision.
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
switch (msg) {
@@ -399,12 +403,9 @@ static int k3_r5_rproc_request_mbox(struct rproc *rproc)
client->knows_txdone = false;
kproc->mbox = mbox_request_channel(client, 0);
- if (IS_ERR(kproc->mbox)) {
- ret = -EBUSY;
- dev_err(dev, "mbox_request_channel failed: %ld\n",
- PTR_ERR(kproc->mbox));
- return ret;
- }
+ if (IS_ERR(kproc->mbox))
+ return dev_err_probe(dev, PTR_ERR(kproc->mbox),
+ "mbox_request_channel failed\n");
This is good cleanup, but maybe something for its own patch.
I think this cleanup is dependent to this patch itself. The current patch moves
the mbox_handle_request to probe routine. And the cleanup returns an
-EDEFER_PROBE ERR code. So, this cleanup is only valid if the current patch is
applied. Else, if this err code is returned at any point after creation of
child devices, it could lead to a infinite loop[0]. Please correct me if I am
wrong..?
Okay I see what you are saying, k3_r5_rproc_request_mbox() is now called from
probe() and not start() as it was before. Then you are correct.
Andrew
[0]:
https://www.kernel.org/doc/html/v6.5-rc3/driver-api/driver-model/driver.html#callbacks
/*
* Ping the remote processor, this is only for sanity-sake for now;
@@ -552,10 +553,6 @@ static int k3_r5_rproc_start(struct rproc *rproc)
u32 boot_addr;
int ret;
- ret = k3_r5_rproc_request_mbox(rproc);
- if (ret)
- return ret;
-
boot_addr = rproc->bootaddr;
/* TODO: add boot_addr sanity checking */
dev_dbg(dev, "booting R5F core using boot addr = 0x%x\n", boot_addr);
@@ -564,7 +561,7 @@ static int k3_r5_rproc_start(struct rproc *rproc)
core = kproc->core;
ret = ti_sci_proc_set_config(core->tsp, boot_addr, 0, 0);
if (ret)
- goto put_mbox;
+ return ret;
/* unhalt/run all applicable cores */
if (cluster->mode == CLUSTER_MODE_LOCKSTEP) {
@@ -580,13 +577,12 @@ static int k3_r5_rproc_start(struct rproc *rproc)
if (core != core0 && core0->rproc->state == RPROC_OFFLINE) {
dev_err(dev, "%s: can not start core 1 before core 0\n",
__func__);
- ret = -EPERM;
- goto put_mbox;
+ return -EPERM;
}
ret = k3_r5_core_run(core);
if (ret)
- goto put_mbox;
+ return ret;
}
return 0;
@@ -596,8 +592,6 @@ static int k3_r5_rproc_start(struct rproc *rproc)
if (k3_r5_core_halt(core))
dev_warn(core->dev, "core halt back failed\n");
}
-put_mbox:
- mbox_free_channel(kproc->mbox);
return ret;
}
@@ -658,8 +652,6 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
goto out;
}
- mbox_free_channel(kproc->mbox);
-
return 0;
unroll_core_halt:
@@ -674,42 +666,22 @@ static int k3_r5_rproc_stop(struct rproc *rproc)
/*
* Attach to a running R5F remote processor (IPC-only mode)
*
- * The R5F attach callback only needs to request the mailbox, the remote
- * processor is already booted, so there is no need to issue any TI-SCI
- * commands to boot the R5F cores in IPC-only mode. This callback is invoked
- * only in IPC-only mode.
+ * The R5F attach callback is a NOP. The remote processor is already booted,
and
+ * all required resources have be
Re: [PATCH v10 2/8] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 6/18/24 12:05 PM, Mathieu Poirier wrote:
Good morning,
On Mon, Jun 10, 2024 at 01:06:09PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 760 +++
3 files changed, 774 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..880e8f0ad1ba3
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,760 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handle
+ * @mem: internal mem
Re: [PATCH] linux++: delete some forward declarations
On Thu, 13 Jun 2024 16:10:12 -0400 Steven Rostedt wrote: > > And... I'm a bit surprised that forward declarations are allowed in C. > > A billion years ago I used a C compiler which would use 16 bits for > > an enum if the enumted values would fit in 16 bits. And it would use 32 > > bits otherwise. So the enumerated values were *required* for the > > compiler to be able to figure out the sizeof. But it was a billion > > years ago. > > Well, I only looked at the one change in ftrace.h which has a > "struct seq_file;" that is not used anywhere else in the file, so that > one definitely can go. The risk is that something which includes ftrace.h is depending upon the enum declaration.
Re: [PATCH] linux++: delete some forward declarations
On Thu, 13 Jun 2024 15:34:02 -0400 Steven Rostedt wrote: > On Thu, 13 Jun 2024 22:22:18 +0300 > Alexey Dobriyan wrote: > > > g++ doesn't like forward enum declarations: > > > > error: use of enum ‘E’ without previous declaration > >64 | enum E; > > But we don't care about g++. Do we? It appears that g++ is a useful enum declaration detector. I'm curious to know how even the above warning was generated. Does g++ work at all on Linux? > I would make that a separate patch. What are you referring to here? > > > > Delete those which aren't used. > > > > Delete some unused/unnecessary forward struct declarations for a change. > > This is a clean up, but should have a better change log. Just something > simple like: > > Delete unnecessary forward struct declarations. Alexey specializes in cute changelogs. I do have a concern about the patch: has it been tested with all possible Kconfigs? No. There may be some configs in which the forward declaration is required. And... I'm a bit surprised that forward declarations are allowed in C. A billion years ago I used a C compiler which would use 16 bits for an enum if the enumted values would fit in 16 bits. And it would use 32 bits otherwise. So the enumerated values were *required* for the compiler to be able to figure out the sizeof. But it was a billion years ago.
Re: [PATCH v2 00/13] OMAP mailbox FIFO removal
On 6/13/24 2:58 AM, Dominic Rath wrote: Hello Andrew, On 10.04.2024 15:59, Andrew Davis wrote: Changes for v2: - Use threaded irq as suggested by Hari and to fix possible "scheduling while atomic" issue sorry for beeing late, I noticed this already got merged. I was wondering what the reason was for ending up with the threaded irq. In your v1 thread your final conclusion appeared to be So for now I just kept this using the regular IRQ context as before. We looked into this some time ago, and noticed that the IRQ approach caused problems in the virtio/rpmsg code. I'd like to understand if your change was for the same reason, or something else we missed before. It is most likely the same reason. Seems despite its name, rproc_vq_interrupt() cannot be called from an IRQ/atomic context. As the following backtrace shows, that function calls down into functions which are not IRQ safe. So we needed to keep it threaded: [5.389374] BUG: scheduling while atomic: (udev-worker)/232/0x00010002 [5.395917] Modules linked in: videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 phy_j721e_wiz display_connector omap_mailbox(+) videodev tps6594_i2c(+) videobuf2_common phy_can_transceiver at24 cd6 [5.433562] CPU: 0 PID: 232 Comm: (udev-worker) Not tainted 6.10.0-rc1-next-20240528-dirty #10 [5.442158] Hardware name: Texas Instruments AM69 SK (DT) [5.447540] Call trace: [5.449976] dump_backtrace+0x94/0xec [5.453640] show_stack+0x18/0x24 [5.456944] dump_stack_lvl+0x78/0x90 [5.460598] dump_stack+0x18/0x24 [5.463900] __schedule_bug+0x50/0x68 [5.467552] __schedule+0x80c/0xb0c [5.471029] schedule+0x34/0x104 [5.474243] schedule_preempt_disabled+0x24/0x40 [5.478845] rwsem_down_write_slowpath+0x31c/0x56c [5.483622] down_write+0x90/0x94 [5.486924] kernfs_add_one+0x3c/0x148 [5.490661] kernfs_create_dir_ns+0x50/0x94 [5.494830] sysfs_create_dir_ns+0x70/0x10c [5.498999] kobject_add_internal+0x98/0x26c [5.503254] kobject_add+0x9c/0x10c [5.506729] device_add+0xc0/0x790 [5.510120] rpmsg_register_device_override+0x10c/0x1c0 [5.515333] rpmsg_register_device+0x14/0x20 [5.519590] virtio_rpmsg_create_channel+0xb0/0x104 [5.524452] rpmsg_create_channel+0x28/0x60 [5.528622] rpmsg_ns_cb+0x100/0x1dc [5.532185] rpmsg_recv_done+0x114/0x2e4 [5.536094] vring_interrupt+0x68/0xa4 [5.539833] rproc_vq_interrupt+0x2c/0x48 [5.543830] k3_r5_rproc_mbox_callback+0x84/0x90 [ti_k3_r5_remoteproc] [5.550348] mbox_chan_received_data+0x1c/0x2c [5.554779] mbox_interrupt+0xa0/0x17c [omap_mailbox] [5.559820] __handle_irq_event_percpu+0x48/0x13c [5.564511] handle_irq_event+0x4c/0xac Andrew Regards, Dominic
[PATCH v10 2/8] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 760 +++
3 files changed, 774 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..880e8f0ad1ba3
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,760 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handle
+ * @mem: internal memory regions data
+ * @num_mems: number of internal memory regions
+ * @rmem: reserved memory regions data
+ * @num_rmems: number of
[PATCH v10 6/8] arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 5b028b3a3192f..727d467ed2c1d 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -99,6 +99,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a310 {
no-map;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@a400 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa400 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@a410 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa410 0x00 0xf0>;
+ no-map;
+ };
+
rtos_ipc_memory_region: ipc-memories@a500 {
reg = <0x00 0xa500 0x00 0x0080>;
alignment = <0x1000>;
@@ -666,6 +678,13 @@ _r5fss1_core1 {
<_r5fss1_core1_memory_region>;
};
+_m4fss {
+ mboxes = <_cluster6 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
{
status = "okay";
/* PWM is available on Pin 1 of header J3 */
--
2.39.2
[PATCH v10 8/8] arm64: defconfig: Enable TI K3 M4 remoteproc driver
From: Hari Nagalla Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 57a9abe78ee41..b7a3488ad4f94 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1369,6 +1369,7 @@ CONFIG_QCOM_Q6V5_PAS=m CONFIG_QCOM_SYSMON=m CONFIG_QCOM_WCNSS_PIL=m CONFIG_TI_K3_DSP_REMOTEPROC=m +CONFIG_TI_K3_M4_REMOTEPROC=m CONFIG_TI_K3_R5_REMOTEPROC=m CONFIG_RPMSG_CHAR=m CONFIG_RPMSG_CTRL=m -- 2.39.2
[PATCH v10 7/8] arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index e20e4ffd0f1fa..6dbb26a1bc768 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -101,6 +101,18 @@ main_r5fss1_core1_memory_region: r5f-memory@a310 {
no-map;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@a400 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa400 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@a410 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa410 0x00 0xf0>;
+ no-map;
+ };
+
rtos_ipc_memory_region: ipc-memories@a500 {
reg = <0x00 0xa500 0x00 0x0080>;
alignment = <0x1000>;
@@ -763,6 +775,13 @@ _r5fss1_core1 {
<_r5fss1_core1_memory_region>;
};
+_m4fss {
+ mboxes = <_cluster6 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
_ln_ctrl {
idle-states = ;
};
--
2.39.2
[PATCH v10 5/8] arm64: dts: ti: k3-am64: Add M4F remoteproc node
From: Hari Nagalla
The AM64x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index ec17285869da6..b98e8ad453289 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -160,4 +160,17 @@ mcu_esm: esm@410 {
reg = <0x00 0x410 0x00 0x1000>;
ti,esm-pins = <0>, <1>;
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ resets = <_reset 9 1>;
+ firmware-name = "am64-mcu-m4f0_0-fw";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ status = "disabled";
+ };
};
--
2.39.2
[PATCH v10 4/8] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 3c45782ab2b78..167bec5c80006 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -48,6 +48,18 @@ ramoops@9ca0 {
pmsg-size = <0x8000>;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb0 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc0 0x00 0xe0>;
+ no-map;
+ };
+
secure_tfa_ddr: tfa@9e78 {
reg = <0x00 0x9e78 0x00 0x8>;
alignment = <0x1000>;
@@ -457,6 +469,13 @@ mbox_m4_0: mbox-m4-0 {
};
};
+_m4fss {
+ mboxes = <_cluster0 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
{
bootph-all;
status = "okay";
--
2.39.2
[PATCH v10 0/8] TI K3 M4F support on AM62 and AM64 SoCs
Hello all, This is the continuation of the M4F RProc support series from here[0]. I'm helping out with the upstream task for Hari and so versions (v8+) is a little different than the previous(v7-) postings[0]. Most notable change I've introduced being the patches factoring out common support from the current K3 R5 and DSP drivers have been dropped. I'd like to do that re-factor *after* getting this driver in shape, that way we have 3 similar drivers to factor out from vs trying to make those changes in parallel with the series adding M4 support. Anyway, details on our M4F subsystem can be found the the AM62 TRM in the section on the same: AM62x Technical Reference Manual (SPRUIV7A – MAY 2022) https://www.ti.com/lit/pdf/SPRUIV7A Thanks, Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/ Changes for v10: - Rebased on v6.10-rc3 - Added AM64 M4 support in DT - Addressed comments by Mathieu from v9 Changes for v9: - Fixed reserved-memory.yaml text in [1/5] - Split dts patch into one for SoC and one for board enable - Corrected DT property order and formatting [4/5][5/5] Hari Nagalla (7): dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs arm64: dts: ti: k3-am62: Add M4F remoteproc node arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node arm64: dts: ti: k3-am64: Add M4F remoteproc node arm64: dts: ti: k3-am642-sk: Add M4F remoteproc node arm64: dts: ti: k3-am642-evm: Add M4F remoteproc node arm64: defconfig: Enable TI K3 M4 remoteproc driver Martyn Welch (1): remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 +++ arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 + .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 + arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 + arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 + arch/arm64/boot/dts/ti/k3-am642-sk.dts| 19 + arch/arm64/configs/defconfig | 1 + drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_m4_remoteproc.c | 760 ++ 10 files changed, 983 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c -- 2.39.2
[PATCH v10 1/8] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 ++
1 file changed, 125 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0..2bd0752b6ba9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla
+ - Mathieu Poirier
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - ti,am64-m4fss
+
+ power-domains:
+maxItems: 1
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+items:
+ - const: iram
+ - const: dram
+
+ resets:
+maxItems: 1
+
+ firmware-name:
+maxItems: 1
+description: Name of firmware to load for the M4F core
+
+ mboxes:
+description:
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+maxItems: 1
+
+ memory-region:
+description:
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. Optional memory regions available for firmware
+ specific purposes.
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
+maxItems: 8
+items:
+ - description: regions used for DMA allocations like vrings, vring
buffers
+ and memory dedicated to firmware's specific purposes.
+additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cb0 0x00 0x10>;
+no-map;
+};
+
+mcu_m4fss_memory_region: m4f-memory@9cc0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cc0 0x00 0xe0>;
+no-map;
+};
+};
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mailbox0_cluster0: mailbox-0 {
+#mbox-cells = <1>;
+};
+
+remoteproc@500 {
+compatible = "ti,am64-m4fss";
+reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+reg-names = "iram", "dram";
+resets = <_reset 9 1>;
+firmware-name = "am62-mcu-m4f0_0-fw";
+mboxes = <_cluster0>, <_m4_0>;
+memory-region = <_m4fss_dma_memory_region>,
+<_m4fss_memory_region>;
+ti,sci = <>;
+ti,sci-dev-id = <9>;
+ti,sci-proc-ids = <0x18 0xff>;
+ };
+};
--
2.39.2
[PATCH v10 3/8] arm64: dts: ti: k3-am62: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..7f6f0007e8e81 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,17 @@ mcu_mcan1: can@4e18000 {
bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
status = "disabled";
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ resets = <_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ status = "disabled";
+ };
};
--
2.39.2
[PATCH 1/6] remoteproc: omap: Use devm_rproc_alloc() helper
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 8f50ab80e56f4..e91e016583802 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -1305,8 +1305,8 @@ static int omap_rproc_probe(struct platform_device *pdev)
return ret;
}
- rproc = rproc_alloc(>dev, dev_name(>dev), _rproc_ops,
- firmware, sizeof(*oproc));
+ rproc = devm_rproc_alloc(>dev, dev_name(>dev),
_rproc_ops,
+firmware, sizeof(*oproc));
if (!rproc)
return -ENOMEM;
@@ -1318,15 +1318,15 @@ static int omap_rproc_probe(struct platform_device
*pdev)
ret = omap_rproc_of_get_internal_memories(pdev, rproc);
if (ret)
- goto free_rproc;
+ return ret;
ret = omap_rproc_get_boot_data(pdev, rproc);
if (ret)
- goto free_rproc;
+ return ret;
ret = omap_rproc_of_get_timers(pdev, rproc);
if (ret)
- goto free_rproc;
+ return ret;
init_completion(>pm_comp);
oproc->autosuspend_delay = DEFAULT_AUTOSUSPEND_DELAY;
@@ -1337,10 +1337,8 @@ static int omap_rproc_probe(struct platform_device *pdev)
pm_runtime_set_autosuspend_delay(>dev, oproc->autosuspend_delay);
oproc->fck = devm_clk_get(>dev, 0);
- if (IS_ERR(oproc->fck)) {
- ret = PTR_ERR(oproc->fck);
- goto free_rproc;
- }
+ if (IS_ERR(oproc->fck))
+ return PTR_ERR(oproc->fck);
ret = of_reserved_mem_device_init(>dev);
if (ret) {
@@ -1359,8 +1357,7 @@ static int omap_rproc_probe(struct platform_device *pdev)
release_mem:
of_reserved_mem_device_release(>dev);
-free_rproc:
- rproc_free(rproc);
+
return ret;
}
@@ -1369,7 +1366,6 @@ static void omap_rproc_remove(struct platform_device
*pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- rproc_free(rproc);
of_reserved_mem_device_release(>dev);
}
--
2.39.2
[PATCH 4/6] remoteproc: da8xx: Use devm_rproc_alloc() helper
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/drivers/remoteproc/da8xx_remoteproc.c
index 9041a0e07fb25..c8b7576937733 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -295,8 +295,8 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
}
}
- rproc = rproc_alloc(dev, "dsp", _rproc_ops, da8xx_fw_name,
- sizeof(*drproc));
+ rproc = devm_rproc_alloc(dev, "dsp", _rproc_ops, da8xx_fw_name,
+sizeof(*drproc));
if (!rproc) {
ret = -ENOMEM;
goto free_mem;
@@ -313,7 +313,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
ret = da8xx_rproc_get_internal_memories(pdev, drproc);
if (ret)
- goto free_rproc;
+ goto free_mem;
platform_set_drvdata(pdev, rproc);
@@ -323,7 +323,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
rproc);
if (ret) {
dev_err(dev, "devm_request_threaded_irq error: %d\n", ret);
- goto free_rproc;
+ goto free_mem;
}
/*
@@ -333,7 +333,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
*/
ret = reset_control_assert(dsp_reset);
if (ret)
- goto free_rproc;
+ goto free_mem;
drproc->chipsig = chipsig;
drproc->bootreg = bootreg;
@@ -344,13 +344,11 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
ret = rproc_add(rproc);
if (ret) {
dev_err(dev, "rproc_add failed: %d\n", ret);
- goto free_rproc;
+ goto free_mem;
}
return 0;
-free_rproc:
- rproc_free(rproc);
free_mem:
if (dev->of_node)
of_reserved_mem_device_release(dev);
@@ -371,7 +369,6 @@ static void da8xx_rproc_remove(struct platform_device *pdev)
disable_irq(drproc->irq);
rproc_del(rproc);
- rproc_free(rproc);
if (dev->of_node)
of_reserved_mem_device_release(dev);
}
--
2.39.2
[PATCH 2/6] remoteproc: omap: Use devm action to release reserved memory
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index e91e016583802..df46be84658f7 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -1277,6 +1277,13 @@ static int omap_rproc_of_get_timers(struct
platform_device *pdev,
return 0;
}
+static void omap_rproc_mem_release(void *data)
+{
+ struct device *dev = data;
+
+ of_reserved_mem_device_release(dev);
+}
+
static int omap_rproc_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -1346,19 +1353,17 @@ static int omap_rproc_probe(struct platform_device
*pdev)
dev_warn(>dev, "Typically this should be provided,\n");
dev_warn(>dev, "only omit if you know what you are
doing.\n");
}
+ ret = devm_add_action_or_reset(>dev, omap_rproc_mem_release,
>dev);
+ if (ret)
+ return ret;
platform_set_drvdata(pdev, rproc);
ret = rproc_add(rproc);
if (ret)
- goto release_mem;
+ return ret;
return 0;
-
-release_mem:
- of_reserved_mem_device_release(>dev);
-
- return ret;
}
static void omap_rproc_remove(struct platform_device *pdev)
@@ -1366,7 +1371,6 @@ static void omap_rproc_remove(struct platform_device
*pdev)
struct rproc *rproc = platform_get_drvdata(pdev);
rproc_del(rproc);
- of_reserved_mem_device_release(>dev);
}
static const struct dev_pm_ops omap_rproc_pm_ops = {
--
2.39.2
[PATCH 5/6] remoteproc: da8xx: Use devm action to release reserved memory
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/drivers/remoteproc/da8xx_remoteproc.c
index c8b7576937733..1ce91516fc6e5 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -233,6 +233,13 @@ static int da8xx_rproc_get_internal_memories(struct
platform_device *pdev,
return 0;
}
+static void da8xx_rproc_mem_release(void *data)
+{
+ struct device *dev = data;
+
+ of_reserved_mem_device_release(dev);
+}
+
static int da8xx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -293,14 +300,13 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
ret);
return ret;
}
+ devm_add_action_or_reset(>dev, da8xx_rproc_mem_release,
>dev);
}
rproc = devm_rproc_alloc(dev, "dsp", _rproc_ops, da8xx_fw_name,
sizeof(*drproc));
- if (!rproc) {
- ret = -ENOMEM;
- goto free_mem;
- }
+ if (!rproc)
+ return -ENOMEM;
/* error recovery is not supported at present */
rproc->recovery_disabled = true;
@@ -313,7 +319,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
ret = da8xx_rproc_get_internal_memories(pdev, drproc);
if (ret)
- goto free_mem;
+ return ret;
platform_set_drvdata(pdev, rproc);
@@ -323,7 +329,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
rproc);
if (ret) {
dev_err(dev, "devm_request_threaded_irq error: %d\n", ret);
- goto free_mem;
+ return ret;
}
/*
@@ -333,7 +339,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
*/
ret = reset_control_assert(dsp_reset);
if (ret)
- goto free_mem;
+ return ret;
drproc->chipsig = chipsig;
drproc->bootreg = bootreg;
@@ -344,15 +350,10 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
ret = rproc_add(rproc);
if (ret) {
dev_err(dev, "rproc_add failed: %d\n", ret);
- goto free_mem;
+ return ret;
}
return 0;
-
-free_mem:
- if (dev->of_node)
- of_reserved_mem_device_release(dev);
- return ret;
}
static void da8xx_rproc_remove(struct platform_device *pdev)
@@ -369,8 +370,6 @@ static void da8xx_rproc_remove(struct platform_device *pdev)
disable_irq(drproc->irq);
rproc_del(rproc);
- if (dev->of_node)
- of_reserved_mem_device_release(dev);
}
static const struct of_device_id davinci_rproc_of_match[] __maybe_unused = {
--
2.39.2
[PATCH 6/6] remoteproc: da8xx: Use devm_rproc_add() helper
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/drivers/remoteproc/da8xx_remoteproc.c
index 1ce91516fc6e5..c20cf33429da9 100644
--- a/drivers/remoteproc/da8xx_remoteproc.c
+++ b/drivers/remoteproc/da8xx_remoteproc.c
@@ -321,8 +321,6 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
if (ret)
return ret;
- platform_set_drvdata(pdev, rproc);
-
/* everything the ISR needs is now setup, so hook it up */
ret = devm_request_threaded_irq(dev, irq, da8xx_rproc_callback,
handle_event, 0, "da8xx-remoteproc",
@@ -347,7 +345,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
drproc->irq_data = irq_data;
drproc->irq = irq;
- ret = rproc_add(rproc);
+ ret = devm_rproc_add(dev, rproc);
if (ret) {
dev_err(dev, "rproc_add failed: %d\n", ret);
return ret;
@@ -356,22 +354,6 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
return 0;
}
-static void da8xx_rproc_remove(struct platform_device *pdev)
-{
- struct rproc *rproc = platform_get_drvdata(pdev);
- struct da8xx_rproc *drproc = rproc->priv;
- struct device *dev = >dev;
-
- /*
-* The devm subsystem might end up releasing things before
-* freeing the irq, thus allowing an interrupt to sneak in while
-* the device is being removed. This should prevent that.
-*/
- disable_irq(drproc->irq);
-
- rproc_del(rproc);
-}
-
static const struct of_device_id davinci_rproc_of_match[] __maybe_unused = {
{ .compatible = "ti,da850-dsp", },
{ /* sentinel */ },
@@ -380,7 +362,6 @@ MODULE_DEVICE_TABLE(of, davinci_rproc_of_match);
static struct platform_driver da8xx_rproc_driver = {
.probe = da8xx_rproc_probe,
- .remove_new = da8xx_rproc_remove,
.driver = {
.name = "davinci-rproc",
.of_match_table = of_match_ptr(davinci_rproc_of_match),
--
2.39.2
[PATCH 3/6] remoteproc: omap: Use devm_rproc_add() helper
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index df46be84658f7..9ae2e831456d5 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -1359,20 +1359,13 @@ static int omap_rproc_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, rproc);
- ret = rproc_add(rproc);
+ ret = devm_rproc_add(>dev, rproc);
if (ret)
return ret;
return 0;
}
-static void omap_rproc_remove(struct platform_device *pdev)
-{
- struct rproc *rproc = platform_get_drvdata(pdev);
-
- rproc_del(rproc);
-}
-
static const struct dev_pm_ops omap_rproc_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(omap_rproc_suspend, omap_rproc_resume)
SET_RUNTIME_PM_OPS(omap_rproc_runtime_suspend,
@@ -1381,7 +1374,6 @@ static const struct dev_pm_ops omap_rproc_pm_ops = {
static struct platform_driver omap_rproc_driver = {
.probe = omap_rproc_probe,
- .remove_new = omap_rproc_remove,
.driver = {
.name = "omap-rproc",
.pm = _rproc_pm_ops,
--
2.39.2
Re: [PATCH v2 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe
ot;R5F core initialized in IPC-only mode\n");
- return 0;
-}
+static int k3_r5_rproc_attach(struct rproc *rproc) { return 0; }
I wonder if rproc_validate() should be updated to allow not
having an attach/detach for cases like this. Then we could drop
this function completely.
Andrew
/*
* Detach from a running R5F remote processor (IPC-only mode)
*
- * The R5F detach callback performs the opposite operation to attach callback
- * and only needs to release the mailbox, the R5F cores are not stopped and
- * will be left in booted state in IPC-only mode. This callback is invoked
- * only in IPC-only mode.
+ * The R5F detach callback is a NOP. The R5F cores are not stopped and will be
+ * left in booted state in IPC-only mode. This callback is invoked only in
+ * IPC-only mode and exists for sanity sake.
*/
-static int k3_r5_rproc_detach(struct rproc *rproc)
-{
- struct k3_r5_rproc *kproc = rproc->priv;
- struct device *dev = kproc->dev;
-
- mbox_free_channel(kproc->mbox);
- dev_info(dev, "R5F core deinitialized in IPC-only mode\n");
- return 0;
-}
+static int k3_r5_rproc_detach(struct rproc *rproc) { return 0; }
/*
* This function implements the .get_loaded_rsc_table() callback and is used
@@ -1277,6 +1249,10 @@ static int k3_r5_cluster_rproc_init(struct
platform_device *pdev)
kproc->rproc = rproc;
core->rproc = rproc;
+ ret = k3_r5_rproc_request_mbox(rproc);
+ if (ret)
+ return ret;
+
ret = k3_r5_rproc_configure_mode(kproc);
if (ret < 0)
goto err_config;
@@ -1393,6 +1369,8 @@ static void k3_r5_cluster_rproc_exit(void *data)
}
}
+ mbox_free_channel(kproc->mbox);
+
rproc_del(rproc);
k3_r5_reserved_mem_exit(kproc);
Re: [PATCH 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe
and
- * will be left in booted state in IPC-only mode. This callback is invoked
- * only in IPC-only mode.
+ * The R5F detach callback is a NOP. The R5F cores are not stopped and will be
+ * left in booted state in IPC-only mode. This callback is invoked only in
+ * IPC-only mode and exists for sanity sake.
*/
-static int k3_r5_rproc_detach(struct rproc *rproc)
-{
- struct k3_r5_rproc *kproc = rproc->priv;
- struct device *dev = kproc->dev;
-
- mbox_free_channel(kproc->mbox);
- dev_info(dev, "R5F core deinitialized in IPC-only mode\n");
- return 0;
-}
+static int k3_r5_rproc_detach(struct rproc *rproc) { return 0; }
Do we still need to disable the mbox channel somehow here to prevent
receiving more messages from the detached core?
/*
* This function implements the .get_loaded_rsc_table() callback and is used
@@ -1277,6 +1249,10 @@ static int k3_r5_cluster_rproc_init(struct
platform_device *pdev)
kproc->rproc = rproc;
core->rproc = rproc;
+ ret = k3_r5_rproc_request_mbox(rproc);
Now that we get the channel here in init you'll want to add a matching
mbox_free_channel() call to k3_r5_cluster_rproc_exit().
Andrew
+ if (ret)
+ return ret;
+
ret = k3_r5_rproc_configure_mode(kproc);
if (ret < 0)
goto err_config;
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/9/24 10:32 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+tristate "TI K3 M4 remoteproc support"
+depends on ARCH_K3 || COMPILE_TEST
+select MAILBOX
+select OMAP2PLUS_MBOX
+help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+void __iomem *cpu_addr;
+phys_addr_t bus_addr;
+u32 dev_addr;
+size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+const char *name;
+const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+const struct k3_m4_rproc_mem_data *mems;
+u32 num_mems;
+bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver st
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/9/24 10:22 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+tristate "TI K3 M4 remoteproc support"
+depends on ARCH_K3 || COMPILE_TEST
+select MAILBOX
+select OMAP2PLUS_MBOX
+help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+void __iomem *cpu_addr;
+phys_addr_t bus_addr;
+u32 dev_addr;
+size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+const char *name;
+const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ *
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+ bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: c
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ co
[PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+ bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handle
+ * @mem: internal memory regions data
+ * @num_mems: num
[PATCH v9 0/5] TI K3 M4F support on AM62 SoCs
Hello all, This is the continuation of the M4F RProc support series from here[0]. I'm helping out with the upstream task for Hari and so this version(v8) is a little different than the previous(v7) postings[0]. Most notable change I've introduced being the patches factoring out common support from the current K3 R5 and DSP drivers have been dropped. I'd like to do that re-factor *after* getting this driver in shape, that way we have 3 similar drivers to factor out from vs trying to make those changes in parallel with the series adding M4 support. Anyway, details on our M4F subsystem can be found the the AM62 TRM in the section on the same: AM62x Technical Reference Manual (SPRUIV7A – MAY 2022) https://www.ti.com/lit/pdf/SPRUIV7A Thanks, Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/ Changes for v9: - Fixed reserved-memory.yaml text in [1/5] - Split dts patch into one for SoC and one for board enable - Corrected DT property order and formatting [4/5][5/5] Hari Nagalla (4): dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs arm64: dts: ti: k3-am62: Add M4F remoteproc node arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node arm64: defconfig: Enable TI K3 M4 remoteproc driver Martyn Welch (1): remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 +++ arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 + .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 + arch/arm64/configs/defconfig | 1 + drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 ++ 7 files changed, 957 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c -- 2.39.2
[PATCH v9 3/5] arm64: dts: ti: k3-am62: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..7f6f0007e8e81 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,17 @@ mcu_mcan1: can@4e18000 {
bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
status = "disabled";
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ resets = <_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ status = "disabled";
+ };
};
--
2.39.2
[PATCH v9 5/5] arm64: defconfig: Enable TI K3 M4 remoteproc driver
From: Hari Nagalla Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e1802..04e8e2ca4aa10 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1352,6 +1352,7 @@ CONFIG_QCOM_Q6V5_PAS=m CONFIG_QCOM_SYSMON=m CONFIG_QCOM_WCNSS_PIL=m CONFIG_TI_K3_DSP_REMOTEPROC=m +CONFIG_TI_K3_M4_REMOTEPROC=m CONFIG_TI_K3_R5_REMOTEPROC=m CONFIG_RPMSG_CHAR=m CONFIG_RPMSG_CTRL=m -- 2.39.2
[PATCH v9 1/5] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 125 ++
1 file changed, 125 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0..2bd0752b6ba9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,125 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla
+ - Mathieu Poirier
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - ti,am64-m4fss
+
+ power-domains:
+maxItems: 1
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+items:
+ - const: iram
+ - const: dram
+
+ resets:
+maxItems: 1
+
+ firmware-name:
+maxItems: 1
+description: Name of firmware to load for the M4F core
+
+ mboxes:
+description:
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+maxItems: 1
+
+ memory-region:
+description:
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. Optional memory regions available for firmware
+ specific purposes.
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
+maxItems: 8
+items:
+ - description: regions used for DMA allocations like vrings, vring
buffers
+ and memory dedicated to firmware's specific purposes.
+additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cb0 0x00 0x10>;
+no-map;
+};
+
+mcu_m4fss_memory_region: m4f-memory@9cc0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cc0 0x00 0xe0>;
+no-map;
+};
+};
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mailbox0_cluster0: mailbox-0 {
+#mbox-cells = <1>;
+};
+
+remoteproc@500 {
+compatible = "ti,am64-m4fss";
+reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+reg-names = "iram", "dram";
+resets = <_reset 9 1>;
+firmware-name = "am62-mcu-m4f0_0-fw";
+mboxes = <_cluster0>, <_m4_0>;
+memory-region = <_m4fss_dma_memory_region>,
+<_m4fss_memory_region>;
+ti,sci = <>;
+ti,sci-dev-id = <9>;
+ti,sci-proc-ids = <0x18 0xff>;
+ };
+};
--
2.39.2
[PATCH v9 4/5] arm64: dts: ti: k3-am625-sk: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor does not have an MMU, and as such
requires the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 3c45782ab2b78..167bec5c80006 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -48,6 +48,18 @@ ramoops@9ca0 {
pmsg-size = <0x8000>;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb0 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc0 0x00 0xe0>;
+ no-map;
+ };
+
secure_tfa_ddr: tfa@9e78 {
reg = <0x00 0x9e78 0x00 0x8>;
alignment = <0x1000>;
@@ -457,6 +469,13 @@ mbox_m4_0: mbox-m4-0 {
};
};
+_m4fss {
+ mboxes = <_cluster0 _m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+ status = "okay";
+};
+
{
bootph-all;
status = "okay";
--
2.39.2
Re: [PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
On 4/25/24 12:15 PM, Conor Dooley wrote: On Wed, Apr 24, 2024 at 03:36:39PM -0500, Rob Herring wrote: On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote: From: Hari Nagalla K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain. The remote processor's life cycle management and IPC mechanisms are similar across the R5F and M4F cores from remote processor driver point of view. However, there are subtle differences in image loading and starting the M4F subsystems. The YAML binding document provides the various node properties to be configured by the consumers of the M4F subsystem. Signed-off-by: Martyn Welch Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): Warning: Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml The file is now in dt-schema: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml So should I use "reserved-memory/reserved-memory.yaml" here, or just drop this line completely? Andrew
[PATCH v8 2/4] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+ bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handle
+ * @mem: internal memory regions data
+ * @num_mems: num
[PATCH v8 4/4] arm64: dts: ti: k3-am62: Add M4F remoteproc node
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is used
as a DMA pool for the rproc device, and the second region will furnish
the static carveout regions for the firmware memory.
The current carveout addresses and sizes are defined statically for
each rproc device. The M4F processor do not have an MMU, and as such
require the exact memory used by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi| 12
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 18 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
index e66d486ef1f21..0c6ee801f35fc 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
@@ -173,4 +173,16 @@ mcu_mcan1: can@4e18000 {
bosch,mram-cfg = <0x0 128 64 64 64 64 32 32>;
status = "disabled";
};
+
+ mcu_m4fss: m4fss@500 {
+ compatible = "ti,am64-m4fss";
+ reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+ reg-names = "iram", "dram";
+ ti,sci = <>;
+ ti,sci-dev-id = <9>;
+ ti,sci-proc-ids = <0x18 0xff>;
+ resets = <_reset 9 1>;
+ firmware-name = "am62-mcu-m4f0_0-fw";
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
index 3c45782ab2b78..bda9fb2e33eec 100644
--- a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
@@ -48,6 +48,18 @@ ramoops@9ca0 {
pmsg-size = <0x8000>;
};
+ mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cb0 0x00 0x10>;
+ no-map;
+ };
+
+ mcu_m4fss_memory_region: m4f-memory@9cc0 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0x9cc0 0x00 0xe0>;
+ no-map;
+ };
+
secure_tfa_ddr: tfa@9e78 {
reg = <0x00 0x9e78 0x00 0x8>;
alignment = <0x1000>;
@@ -457,6 +469,12 @@ mbox_m4_0: mbox-m4-0 {
};
};
+_m4fss {
+ mboxes = <_cluster0>, <_m4_0>;
+ memory-region = <_m4fss_dma_memory_region>,
+ <_m4fss_memory_region>;
+};
+
{
bootph-all;
status = "okay";
--
2.39.2
[PATCH v8 0/4] TI K3 M4F support on AM62 SoCs
Hello all, This is the continuation of the M4F RProc support series from here[0]. I'm helping out with the upstream task for Hari and so this version(v8) is a little different than the previous(v7) postings[0]. Most notable change I've introduced being the patches factoring out common support from the current K3 R5 and DSP drivers have been dropped. I'd like to do that re-factor *after* getting this driver in shape, that way we have 3 similar drivers to factor out from vs trying to make those changes in parallel with the series adding M4 support. Anyway, details on our M4F subsystem can be found the the AM62 TRM in the section on the same: AM62x Technical Reference Manual (SPRUIV7A – MAY 2022) https://www.ti.com/lit/pdf/SPRUIV7A Thanks, Andrew [0] https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/ Hari Nagalla (3): dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs arm64: defconfig: Enable TI K3 M4 remoteproc driver arm64: dts: ti: k3-am62: Add M4F remoteproc node Martyn Welch (1): remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem .../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 +++ arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 12 + .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 18 + arch/arm64/configs/defconfig | 1 + drivers/remoteproc/Kconfig| 13 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 ++ 7 files changed, 956 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c -- 2.39.2
[PATCH v8 3/4] arm64: defconfig: Enable TI K3 M4 remoteproc driver
From: Hari Nagalla Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla Signed-off-by: Andrew Davis --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e1802..04e8e2ca4aa10 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1352,6 +1352,7 @@ CONFIG_QCOM_Q6V5_PAS=m CONFIG_QCOM_SYSMON=m CONFIG_QCOM_WCNSS_PIL=m CONFIG_TI_K3_DSP_REMOTEPROC=m +CONFIG_TI_K3_M4_REMOTEPROC=m CONFIG_TI_K3_R5_REMOTEPROC=m CONFIG_RPMSG_CHAR=m CONFIG_RPMSG_CTRL=m -- 2.39.2
[PATCH v8 1/4] dt-bindings: remoteproc: k3-m4f: Add K3 AM64x SoCs
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126 ++
1 file changed, 126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
new file mode 100644
index 0..3629ddd6efa8c
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-m4f-rproc.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-m4f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 M4F processor subsystems
+
+maintainers:
+ - Hari Nagalla
+ - Mathieu Poirier
+
+description: |
+ Some K3 family SoCs have Arm Cortex M4F cores. AM64x is a SoC in K3
+ family with a M4F core. Typically safety oriented applications may use
+ the M4F core in isolation without an IPC. Where as some industrial and
+ home automation applications, may use the M4F core as a remote processor
+ with IPC communications.
+
+$ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - ti,am64-m4fss
+
+ power-domains:
+maxItems: 1
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+items:
+ - description: IRAM internal memory region
+ - description: DRAM internal memory region
+
+ reg-names:
+items:
+ - const: iram
+ - const: dram
+
+ resets:
+maxItems: 1
+
+ firmware-name:
+maxItems: 1
+description: Name of firmware to load for the M4F core
+
+ mboxes:
+description: |
+ OMAP Mailbox specifier denoting the sub-mailbox, to be used for
+ communication with the remote processor. This property should match
+ with the sub-mailbox node used in the firmware image.
+maxItems: 1
+
+ memory-region:
+description: |
+ phandle to the reserved memory nodes to be associated with the
+ remoteproc device. The reserved memory nodes should be carveout nodes,
+ and should be defined with a "no-map" property as per the bindings in
+ Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
+ Optional memory regions available for firmware specific purposes.
+maxItems: 8
+items:
+ - description: regions used for DMA allocations like vrings, vring
buffers
+ and memory dedicated to firmware's specific purposes.
+additionalItems: true
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-proc-ids
+ - resets
+ - firmware-name
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mcu_m4fss_dma_memory_region: m4f-dma-memory@9cb0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cb0 0x00 0x10>;
+no-map;
+};
+
+mcu_m4fss_memory_region: m4f-memory@9cc0 {
+compatible = "shared-dma-pool";
+reg = <0x00 0x9cc0 0x00 0xe0>;
+no-map;
+};
+};
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+mailbox0_cluster0: mailbox-0 {
+#mbox-cells = <1>;
+};
+
+remoteproc@500 {
+compatible = "ti,am64-m4fss";
+reg = <0x00 0x500 0x00 0x3>,
+ <0x00 0x504 0x00 0x1>;
+reg-names = "iram", "dram";
+ti,sci = <>;
+ti,sci-dev-id = <9>;
+ti,sci-proc-ids = <0x18 0xff>;
+resets = <_reset 9 1>;
+firmware-name = "am62-mcu-m4f0_0-fw";
+mboxes = <_cluster0>, <_m4_0>;
+memory-region = <_m4fss_dma_memory_region>,
+<_m4fss_memory_region>;
+ };
+};
--
2.39.2
Re: [PATCH 2/3] kernel/pid: Remove default pid_max value
On Thu, 11 Apr 2024 17:40:02 +0200 Michal Koutný wrote: > Hello. > > On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton > wrote: > > That seems like a large change. > > In what sense is it large? A large increase in the maximum number of processes. Or did I misinterpret?
Re: [PATCH 0/4] KVM, mm: remove the .change_pte() MMU notifier and set_pte_at_notify()
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote: > Please review! Also feel free to take the KVM patches through the mm > tree, as I don't expect any conflicts. It's mainly a KVM thing and the MM changes are small and simple. I'd say that the KVM tree would be a better home?
[PATCH v2 09/13] mailbox: omap: Use function local struct mbox_controller
The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 17c9b9df78b1d..97f59d9f9f319 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -86,7 +86,6 @@ struct omap_mbox_device {
u32 num_fifos;
u32 intr_type;
struct omap_mbox **mboxes;
- struct mbox_controller controller;
};
struct omap_mbox {
@@ -541,7 +540,7 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
struct omap_mbox_device *mdev;
struct omap_mbox *mbox;
- mdev = container_of(controller, struct omap_mbox_device, controller);
+ mdev = dev_get_drvdata(controller->dev);
if (WARN_ON(!mdev))
return ERR_PTR(-EINVAL);
@@ -567,6 +566,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct device_node *child;
const struct omap_mbox_match_data *match_data;
+ struct mbox_controller *controller;
u32 intr_type, info_count;
u32 num_users, num_fifos;
u32 tmp[3];
@@ -685,17 +685,20 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->intr_type = intr_type;
mdev->mboxes = list;
+ controller = devm_kzalloc(>dev, sizeof(*controller), GFP_KERNEL);
+ if (!controller)
+ return -ENOMEM;
/*
* OMAP/K3 Mailbox IP does not have a Tx-Done IRQ, but rather a Tx-Ready
* IRQ and is needed to run the Tx state machine
*/
- mdev->controller.txdone_irq = true;
- mdev->controller.dev = mdev->dev;
- mdev->controller.ops = _mbox_chan_ops;
- mdev->controller.chans = chnls;
- mdev->controller.num_chans = info_count;
- mdev->controller.of_xlate = omap_mbox_of_xlate;
- ret = devm_mbox_controller_register(mdev->dev, >controller);
+ controller->txdone_irq = true;
+ controller->dev = mdev->dev;
+ controller->ops = _mbox_chan_ops;
+ controller->chans = chnls;
+ controller->num_chans = info_count;
+ controller->of_xlate = omap_mbox_of_xlate;
+ ret = devm_mbox_controller_register(mdev->dev, controller);
if (ret)
return ret;
--
2.39.2
[PATCH v2 11/13] mailbox: omap: Remove mbox_chan_to_omap_mbox()
This function only checks if mbox_chan *chan is not NULL, but that cannot
be the case and if it was returning NULL which is not later checked
doesn't save us from this. The second check for chan->con_priv is
completely redundant as if it was NULL we would return NULL just the
same. Simply dereference con_priv directly and remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e42266cb31a5..8e2760d2c5b0c 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -103,14 +103,6 @@ static unsigned int mbox_kfifo_size =
CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
-{
- if (!chan || !chan->con_priv)
- return NULL;
-
- return (struct omap_mbox *)chan->con_priv;
-}
-
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -357,7 +349,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
static int omap_mbox_chan_startup(struct mbox_chan *chan)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
struct omap_mbox_device *mdev = mbox->parent;
int ret = 0;
@@ -372,7 +364,7 @@ static int omap_mbox_chan_startup(struct mbox_chan *chan)
static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
struct omap_mbox_device *mdev = mbox->parent;
mutex_lock(>cfg_lock);
@@ -415,7 +407,7 @@ static int omap_mbox_chan_send(struct omap_mbox *mbox, u32
msg)
static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
int ret;
u32 msg = (u32)(uintptr_t)(data);
--
2.39.2
[PATCH v2 05/13] mailbox: omap: Remove unneeded header omap-mailbox.h
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). This type should have been defined as
u32. Instead of making that change here, simply remove the header usage
and fix the last couple users of the same in this driver.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 167348fb1b33b..4c673cb732ed1 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -239,16 +238,14 @@ static void mbox_rx_work(struct work_struct *work)
{
struct omap_mbox_queue *mq =
container_of(work, struct omap_mbox_queue, work);
- mbox_msg_t data;
u32 msg;
int len;
while (kfifo_len(>fifo) >= sizeof(msg)) {
len = kfifo_out(>fifo, (unsigned char *), sizeof(msg));
WARN_ON(len != sizeof(msg));
- data = msg;
- mbox_chan_received_data(mq->mbox->chan, (void *)data);
+ mbox_chan_received_data(mq->mbox->chan, (void *)(uintptr_t)msg);
spin_lock_irq(>lock);
if (mq->full) {
mq->full = false;
@@ -515,7 +512,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan,
void *data)
{
struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
int ret;
- u32 msg = omap_mbox_message(data);
+ u32 msg = (u32)(uintptr_t)(data);
if (!mbox)
return -EINVAL;
--
2.39.2
[PATCH v2 13/13] mailbox: omap: Remove kernel FIFO message queuing
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea itself looks to be a leftover from before the
unified mailbox framework. The current mailbox framework expects
mbox_chan_received_data() to be called with data immediately as it
arrives. Remove the FIFO and pass the messages to the mailbox
framework directly as part of a threaded IRQ handler.
Signed-off-by: Andrew Davis
---
drivers/mailbox/Kconfig| 9 ---
drivers/mailbox/omap-mailbox.c | 107 ++---
2 files changed, 5 insertions(+), 111 deletions(-)
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 42940108a1874..78e4c74fbe5c2 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -68,15 +68,6 @@ config OMAP2PLUS_MBOX
OMAP2/3; or IPU, IVA HD and DSP in OMAP4/5. Say Y here if you
want to use OMAP2+ Mailbox framework support.
-config OMAP_MBOX_KFIFO_SIZE
- int "Mailbox kfifo default buffer size (bytes)"
- depends on OMAP2PLUS_MBOX
- default 256
- help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
config ROCKCHIP_MBOX
bool "Rockchip Soc Integrated Mailbox Support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c5d4083125856..46747559b438f 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -65,14 +65,6 @@ struct omap_mbox_fifo {
u32 intr_bit;
};
-struct omap_mbox_queue {
- spinlock_t lock;
- struct kfifofifo;
- struct work_struct work;
- struct omap_mbox*mbox;
- bool full;
-};
-
struct omap_mbox_match_data {
u32 intr_type;
};
@@ -90,7 +82,6 @@ struct omap_mbox_device {
struct omap_mbox {
const char *name;
int irq;
- struct omap_mbox_queue *rxq;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
@@ -99,10 +90,6 @@ struct omap_mbox {
boolsend_no_irq;
};
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -202,30 +189,6 @@ static void omap_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-/*
- * Message receiver(workqueue)
- */
-static void mbox_rx_work(struct work_struct *work)
-{
- struct omap_mbox_queue *mq =
- container_of(work, struct omap_mbox_queue, work);
- u32 msg;
- int len;
-
- while (kfifo_len(>fifo) >= sizeof(msg)) {
- len = kfifo_out(>fifo, (unsigned char *), sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- mbox_chan_received_data(mq->mbox->chan, (void *)(uintptr_t)msg);
- spin_lock_irq(>lock);
- if (mq->full) {
- mq->full = false;
- omap_mbox_enable_irq(mq->mbox, IRQ_RX);
- }
- spin_unlock_irq(>lock);
- }
-}
-
/*
* Mailbox interrupt handler
*/
@@ -238,27 +201,15 @@ static void __mbox_tx_interrupt(struct omap_mbox *mbox)
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
{
- struct omap_mbox_queue *mq = mbox->rxq;
u32 msg;
- int len;
while (!mbox_fifo_empty(mbox)) {
- if (unlikely(kfifo_avail(>fifo) < sizeof(msg))) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
- mq->full = true;
- goto nomem;
- }
-
msg = mbox_fifo_read(mbox);
-
- len = kfifo_in(>fifo, (unsigned char *), sizeof(msg));
- WARN_ON(len != sizeof(msg));
+ mbox_chan_received_data(mbox->chan, (void *)(uintptr_t)msg);
}
- /* no more messages in the fifo. clear IRQ source. */
+ /* clear IRQ source. */
ack_mbox_irq(mbox, IRQ_RX);
-nomem:
- schedule_work(>rxq->work);
}
static irqreturn_t mbox_interrupt(int irq, void *p)
@@ -274,57 +225,15 @@ static irqreturn_t mbox_interrupt(int irq, void *p)
return IRQ_HANDLED;
}
-static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
- void (*work)(struct work_struct *))
-{
- struct omap_mbox_queue *mq;
-
[PATCH v2 10/13] mailbox: omap: Use mbox_controller channel list directly
The driver stores a list of omap_mbox structs so it can later use it to
lookup the mailbox names in of_xlate. This same information is already
available in the mbox_controller passed into of_xlate. Simply use that
data and remove the extra allocation and storage of the omap_mbox list.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 +-
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 97f59d9f9f319..8e42266cb31a5 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -85,7 +85,6 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
u32 intr_type;
- struct omap_mbox **mboxes;
};
struct omap_mbox {
@@ -356,25 +355,6 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox->rxq);
}
-static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
- const char *mbox_name)
-{
- struct omap_mbox *_mbox, *mbox = NULL;
- struct omap_mbox **mboxes = mdev->mboxes;
- int i;
-
- if (!mboxes)
- return NULL;
-
- for (i = 0; (_mbox = mboxes[i]); i++) {
- if (!strcmp(_mbox->name, mbox_name)) {
- mbox = _mbox;
- break;
- }
- }
- return mbox;
-}
-
static int omap_mbox_chan_startup(struct mbox_chan *chan)
{
struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
@@ -539,6 +519,7 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
struct device_node *node;
struct omap_mbox_device *mdev;
struct omap_mbox *mbox;
+ int i;
mdev = dev_get_drvdata(controller->dev);
if (WARN_ON(!mdev))
@@ -551,16 +532,23 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
return ERR_PTR(-ENODEV);
}
- mbox = omap_mbox_device_find(mdev, node->name);
+ for (i = 0; i < controller->num_chans; i++) {
+ mbox = controller->chans[i].con_priv;
+ if (!strcmp(mbox->name, node->name)) {
+ of_node_put(node);
+ return >chans[i];
+ }
+ }
+
of_node_put(node);
- return mbox ? mbox->chan : ERR_PTR(-ENOENT);
+ return ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
{
int ret;
struct mbox_chan *chnls;
- struct omap_mbox **list, *mbox;
+ struct omap_mbox *mbox;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
struct device_node *node = pdev->dev.of_node;
@@ -608,12 +596,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!mdev->irq_ctx)
return -ENOMEM;
- /* allocate one extra for marking end of list */
- list = devm_kcalloc(>dev, info_count + 1, sizeof(*list),
- GFP_KERNEL);
- if (!list)
- return -ENOMEM;
-
chnls = devm_kcalloc(>dev, info_count + 1, sizeof(*chnls),
GFP_KERNEL);
if (!chnls)
@@ -675,7 +657,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
return mbox->irq;
mbox->chan = [i];
chnls[i].con_priv = mbox;
- list[i] = mbox++;
}
mutex_init(>cfg_lock);
@@ -683,7 +664,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->num_users = num_users;
mdev->num_fifos = num_fifos;
mdev->intr_type = intr_type;
- mdev->mboxes = list;
controller = devm_kzalloc(>dev, sizeof(*controller), GFP_KERNEL);
if (!controller)
--
2.39.2
[PATCH v2 03/13] mailbox: omap: Move omap_mbox_irq_t into driver
This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 5 +
include/linux/omap-mailbox.h | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8151722eef383..c083734b6954c 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -51,6 +51,11 @@
#define MBOX_INTR_CFG_TYPE10
#define MBOX_INTR_CFG_TYPE21
+typedef enum {
+ IRQ_TX = 1,
+ IRQ_RX = 2,
+} omap_mbox_irq_t;
+
struct omap_mbox_fifo {
unsigned long msg;
unsigned long fifo_stat;
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index f8ddf8e814167..3cc5c4ed7f5a6 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -10,8 +10,4 @@ typedef uintptr_t mbox_msg_t;
#define omap_mbox_message(data) (u32)(mbox_msg_t)(data)
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
#endif /* OMAP_MAILBOX_H */
--
2.39.2
[PATCH v2 12/13] mailbox: omap: Reverse FIFO busy check logic
It is much more clear to check if the hardware FIFO is full and return
EBUSY if true. This allows us to also remove one level of indention
from the core of this function. It also makes the similarities between
omap_mbox_chan_send_noirq() and omap_mbox_chan_send() more obvious.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e2760d2c5b0c..c5d4083125856 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -375,34 +375,33 @@ static void omap_mbox_chan_shutdown(struct mbox_chan
*chan)
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_RX);
- mbox_fifo_write(mbox, msg);
- ret = 0;
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
+ mbox_fifo_write(mbox, msg);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
- /* we must read and ack the interrupt directly from here */
- mbox_fifo_read(mbox);
- ack_mbox_irq(mbox, IRQ_RX);
- }
+ /* we must read and ack the interrupt directly from here */
+ mbox_fifo_read(mbox);
+ ack_mbox_irq(mbox, IRQ_RX);
- return ret;
+ return 0;
}
static int omap_mbox_chan_send(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
-
- if (!mbox_fifo_full(mbox)) {
- mbox_fifo_write(mbox, msg);
- ret = 0;
+ if (mbox_fifo_full(mbox)) {
+ /* always enable the interrupt */
+ omap_mbox_enable_irq(mbox, IRQ_TX);
+ return -EBUSY;
}
+ mbox_fifo_write(mbox, msg);
+
/* always enable the interrupt */
omap_mbox_enable_irq(mbox, IRQ_TX);
- return ret;
+ return 0;
}
static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
--
2.39.2
[PATCH v2 08/13] mailbox: omap: Merge mailbox child node setup loops
Currently the driver loops through all mailbox child nodes twice, once
to read in data from each node, and again to make use of this data.
Instead read the data and make use of it in one pass. This removes
the need for several temporary data structures and reduces the
complexity of this main loop in probe.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 119 +
1 file changed, 46 insertions(+), 73 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 4f956c7b4072c..17c9b9df78b1d 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -89,19 +89,6 @@ struct omap_mbox_device {
struct mbox_controller controller;
};
-struct omap_mbox_fifo_info {
- int tx_id;
- int tx_usr;
- int tx_irq;
-
- int rx_id;
- int rx_usr;
- int rx_irq;
-
- const char *name;
- bool send_no_irq;
-};
-
struct omap_mbox {
const char *name;
int irq;
@@ -574,8 +561,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
{
int ret;
struct mbox_chan *chnls;
- struct omap_mbox **list, *mbox, *mboxblk;
- struct omap_mbox_fifo_info *finfo, *finfoblk;
+ struct omap_mbox **list, *mbox;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
struct device_node *node = pdev->dev.of_node;
@@ -609,40 +595,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
return -ENODEV;
}
- finfoblk = devm_kcalloc(>dev, info_count, sizeof(*finfoblk),
- GFP_KERNEL);
- if (!finfoblk)
- return -ENOMEM;
-
- finfo = finfoblk;
- child = NULL;
- for (i = 0; i < info_count; i++, finfo++) {
- child = of_get_next_available_child(node, child);
- ret = of_property_read_u32_array(child, "ti,mbox-tx", tmp,
-ARRAY_SIZE(tmp));
- if (ret)
- return ret;
- finfo->tx_id = tmp[0];
- finfo->tx_irq = tmp[1];
- finfo->tx_usr = tmp[2];
-
- ret = of_property_read_u32_array(child, "ti,mbox-rx", tmp,
-ARRAY_SIZE(tmp));
- if (ret)
- return ret;
- finfo->rx_id = tmp[0];
- finfo->rx_irq = tmp[1];
- finfo->rx_usr = tmp[2];
-
- finfo->name = child->name;
-
- finfo->send_no_irq = of_property_read_bool(child,
"ti,mbox-send-noirq");
-
- if (finfo->tx_id >= num_fifos || finfo->rx_id >= num_fifos ||
- finfo->tx_usr >= num_users || finfo->rx_usr >= num_users)
- return -EINVAL;
- }
-
mdev = devm_kzalloc(>dev, sizeof(*mdev), GFP_KERNEL);
if (!mdev)
return -ENOMEM;
@@ -667,36 +619,58 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!chnls)
return -ENOMEM;
- mboxblk = devm_kcalloc(>dev, info_count, sizeof(*mbox),
- GFP_KERNEL);
- if (!mboxblk)
- return -ENOMEM;
+ child = NULL;
+ for (i = 0; i < info_count; i++) {
+ int tx_id, tx_irq, tx_usr;
+ int rx_id, rx_usr;
+
+ mbox = devm_kzalloc(>dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ child = of_get_next_available_child(node, child);
+ ret = of_property_read_u32_array(child, "ti,mbox-tx", tmp,
+ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ tx_id = tmp[0];
+ tx_irq = tmp[1];
+ tx_usr = tmp[2];
+
+ ret = of_property_read_u32_array(child, "ti,mbox-rx", tmp,
+ARRAY_SIZE(tmp));
+ if (ret)
+ return ret;
+ rx_id = tmp[0];
+ /* rx_irq = tmp[1]; */
+ rx_usr = tmp[2];
+
+ if (tx_id >= num_fifos || rx_id >= num_fifos ||
+ tx_usr >= num_users || rx_usr >= num_users)
+ return -EINVAL;
- mbox = mboxblk;
- finfo = finfoblk;
- for (i = 0; i < info_count; i++, finfo++) {
fifo = >tx_fifo;
- fifo->msg = MAILBOX_MESSAGE(finfo->tx_id);
- fifo->fifo_stat = MAILBOX_FIFOSTATUS(finfo->tx_id);
- fifo->intr_bit = MAILBOX_IRQ_NOTFULL(finfo->tx_id);
- fifo->irqenab
[PATCH v2 07/13] mailbox: omap: Use devm_pm_runtime_enable() helper
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index ea467931faf46..4f956c7b4072c 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -726,11 +726,11 @@ static int omap_mbox_probe(struct platform_device *pdev)
return ret;
platform_set_drvdata(pdev, mdev);
- pm_runtime_enable(mdev->dev);
+ devm_pm_runtime_enable(mdev->dev);
ret = pm_runtime_resume_and_get(mdev->dev);
if (ret < 0)
- goto unregister;
+ return ret;
/*
* just print the raw revision register, the format is not
@@ -741,26 +741,14 @@ static int omap_mbox_probe(struct platform_device *pdev)
ret = pm_runtime_put_sync(mdev->dev);
if (ret < 0 && ret != -ENOSYS)
- goto unregister;
+ return ret;
devm_kfree(>dev, finfoblk);
return 0;
-
-unregister:
- pm_runtime_disable(mdev->dev);
- return ret;
-}
-
-static void omap_mbox_remove(struct platform_device *pdev)
-{
- struct omap_mbox_device *mdev = platform_get_drvdata(pdev);
-
- pm_runtime_disable(mdev->dev);
}
static struct platform_driver omap_mbox_driver = {
.probe = omap_mbox_probe,
- .remove_new = omap_mbox_remove,
.driver = {
.name = "omap-mailbox",
.pm = _mbox_pm_ops,
--
2.39.2
[PATCH v2 06/13] mailbox: omap: Remove device class
The driver currently creates a new device class "mbox". Then for each
mailbox adds a device to that class. This class provides no file
operations provided for any userspace users of this device class.
It may have been extended to be functional in our vendor tree at
some point, but that is not the case anymore, nor does it matter
for the upstream tree.
Remove this device class and related functions and variables.
This also allows us to switch to module_platform_driver() as
there is nothing left to do in module_init().
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 89 +-
1 file changed, 2 insertions(+), 87 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 4c673cb732ed1..ea467931faf46 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -87,7 +87,6 @@ struct omap_mbox_device {
u32 intr_type;
struct omap_mbox **mboxes;
struct mbox_controller controller;
- struct list_head elem;
};
struct omap_mbox_fifo_info {
@@ -107,7 +106,6 @@ struct omap_mbox {
const char *name;
int irq;
struct omap_mbox_queue *rxq;
- struct device *dev;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
@@ -116,10 +114,6 @@ struct omap_mbox {
boolsend_no_irq;
};
-/* global variables for the mailbox devices */
-static DEFINE_MUTEX(omap_mbox_devices_lock);
-static LIST_HEAD(omap_mbox_devices);
-
static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
@@ -395,61 +389,6 @@ static struct omap_mbox *omap_mbox_device_find(struct
omap_mbox_device *mdev,
return mbox;
}
-static struct class omap_mbox_class = { .name = "mbox", };
-
-static int omap_mbox_register(struct omap_mbox_device *mdev)
-{
- int ret;
- int i;
- struct omap_mbox **mboxes;
-
- if (!mdev || !mdev->mboxes)
- return -EINVAL;
-
- mboxes = mdev->mboxes;
- for (i = 0; mboxes[i]; i++) {
- struct omap_mbox *mbox = mboxes[i];
-
- mbox->dev = device_create(_mbox_class, mdev->dev,
- 0, mbox, "%s", mbox->name);
- if (IS_ERR(mbox->dev)) {
- ret = PTR_ERR(mbox->dev);
- goto err_out;
- }
- }
-
- mutex_lock(_mbox_devices_lock);
- list_add(>elem, _mbox_devices);
- mutex_unlock(_mbox_devices_lock);
-
- ret = devm_mbox_controller_register(mdev->dev, >controller);
-
-err_out:
- if (ret) {
- while (i--)
- device_unregister(mboxes[i]->dev);
- }
- return ret;
-}
-
-static int omap_mbox_unregister(struct omap_mbox_device *mdev)
-{
- int i;
- struct omap_mbox **mboxes;
-
- if (!mdev || !mdev->mboxes)
- return -EINVAL;
-
- mutex_lock(_mbox_devices_lock);
- list_del(>elem);
- mutex_unlock(_mbox_devices_lock);
-
- mboxes = mdev->mboxes;
- for (i = 0; mboxes[i]; i++)
- device_unregister(mboxes[i]->dev);
- return 0;
-}
-
static int omap_mbox_chan_startup(struct mbox_chan *chan)
{
struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
@@ -782,7 +721,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->controller.chans = chnls;
mdev->controller.num_chans = info_count;
mdev->controller.of_xlate = omap_mbox_of_xlate;
- ret = omap_mbox_register(mdev);
+ ret = devm_mbox_controller_register(mdev->dev, >controller);
if (ret)
return ret;
@@ -809,7 +748,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
unregister:
pm_runtime_disable(mdev->dev);
- omap_mbox_unregister(mdev);
return ret;
}
@@ -818,7 +756,6 @@ static void omap_mbox_remove(struct platform_device *pdev)
struct omap_mbox_device *mdev = platform_get_drvdata(pdev);
pm_runtime_disable(mdev->dev);
- omap_mbox_unregister(mdev);
}
static struct platform_driver omap_mbox_driver = {
@@ -830,29 +767,7 @@ static struct platform_driver omap_mbox_driver = {
.of_match_table = of_match_ptr(omap_mailbox_of_match),
},
};
-
-static int __init omap_mbox_init(void)
-{
- int err;
-
- err = class_register(_mbox_class);
- if (err)
- return err;
-
- err = platform_driver_register(_mbox_driver);
- if (err)
- class_unregister(_mbox_class);
-
- return err;
-}
-subsys_initcall(omap_mbox_init);
-
-static void
[PATCH v2 04/13] mailbox: omap: Move fifo size check to point of use
The mbox_kfifo_size can be changed at runtime, the sanity
check on it's value should be done when it is used, not
only once at init time.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c083734b6954c..167348fb1b33b 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -310,6 +310,7 @@ static struct omap_mbox_queue *mbox_queue_alloc(struct
omap_mbox *mbox,
void (*work)(struct work_struct *))
{
struct omap_mbox_queue *mq;
+ unsigned int size;
if (!work)
return NULL;
@@ -320,7 +321,10 @@ static struct omap_mbox_queue *mbox_queue_alloc(struct
omap_mbox *mbox,
spin_lock_init(>lock);
- if (kfifo_alloc(>fifo, mbox_kfifo_size, GFP_KERNEL))
+ /* kfifo size sanity check: alignment and minimal size */
+ size = ALIGN(mbox_kfifo_size, sizeof(u32));
+ size = max_t(unsigned int, size, sizeof(u32));
+ if (kfifo_alloc(>fifo, size, GFP_KERNEL))
goto error;
INIT_WORK(>work, work);
@@ -838,10 +842,6 @@ static int __init omap_mbox_init(void)
if (err)
return err;
- /* kfifo size sanity check: alignment and minimal size */
- mbox_kfifo_size = ALIGN(mbox_kfifo_size, sizeof(u32));
- mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(u32));
-
err = platform_driver_register(_mbox_driver);
if (err)
class_unregister(_mbox_class);
--
2.39.2
[PATCH v2 01/13] mailbox: omap: Remove unused omap_mbox_{enable,disable}_irq() functions
These function are not used, remove these here.
While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 --
include/linux/omap-mailbox.h | 3 ---
2 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c961706fe61d5..624a7ccc27285 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -197,7 +197,7 @@ static int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
-static void _omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
u32 l;
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
@@ -210,7 +210,7 @@ static void _omap_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, l, irqenable);
}
-static void _omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
>tx_fifo : >rx_fifo;
@@ -227,28 +227,6 @@ static void _omap_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
-{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
-
- if (WARN_ON(!mbox))
- return;
-
- _omap_mbox_enable_irq(mbox, irq);
-}
-EXPORT_SYMBOL(omap_mbox_enable_irq);
-
-void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
-{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
-
- if (WARN_ON(!mbox))
- return;
-
- _omap_mbox_disable_irq(mbox, irq);
-}
-EXPORT_SYMBOL(omap_mbox_disable_irq);
-
/*
* Message receiver(workqueue)
*/
@@ -269,7 +247,7 @@ static void mbox_rx_work(struct work_struct *work)
spin_lock_irq(>lock);
if (mq->full) {
mq->full = false;
- _omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ omap_mbox_enable_irq(mq->mbox, IRQ_RX);
}
spin_unlock_irq(>lock);
}
@@ -280,7 +258,7 @@ static void mbox_rx_work(struct work_struct *work)
*/
static void __mbox_tx_interrupt(struct omap_mbox *mbox)
{
- _omap_mbox_disable_irq(mbox, IRQ_TX);
+ omap_mbox_disable_irq(mbox, IRQ_TX);
ack_mbox_irq(mbox, IRQ_TX);
mbox_chan_txdone(mbox->chan, 0);
}
@@ -293,7 +271,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(>fifo) < sizeof(msg))) {
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
mq->full = true;
goto nomem;
}
@@ -375,7 +353,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
if (mbox->send_no_irq)
mbox->chan->txdone_method = TXDONE_BY_ACK;
- _omap_mbox_enable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
return 0;
@@ -386,7 +364,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
free_irq(mbox->irq, mbox);
flush_work(>rxq->work);
mbox_queue_free(mbox->rxq);
@@ -533,10 +511,10 @@ static int omap_mbox_chan_send_noirq(struct omap_mbox
*mbox, u32 msg)
int ret = -EBUSY;
if (!mbox_fifo_full(mbox)) {
- _omap_mbox_enable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
mbox_fifo_write(mbox, msg);
ret = 0;
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
/* we must read and ack the interrupt directly from here */
mbox_fifo_read(mbox);
@@ -556,7 +534,7 @@ static int omap_mbox_chan_send(struct omap_mbox *mbox, u32
msg)
}
/* always enable the interrupt */
- _omap_mbox_enable_irq(mbox, IRQ_TX);
+ omap_mbox_enable_irq(mbox, IRQ_TX);
return ret;
}
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index 8aa984ec1f38b..426a80fb32b5c 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -20,7 +20,4 @@ struct mbox_client;
struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
[PATCH v2 00/13] OMAP mailbox FIFO removal
Hello all,
Core of this series is the last patch removing the message FIFO
from OMAP mailbox. This hurts our real-time performance. It was a
legacy leftover from before the common mailbox framework anyway.
The rest of the patches are cleanups found along the way.
Thanks,
Andrew
Changes for v2:
- Use threaded irq as suggested by Hari and to
fix possible "scheduling while atomic" issue
- Use oneshot irq as we do not want to enable the
irq again until we clear our the messages
- Rebase on v6.9-rc3
Andrew Davis (13):
mailbox: omap: Remove unused omap_mbox_{enable,disable}_irq()
functions
mailbox: omap: Remove unused omap_mbox_request_channel() function
mailbox: omap: Move omap_mbox_irq_t into driver
mailbox: omap: Move fifo size check to point of use
mailbox: omap: Remove unneeded header omap-mailbox.h
mailbox: omap: Remove device class
mailbox: omap: Use devm_pm_runtime_enable() helper
mailbox: omap: Merge mailbox child node setup loops
mailbox: omap: Use function local struct mbox_controller
mailbox: omap: Use mbox_controller channel list directly
mailbox: omap: Remove mbox_chan_to_omap_mbox()
mailbox: omap: Reverse FIFO busy check logic
mailbox: omap: Remove kernel FIFO message queuing
drivers/mailbox/Kconfig| 9 -
drivers/mailbox/omap-mailbox.c | 519 +++--
include/linux/omap-mailbox.h | 13 -
3 files changed, 108 insertions(+), 433 deletions(-)
--
2.39.2
[PATCH v2 02/13] mailbox: omap: Remove unused omap_mbox_request_channel() function
This function is not used, remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 36 --
include/linux/omap-mailbox.h | 6 --
2 files changed, 42 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 624a7ccc27285..8151722eef383 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -389,42 +389,6 @@ static struct omap_mbox *omap_mbox_device_find(struct
omap_mbox_device *mdev,
return mbox;
}
-struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
- const char *chan_name)
-{
- struct device *dev = cl->dev;
- struct omap_mbox *mbox = NULL;
- struct omap_mbox_device *mdev;
- int ret;
-
- if (!dev)
- return ERR_PTR(-ENODEV);
-
- if (dev->of_node) {
- pr_err("%s: please use mbox_request_channel(), this API is
supported only for OMAP non-DT usage\n",
- __func__);
- return ERR_PTR(-ENODEV);
- }
-
- mutex_lock(_mbox_devices_lock);
- list_for_each_entry(mdev, _mbox_devices, elem) {
- mbox = omap_mbox_device_find(mdev, chan_name);
- if (mbox)
- break;
- }
- mutex_unlock(_mbox_devices_lock);
-
- if (!mbox || !mbox->chan)
- return ERR_PTR(-ENOENT);
-
- ret = mbox_bind_client(mbox->chan, cl);
- if (ret)
- return ERR_PTR(ret);
-
- return mbox->chan;
-}
-EXPORT_SYMBOL(omap_mbox_request_channel);
-
static struct class omap_mbox_class = { .name = "mbox", };
static int omap_mbox_register(struct omap_mbox_device *mdev)
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index 426a80fb32b5c..f8ddf8e814167 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -14,10 +14,4 @@ typedef int __bitwise omap_mbox_irq_t;
#define IRQ_TX ((__force omap_mbox_irq_t) 1)
#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-struct mbox_chan;
-struct mbox_client;
-
-struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
- const char *chan_name);
-
#endif /* OMAP_MAILBOX_H */
--
2.39.2
Re: [External] Re: [PATCH v11 1/2] memory tier: dax/kmem: introduce an abstract layer for finding, allocating, and putting memory types
On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang" wrote: > Hi Jonathan, > > On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron > wrote: > > > > On Fri, 5 Apr 2024 00:07:05 + > > "Ho-Ren (Jack) Chuang" wrote: > > > > > Since different memory devices require finding, allocating, and putting > > > memory types, these common steps are abstracted in this patch, > > > enhancing the scalability and conciseness of the code. > > > > > > Signed-off-by: Ho-Ren (Jack) Chuang > > > Reviewed-by: "Huang, Ying" > > Reviewed-by: Jonathan Cameron > > > Thank you for reviewing and for adding your "Reviewed-by"! > I was wondering if I need to send a v12 and manually add > this to the commit description, or if this is sufficient. I had added Jonathan's r-b to the mm.git copy of this patch.
Re: [PATCH 2/3] kernel/pid: Remove default pid_max value
On Mon, 8 Apr 2024 16:58:18 +0200 Michal Koutný wrote: > The kernel provides mechanisms, while it should not imply policies -- > default pid_max seems to be an example of the policy that does not fit > all. At the same time pid_max must have some value assigned, so use the > end of the allowed range -- pid_max_max. > > This change thus increases initial pid_max from 32k to 4M (x86_64 > defconfig). That seems like a large change. It isn't clear why we'd want to merge this patchset. Does it improve anyone's life and if so, how?
Re: [PATCH] dax/bus.c: replace WARN_ON_ONCE() with lockdep asserts
On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma wrote: > In [1], Dan points out that all of the WARN_ON_ONCE() usage in the > referenced patch should be replaced with lockdep_assert_held(_write)(). > > Replace those, and additionally, replace a couple of other > WARN_ON_ONCE() introduced in the same patch for actual failure > cases (i.e. when acquiring a semaphore fails in a remove / unregister > path) with dev_WARN_ONCE() as is the precedent here. > > Recall that previously, unregistration paths was implicitly protected by > overloading the device lock, which the patch in [1] sought to remove. > This meant adding a semaphore acquisition in these unregistration paths. > Since that can fail, and it doesn't make sense to return errors from > these paths, retain the two instances of (now) dev_WARN_ONCE(). > > ... > > @@ -471,6 +471,7 @@ static void __unregister_dev_dax(void *dev) > > dev_dbg(dev, "%s\n", __func__); > > + lockdep_assert_held_write(_region_rwsem); > kill_dev_dax(dev_dax); > device_del(dev); > free_dev_dax_ranges(dev_dax); This is new and unchangelogged? I'm taking Dan's reply to your patch as Not-A-Nack ;)
Re: [PATCH 13/13] mailbox: omap: Remove kernel FIFO message queuing
On 4/1/24 6:39 PM, Hari Nagalla wrote: On 3/25/24 12:20, Andrew Davis wrote: The kernel FIFO queue has a couple issues. The biggest issue is that it causes extra latency in a path that can be used in real-time tasks, such as communication with real-time remote processors. The whole FIFO idea itself looks to be a leftover from before the unified mailbox framework. The current mailbox framework expects mbox_chan_received_data() to be called with data immediately as it arrives. Remove the FIFO and pass the messages to the mailbox framework directly. Yes, this would definitely speed up the message receive path. With RT linux, the irq runs in thread context, so that is Ok. But with non-RT the whole receive path runs in interrupt context. So, i think it would be appropriate to use a threaded_irq()? I was thinking the same at first, but seems some mailbox drivers use threaded, others use non-threaded context. Since all we do in the IRQ context anymore is call mbox_chan_received_data(), which is supposed to be IRQ safe, then it should be fine either way. So for now I just kept this using the regular IRQ context as before. If that does turn out to be an issue then let's switch to threaded. Andrew
Re: [PATCH 12/13] mailbox: omap: Reverse FIFO busy check logic
On 4/1/24 6:31 PM, Hari Nagalla wrote:
On 3/25/24 12:20, Andrew Davis wrote:
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_RX);
- mbox_fifo_write(mbox, msg);
- ret = 0;
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
+ mbox_fifo_write(mbox, msg);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
- /* we must read and ack the interrupt directly from here */
- mbox_fifo_read(mbox);
- ack_mbox_irq(mbox, IRQ_RX);
- }
+ /* we must read and ack the interrupt directly from here */
+ mbox_fifo_read(mbox);
+ ack_mbox_irq(mbox, IRQ_RX);
- return ret;
+ return 0;
}
Is n't the interrupt supposed to be IRQ_TX above? i.e TX ready signal?
Hmm, could be, but this patch doesn't actually change anything, only moves code
around for readability. So if we were are ack'ing the wrong interrupt, then it
was wrong before. We should check that and fix it if needed in a follow up
patch.
Andrew
Re: [PATCH 1/3] remoteproc: k3-dsp: Fix usage of omap_mbox_message and mbox_msg_t
On 3/28/24 10:28 AM, Mathieu Poirier wrote:
Hi Andrew,
On Mon, Mar 25, 2024 at 11:58:06AM -0500, Andrew Davis wrote:
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Use u32 unconditionally and remove
the now unneeded omap-mailbox.h include.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
index 3555b535b1683..33b30cfb86c9d 100644
--- a/drivers/remoteproc/ti_k3_dsp_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_dsp_remoteproc.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -113,7 +112,7 @@ static void k3_dsp_rproc_mbox_callback(struct mbox_client
*client, void *data)
client);
struct device *dev = kproc->rproc->dev.parent;
const char *name = kproc->rproc->name;
- u32 msg = omap_mbox_message(data);
+ u32 msg = (u32)(uintptr_t)(data);
Looking at omap-mailbox.h and unless I'm missing something, the end result is
the same.
dev_dbg(dev, "mbox msg: 0x%x\n", msg);
@@ -152,11 +151,11 @@ static void k3_dsp_rproc_kick(struct rproc *rproc, int vqid)
{
struct k3_dsp_rproc *kproc = rproc->priv;
struct device *dev = rproc->dev.parent;
- mbox_msg_t msg = (mbox_msg_t)vqid;
+ u32 msg = vqid;
int ret;
Here @vqid becomes a 'u32' rather than a 'uintptr'...
u32 is the correct type for messages sent with OMAP mailbox. It
only sends 32bit messages, uintptr is 64bit when compiled on
64bit hardware (like our ARM64 cores on K3). mbox_msg_t should
have been defined as u32, this was a mistake we missed as we only
ever used to compile it for 32bit cores (where uintptr is 32bit).
/* send the index of the triggered virtqueue in the mailbox payload */
- ret = mbox_send_message(kproc->mbox, (void *)msg);
+ ret = mbox_send_message(kproc->mbox, (void *)(uintptr_t)msg);
... but here it is casted as a 'uintptr_t', which yields the same result.
The function mbox_send_message() takes a void*, so we need to cast our 32bit
message to that first, it is cast back to u32 inside the OMAP mailbox driver.
Doing that in one step (u32 -> void*) causes a warning when void* is 64bit
(cast from int to pointer of different size).
I am puzzled - other than getting rid of a header file I don't see what else
this patch does.
Getting rid of the header is the main point of this patch (I have a later
series that needs that header gone). But the difference this patch makes is that
before we passed a pointer to a 64bit int to OMAP mailbox which takes a pointer
to a 32bit int. Sure, the result is the same in little-endian systems, but that
isn't a strictly correct in general.
Thanks,
Andrew
Thanks,
Mathieu
if (ret < 0)
dev_err(dev, "failed to send mailbox message (%pe)\n",
ERR_PTR(ret));
--
2.39.2
Re: [PATCH v2 1/1] vhost: Added pad cleanup if vnet_hdr is not present.
Thanks, I'll look into it. On Thu, Mar 28, 2024 at 6:03 AM Jason Wang wrote: > > On Thu, Mar 28, 2024 at 7:44 AM Andrew Melnychenko wrote: > > > > When the Qemu launched with vhost but without tap vnet_hdr, > > vhost tries to copy vnet_hdr from socket iter with size 0 > > to the page that may contain some trash. > > That trash can be interpreted as unpredictable values for > > vnet_hdr. > > That leads to dropping some packets and in some cases to > > stalling vhost routine when the vhost_net tries to process > > packets and fails in a loop. > > > > Qemu options: > > -netdev tap,vhost=on,vnet_hdr=off,... > > > > From security point of view, wrong values on field used later > > tap's tap_get_user_xdp() and will affect skb gso and options. > > Later the header(and data in headroom) should not be used by the stack. > > Using custom socket as a backend to vhost_net can reveal some data > > in the vnet_hdr, although it would require kernel access to implement. > > > > The issue happens because the value of sock_len in virtqueue is 0. > > That value is set at vhost_net_set_features() with > > VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open() > > and reset() routine. > > So, currently, to trigger the issue, we need to set up qemu with > > vhost=on,vnet_hdr=off, or do not configure vhost in the custom program. > > > > Signed-off-by: Andrew Melnychenko > > Acked-by: Jason Wang > > It seems it has been merged by Michael. > > Thanks > > > --- > > drivers/vhost/net.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c > > index f2ed7167c848..57411ac2d08b 100644 > > --- a/drivers/vhost/net.c > > +++ b/drivers/vhost/net.c > > @@ -735,6 +735,9 @@ static int vhost_net_build_xdp(struct > > vhost_net_virtqueue *nvq, > > hdr = buf; > > gso = >gso; > > > > + if (!sock_hlen) > > + memset(buf, 0, pad); > > + > > if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && > > vhost16_to_cpu(vq, gso->csum_start) + > > vhost16_to_cpu(vq, gso->csum_offset) + 2 > > > -- > > 2.43.0 > > >
[PATCH v2 1/1] vhost: Added pad cleanup if vnet_hdr is not present.
When the Qemu launched with vhost but without tap vnet_hdr, vhost tries to copy vnet_hdr from socket iter with size 0 to the page that may contain some trash. That trash can be interpreted as unpredictable values for vnet_hdr. That leads to dropping some packets and in some cases to stalling vhost routine when the vhost_net tries to process packets and fails in a loop. Qemu options: -netdev tap,vhost=on,vnet_hdr=off,... >From security point of view, wrong values on field used later tap's tap_get_user_xdp() and will affect skb gso and options. Later the header(and data in headroom) should not be used by the stack. Using custom socket as a backend to vhost_net can reveal some data in the vnet_hdr, although it would require kernel access to implement. The issue happens because the value of sock_len in virtqueue is 0. That value is set at vhost_net_set_features() with VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open() and reset() routine. So, currently, to trigger the issue, we need to set up qemu with vhost=on,vnet_hdr=off, or do not configure vhost in the custom program. Signed-off-by: Andrew Melnychenko --- drivers/vhost/net.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index f2ed7167c848..57411ac2d08b 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -735,6 +735,9 @@ static int vhost_net_build_xdp(struct vhost_net_virtqueue *nvq, hdr = buf; gso = >gso; + if (!sock_hlen) + memset(buf, 0, pad); + if ((gso->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) && vhost16_to_cpu(vq, gso->csum_start) + vhost16_to_cpu(vq, gso->csum_offset) + 2 > -- 2.43.0
[PATCH 05/13] mailbox: omap: Remove unneeded header omap-mailbox.h
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). This type should have been defined as
u32. Instead of making that change here, simply remove the header usage
and fix the last couple users of the same in this driver.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 167348fb1b33b..4c673cb732ed1 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -239,16 +238,14 @@ static void mbox_rx_work(struct work_struct *work)
{
struct omap_mbox_queue *mq =
container_of(work, struct omap_mbox_queue, work);
- mbox_msg_t data;
u32 msg;
int len;
while (kfifo_len(>fifo) >= sizeof(msg)) {
len = kfifo_out(>fifo, (unsigned char *), sizeof(msg));
WARN_ON(len != sizeof(msg));
- data = msg;
- mbox_chan_received_data(mq->mbox->chan, (void *)data);
+ mbox_chan_received_data(mq->mbox->chan, (void *)(uintptr_t)msg);
spin_lock_irq(>lock);
if (mq->full) {
mq->full = false;
@@ -515,7 +512,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan,
void *data)
{
struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
int ret;
- u32 msg = omap_mbox_message(data);
+ u32 msg = (u32)(uintptr_t)(data);
if (!mbox)
return -EINVAL;
--
2.39.2
[PATCH 03/13] mailbox: omap: Move omap_mbox_irq_t into driver
This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 5 +
include/linux/omap-mailbox.h | 4
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8151722eef383..c083734b6954c 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -51,6 +51,11 @@
#define MBOX_INTR_CFG_TYPE10
#define MBOX_INTR_CFG_TYPE21
+typedef enum {
+ IRQ_TX = 1,
+ IRQ_RX = 2,
+} omap_mbox_irq_t;
+
struct omap_mbox_fifo {
unsigned long msg;
unsigned long fifo_stat;
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index f8ddf8e814167..3cc5c4ed7f5a6 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -10,8 +10,4 @@ typedef uintptr_t mbox_msg_t;
#define omap_mbox_message(data) (u32)(mbox_msg_t)(data)
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
#endif /* OMAP_MAILBOX_H */
--
2.39.2
[PATCH 09/13] mailbox: omap: Use function local struct mbox_controller
The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 17c9b9df78b1d..97f59d9f9f319 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -86,7 +86,6 @@ struct omap_mbox_device {
u32 num_fifos;
u32 intr_type;
struct omap_mbox **mboxes;
- struct mbox_controller controller;
};
struct omap_mbox {
@@ -541,7 +540,7 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
struct omap_mbox_device *mdev;
struct omap_mbox *mbox;
- mdev = container_of(controller, struct omap_mbox_device, controller);
+ mdev = dev_get_drvdata(controller->dev);
if (WARN_ON(!mdev))
return ERR_PTR(-EINVAL);
@@ -567,6 +566,7 @@ static int omap_mbox_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct device_node *child;
const struct omap_mbox_match_data *match_data;
+ struct mbox_controller *controller;
u32 intr_type, info_count;
u32 num_users, num_fifos;
u32 tmp[3];
@@ -685,17 +685,20 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->intr_type = intr_type;
mdev->mboxes = list;
+ controller = devm_kzalloc(>dev, sizeof(*controller), GFP_KERNEL);
+ if (!controller)
+ return -ENOMEM;
/*
* OMAP/K3 Mailbox IP does not have a Tx-Done IRQ, but rather a Tx-Ready
* IRQ and is needed to run the Tx state machine
*/
- mdev->controller.txdone_irq = true;
- mdev->controller.dev = mdev->dev;
- mdev->controller.ops = _mbox_chan_ops;
- mdev->controller.chans = chnls;
- mdev->controller.num_chans = info_count;
- mdev->controller.of_xlate = omap_mbox_of_xlate;
- ret = devm_mbox_controller_register(mdev->dev, >controller);
+ controller->txdone_irq = true;
+ controller->dev = mdev->dev;
+ controller->ops = _mbox_chan_ops;
+ controller->chans = chnls;
+ controller->num_chans = info_count;
+ controller->of_xlate = omap_mbox_of_xlate;
+ ret = devm_mbox_controller_register(mdev->dev, controller);
if (ret)
return ret;
--
2.39.2
[PATCH 10/13] mailbox: omap: Use mbox_controller channel list directly
The driver stores a list of omap_mbox structs so it can later use it to
lookup the mailbox names in of_xlate. This same information is already
available in the mbox_controller passed into of_xlate. Simply use that
data and remove the extra allocation and storage of the omap_mbox list.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 +-
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 97f59d9f9f319..8e42266cb31a5 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -85,7 +85,6 @@ struct omap_mbox_device {
u32 num_users;
u32 num_fifos;
u32 intr_type;
- struct omap_mbox **mboxes;
};
struct omap_mbox {
@@ -356,25 +355,6 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
mbox_queue_free(mbox->rxq);
}
-static struct omap_mbox *omap_mbox_device_find(struct omap_mbox_device *mdev,
- const char *mbox_name)
-{
- struct omap_mbox *_mbox, *mbox = NULL;
- struct omap_mbox **mboxes = mdev->mboxes;
- int i;
-
- if (!mboxes)
- return NULL;
-
- for (i = 0; (_mbox = mboxes[i]); i++) {
- if (!strcmp(_mbox->name, mbox_name)) {
- mbox = _mbox;
- break;
- }
- }
- return mbox;
-}
-
static int omap_mbox_chan_startup(struct mbox_chan *chan)
{
struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
@@ -539,6 +519,7 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
struct device_node *node;
struct omap_mbox_device *mdev;
struct omap_mbox *mbox;
+ int i;
mdev = dev_get_drvdata(controller->dev);
if (WARN_ON(!mdev))
@@ -551,16 +532,23 @@ static struct mbox_chan *omap_mbox_of_xlate(struct
mbox_controller *controller,
return ERR_PTR(-ENODEV);
}
- mbox = omap_mbox_device_find(mdev, node->name);
+ for (i = 0; i < controller->num_chans; i++) {
+ mbox = controller->chans[i].con_priv;
+ if (!strcmp(mbox->name, node->name)) {
+ of_node_put(node);
+ return >chans[i];
+ }
+ }
+
of_node_put(node);
- return mbox ? mbox->chan : ERR_PTR(-ENOENT);
+ return ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
{
int ret;
struct mbox_chan *chnls;
- struct omap_mbox **list, *mbox;
+ struct omap_mbox *mbox;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
struct device_node *node = pdev->dev.of_node;
@@ -608,12 +596,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
if (!mdev->irq_ctx)
return -ENOMEM;
- /* allocate one extra for marking end of list */
- list = devm_kcalloc(>dev, info_count + 1, sizeof(*list),
- GFP_KERNEL);
- if (!list)
- return -ENOMEM;
-
chnls = devm_kcalloc(>dev, info_count + 1, sizeof(*chnls),
GFP_KERNEL);
if (!chnls)
@@ -675,7 +657,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
return mbox->irq;
mbox->chan = [i];
chnls[i].con_priv = mbox;
- list[i] = mbox++;
}
mutex_init(>cfg_lock);
@@ -683,7 +664,6 @@ static int omap_mbox_probe(struct platform_device *pdev)
mdev->num_users = num_users;
mdev->num_fifos = num_fifos;
mdev->intr_type = intr_type;
- mdev->mboxes = list;
controller = devm_kzalloc(>dev, sizeof(*controller), GFP_KERNEL);
if (!controller)
--
2.39.2
[PATCH 12/13] mailbox: omap: Reverse FIFO busy check logic
It is much more clear to check if the hardware FIFO is full and return
EBUSY if true. This allows us to also remove one level of indention
from the core of this function. It also makes the similarities between
omap_mbox_chan_send_noirq() and omap_mbox_chan_send() more obvious.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e2760d2c5b0c..c5d4083125856 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -375,34 +375,33 @@ static void omap_mbox_chan_shutdown(struct mbox_chan
*chan)
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq(mbox, IRQ_RX);
- mbox_fifo_write(mbox, msg);
- ret = 0;
- omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
+ mbox_fifo_write(mbox, msg);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
- /* we must read and ack the interrupt directly from here */
- mbox_fifo_read(mbox);
- ack_mbox_irq(mbox, IRQ_RX);
- }
+ /* we must read and ack the interrupt directly from here */
+ mbox_fifo_read(mbox);
+ ack_mbox_irq(mbox, IRQ_RX);
- return ret;
+ return 0;
}
static int omap_mbox_chan_send(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
-
- if (!mbox_fifo_full(mbox)) {
- mbox_fifo_write(mbox, msg);
- ret = 0;
+ if (mbox_fifo_full(mbox)) {
+ /* always enable the interrupt */
+ omap_mbox_enable_irq(mbox, IRQ_TX);
+ return -EBUSY;
}
+ mbox_fifo_write(mbox, msg);
+
/* always enable the interrupt */
omap_mbox_enable_irq(mbox, IRQ_TX);
- return ret;
+ return 0;
}
static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
--
2.39.2
[PATCH 00/13] OMAP mailbox FIFO removal
Hello all,
Core of this series is the last patch removing the message FIFO
from OMAP mailbox. This hurts our real-time performance. It was a
legacy leftover from before the common mailbox framework anyway.
The rest of the patches are cleanups found along the way.
Thanks,
Andrew
Andrew Davis (13):
mailbox: omap: Remove unused omap_mbox_{enable,disable}_irq()
functions
mailbox: omap: Remove unused omap_mbox_request_channel() function
mailbox: omap: Move omap_mbox_irq_t into driver
mailbox: omap: Move fifo size check to point of use
mailbox: omap: Remove unneeded header omap-mailbox.h
mailbox: omap: Remove device class
mailbox: omap: Use devm_pm_runtime_enable() helper
mailbox: omap: Merge mailbox child node setup loops
mailbox: omap: Use function local struct mbox_controller
mailbox: omap: Use mbox_controller channel list directly
mailbox: omap: Remove mbox_chan_to_omap_mbox()
mailbox: omap: Reverse FIFO busy check logic
mailbox: omap: Remove kernel FIFO message queuing
drivers/mailbox/Kconfig| 9 -
drivers/mailbox/omap-mailbox.c | 515 +++--
include/linux/omap-mailbox.h | 13 -
3 files changed, 106 insertions(+), 431 deletions(-)
--
2.39.2
[PATCH 13/13] mailbox: omap: Remove kernel FIFO message queuing
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea itself looks to be a leftover from before the
unified mailbox framework. The current mailbox framework expects
mbox_chan_received_data() to be called with data immediately as it
arrives. Remove the FIFO and pass the messages to the mailbox
framework directly.
Signed-off-by: Andrew Davis
---
drivers/mailbox/Kconfig| 9 ---
drivers/mailbox/omap-mailbox.c | 103 +
2 files changed, 3 insertions(+), 109 deletions(-)
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 42940108a1874..78e4c74fbe5c2 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -68,15 +68,6 @@ config OMAP2PLUS_MBOX
OMAP2/3; or IPU, IVA HD and DSP in OMAP4/5. Say Y here if you
want to use OMAP2+ Mailbox framework support.
-config OMAP_MBOX_KFIFO_SIZE
- int "Mailbox kfifo default buffer size (bytes)"
- depends on OMAP2PLUS_MBOX
- default 256
- help
- Specify the default size of mailbox's kfifo buffers (bytes).
- This can also be changed at runtime (via the mbox_kfifo_size
- module parameter).
-
config ROCKCHIP_MBOX
bool "Rockchip Soc Integrated Mailbox Support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c5d4083125856..4e7e0e2f537b0 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -65,14 +65,6 @@ struct omap_mbox_fifo {
u32 intr_bit;
};
-struct omap_mbox_queue {
- spinlock_t lock;
- struct kfifofifo;
- struct work_struct work;
- struct omap_mbox*mbox;
- bool full;
-};
-
struct omap_mbox_match_data {
u32 intr_type;
};
@@ -90,7 +82,6 @@ struct omap_mbox_device {
struct omap_mbox {
const char *name;
int irq;
- struct omap_mbox_queue *rxq;
struct omap_mbox_device *parent;
struct omap_mbox_fifo tx_fifo;
struct omap_mbox_fifo rx_fifo;
@@ -99,10 +90,6 @@ struct omap_mbox {
boolsend_no_irq;
};
-static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
-module_param(mbox_kfifo_size, uint, S_IRUGO);
-MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -202,30 +189,6 @@ static void omap_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-/*
- * Message receiver(workqueue)
- */
-static void mbox_rx_work(struct work_struct *work)
-{
- struct omap_mbox_queue *mq =
- container_of(work, struct omap_mbox_queue, work);
- u32 msg;
- int len;
-
- while (kfifo_len(>fifo) >= sizeof(msg)) {
- len = kfifo_out(>fifo, (unsigned char *), sizeof(msg));
- WARN_ON(len != sizeof(msg));
-
- mbox_chan_received_data(mq->mbox->chan, (void *)(uintptr_t)msg);
- spin_lock_irq(>lock);
- if (mq->full) {
- mq->full = false;
- omap_mbox_enable_irq(mq->mbox, IRQ_RX);
- }
- spin_unlock_irq(>lock);
- }
-}
-
/*
* Mailbox interrupt handler
*/
@@ -238,27 +201,15 @@ static void __mbox_tx_interrupt(struct omap_mbox *mbox)
static void __mbox_rx_interrupt(struct omap_mbox *mbox)
{
- struct omap_mbox_queue *mq = mbox->rxq;
u32 msg;
- int len;
while (!mbox_fifo_empty(mbox)) {
- if (unlikely(kfifo_avail(>fifo) < sizeof(msg))) {
- omap_mbox_disable_irq(mbox, IRQ_RX);
- mq->full = true;
- goto nomem;
- }
-
msg = mbox_fifo_read(mbox);
-
- len = kfifo_in(>fifo, (unsigned char *), sizeof(msg));
- WARN_ON(len != sizeof(msg));
+ mbox_chan_received_data(mbox->chan, (void *)(uintptr_t)msg);
}
- /* no more messages in the fifo. clear IRQ source. */
+ /* clear IRQ source. */
ack_mbox_irq(mbox, IRQ_RX);
-nomem:
- schedule_work(>rxq->work);
}
static irqreturn_t mbox_interrupt(int irq, void *p)
@@ -274,57 +225,15 @@ static irqreturn_t mbox_interrupt(int irq, void *p)
return IRQ_HANDLED;
}
-static struct omap_mbox_queue *mbox_queue_alloc(struct omap_mbox *mbox,
- void (*work)(struct work_struct *))
-{
- struct omap_mbox_queue *mq;
- unsigned int size;
-
-
[PATCH 11/13] mailbox: omap: Remove mbox_chan_to_omap_mbox()
This function only checks if mbox_chan *chan is not NULL, but that cannot
be the case and if it was returning NULL which is not later checked
doesn't save us from this. The second check for chan->con_priv is
completely redundant as if it was NULL we would return NULL just the
same. Simply dereference con_priv directly and remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e42266cb31a5..8e2760d2c5b0c 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -103,14 +103,6 @@ static unsigned int mbox_kfifo_size =
CONFIG_OMAP_MBOX_KFIFO_SIZE;
module_param(mbox_kfifo_size, uint, S_IRUGO);
MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
-static struct omap_mbox *mbox_chan_to_omap_mbox(struct mbox_chan *chan)
-{
- if (!chan || !chan->con_priv)
- return NULL;
-
- return (struct omap_mbox *)chan->con_priv;
-}
-
static inline
unsigned int mbox_read_reg(struct omap_mbox_device *mdev, size_t ofs)
{
@@ -357,7 +349,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
static int omap_mbox_chan_startup(struct mbox_chan *chan)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
struct omap_mbox_device *mdev = mbox->parent;
int ret = 0;
@@ -372,7 +364,7 @@ static int omap_mbox_chan_startup(struct mbox_chan *chan)
static void omap_mbox_chan_shutdown(struct mbox_chan *chan)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
struct omap_mbox_device *mdev = mbox->parent;
mutex_lock(>cfg_lock);
@@ -415,7 +407,7 @@ static int omap_mbox_chan_send(struct omap_mbox *mbox, u32
msg)
static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
+ struct omap_mbox *mbox = chan->con_priv;
int ret;
u32 msg = (u32)(uintptr_t)(data);
--
2.39.2
[PATCH 01/13] mailbox: omap: Remove unused omap_mbox_{enable,disable}_irq() functions
These function are not used, remove these here.
While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 --
include/linux/omap-mailbox.h | 3 ---
2 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index c961706fe61d5..624a7ccc27285 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -197,7 +197,7 @@ static int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
return (int)(enable & status & bit);
}
-static void _omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
u32 l;
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
@@ -210,7 +210,7 @@ static void _omap_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, l, irqenable);
}
-static void _omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+static void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox_fifo *fifo = (irq == IRQ_TX) ?
>tx_fifo : >rx_fifo;
@@ -227,28 +227,6 @@ static void _omap_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
mbox_write_reg(mbox->parent, bit, irqdisable);
}
-void omap_mbox_enable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
-{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
-
- if (WARN_ON(!mbox))
- return;
-
- _omap_mbox_enable_irq(mbox, irq);
-}
-EXPORT_SYMBOL(omap_mbox_enable_irq);
-
-void omap_mbox_disable_irq(struct mbox_chan *chan, omap_mbox_irq_t irq)
-{
- struct omap_mbox *mbox = mbox_chan_to_omap_mbox(chan);
-
- if (WARN_ON(!mbox))
- return;
-
- _omap_mbox_disable_irq(mbox, irq);
-}
-EXPORT_SYMBOL(omap_mbox_disable_irq);
-
/*
* Message receiver(workqueue)
*/
@@ -269,7 +247,7 @@ static void mbox_rx_work(struct work_struct *work)
spin_lock_irq(>lock);
if (mq->full) {
mq->full = false;
- _omap_mbox_enable_irq(mq->mbox, IRQ_RX);
+ omap_mbox_enable_irq(mq->mbox, IRQ_RX);
}
spin_unlock_irq(>lock);
}
@@ -280,7 +258,7 @@ static void mbox_rx_work(struct work_struct *work)
*/
static void __mbox_tx_interrupt(struct omap_mbox *mbox)
{
- _omap_mbox_disable_irq(mbox, IRQ_TX);
+ omap_mbox_disable_irq(mbox, IRQ_TX);
ack_mbox_irq(mbox, IRQ_TX);
mbox_chan_txdone(mbox->chan, 0);
}
@@ -293,7 +271,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(>fifo) < sizeof(msg))) {
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
mq->full = true;
goto nomem;
}
@@ -375,7 +353,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
if (mbox->send_no_irq)
mbox->chan->txdone_method = TXDONE_BY_ACK;
- _omap_mbox_enable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
return 0;
@@ -386,7 +364,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
static void omap_mbox_fini(struct omap_mbox *mbox)
{
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
free_irq(mbox->irq, mbox);
flush_work(>rxq->work);
mbox_queue_free(mbox->rxq);
@@ -533,10 +511,10 @@ static int omap_mbox_chan_send_noirq(struct omap_mbox
*mbox, u32 msg)
int ret = -EBUSY;
if (!mbox_fifo_full(mbox)) {
- _omap_mbox_enable_irq(mbox, IRQ_RX);
+ omap_mbox_enable_irq(mbox, IRQ_RX);
mbox_fifo_write(mbox, msg);
ret = 0;
- _omap_mbox_disable_irq(mbox, IRQ_RX);
+ omap_mbox_disable_irq(mbox, IRQ_RX);
/* we must read and ack the interrupt directly from here */
mbox_fifo_read(mbox);
@@ -556,7 +534,7 @@ static int omap_mbox_chan_send(struct omap_mbox *mbox, u32
msg)
}
/* always enable the interrupt */
- _omap_mbox_enable_irq(mbox, IRQ_TX);
+ omap_mbox_enable_irq(mbox, IRQ_TX);
return ret;
}
diff --git a/include/linux/omap-mailbox.h b/include/linux/omap-mailbox.h
index 8aa984ec1f38b..426a80fb32b5c 100644
--- a/include/linux/omap-mailbox.h
+++ b/include/linux/omap-mailbox.h
@@ -20,7 +20,4 @@ struct mbox_client;
struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
