The mediatek remoteproc driver currently only allows bringing up a
single core SCP, e.g. MT8183. It also only bringing up the 1st
core in SoCs with a dual-core SCP, e.g. MT8195. This series support
to bring-up the 2nd core of the dual-core SCP.
v16 -> v17:
1. add a comment in scp_add_multi_core() at patchset 8
v15 -> v16:
1. fix the checkpatch warning at patchset 1
2. move changes on scp_probe() to the new added patchset 6
3. revise platform_set_drvdata() at patchset 8
4. fix commit message at patchset 9
v15 -> v14:
1. use the common SCP registers in struct mtk_scp_of_cluster instead of
copy it to struct mtk_scp at patchset 5
2. use platform_set_drvdata instead of platform_device_add_data at patchset 5
3. rename l2tcm_lock to cluster_lock at patchset 8
4. check l2tcm_refcnt value before decreasing at patchset 8
5. revise the commit message at patchset 11
v13 -> v14:
1. add review tag to patchset 1,6
2. exchange the order of sram power on and reset assert in
mt8195_scp_c1_before_load at patchset 2
3. use ERR_CAST in patchset 5
4. re-write patchset 7 to remove dependency between core 0 and core 1
5. add patch set 10 to report watchdot timeout to all cores
v12 -> v13:
1. replace subdevice with new mediatek scp operations in patchset 7
2. add review tag to patchset 3
3. modify mediatek,scp phandle name of video-codec@18000000 at patchset 11
v11 -> v12:
1. add scp_add_single/multi_core() to patchset 6
2. remove unused comment in patchset 6
3. rename list name from mtk_scp_cluster to mtk_scp_list
4. rewrite the multi-core probe flow
5. disable rproc->autoboot and boot rproc by request_firmware_nowait at patchset 7
6. remove patchset 7 review tag
v10 -> v11:
1. rewrite patchset 5 to probe single-core SCP with the cluster list
2. Also in patchset 5, move the pointer of mtk_scp object from the
platform data property to the driver data property
3. move the appearance of mtk_scp cluster property to patcheset 7
v9 -> v10:
1. move the global mtk_scp list into the platform device driver data structure
2. remove an unnecessary if() condition
v8 -> v9:
1. initialize l1tcm_size/l1tcm_phys at patchset 05/11
2. rewrite patchset 06/11 to unify the flow and remove hacks
v7 -> v8:
1. update the node name of mt8192 asurada SCP rpmsg subnode
2. squash register definitions into driver patches
3. initialize local variables on the declaration at patch v8 06/11
v6 -> v7:
1. merge the mtk_scp_cluster struct into the mtk_scp structure
at the "Probe multi-core SCP" patch
v5 -> v6:
1. move the mtk_scp_of_regs structure from mtk_common.h to mtk_scp.c
2. rename the SCP core 0 label from 'scp' to 'scp_c0'
v4 -> v5:
1. move resource release actions to the platform driver remove operation
2. fix dual-core watchdog handling
v3 -> v4:
1. change the representation of dual-core SCP in dts file and update SCP yaml
2. rewrite SCP driver to reflect the change of dts node
3. drop 'remove redundant call of rproc_boot for SCP' in v3 for further investigation
v2 -> v3:
1. change the representation of dual-core SCP in dts file and update SCP yaml
2. rewrite SCP driver to reflect the change of dts node
3. add SCP core 1 node to mt8195.dtsi
4. remove redundant call of rproc_boot for SCP
5. refine IPI error message
v1 -> v2:
1. update dt-binding property description
2. remove kconfig for scp dual driver
3. merge mtk_scp_dual.c and mtk_scp_subdev.c to mtk_scp.c
Tinghan Shen (14):
dt-bindings: remoteproc: mediatek: Improve the rpmsg subnode
definition
arm64: dts: mediatek: Update the node name of SCP rpmsg subnode
dt-bindings: remoteproc: mediatek: Support MT8195 dual-core SCP
remoteproc: mediatek: Add MT8195 SCP core 1 operations
remoteproc: mediatek: Extract SCP common registers
remoteproc: mediatek: Revise SCP rproc initialization flow for
multi-core SCP
remoteproc: mediatek: Probe SCP cluster on single-core SCP
remoteproc: mediatek: Probe SCP cluster on multi-core SCP
remoteproc: mediatek: Remove dependency of MT8195 SCP L2TCM power
control on dual-core SCP
remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset
remoteproc: mediatek: Handle MT8195 SCP core 1 watchdog timeout
remoteproc: mediatek: Report watchdog crash to all cores
remoteproc: mediatek: Refine ipi handler error message
arm64: dts: mediatek: mt8195: Add SCP 2nd core
.../bindings/remoteproc/mtk,scp.yaml | 176 +++++-
.../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 +-
.../boot/dts/mediatek/mt8192-asurada.dtsi | 2 +-
.../boot/dts/mediatek/mt8195-cherry.dtsi | 6 +-
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 34 +-
drivers/remoteproc/mtk_common.h | 39 +-
drivers/remoteproc/mtk_scp.c | 539 ++++++++++++++----
drivers/remoteproc/mtk_scp_ipi.c | 4 +-
8 files changed, 656 insertions(+), 146 deletions(-)
--
2.18.0
This is the 3rd preliminary step for probing multi-core SCP.
Rewrite the probing flow of single-core SCP to adapt with the 'cluster'
concept needed by the multi-core SCP. The SCP core object(s)
is maintained at the cluster list.
Signed-off-by: Tinghan Shen <[email protected]>
---
drivers/remoteproc/mtk_common.h | 2 +
drivers/remoteproc/mtk_scp.c | 86 +++++++++++++++++++++++----------
2 files changed, 63 insertions(+), 25 deletions(-)
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index b04d71277c1f..1438159ae736 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -105,6 +105,7 @@ struct mtk_scp_of_cluster {
void __iomem *l1tcm_base;
size_t l1tcm_size;
phys_addr_t l1tcm_phys;
+ struct list_head mtk_scp_list;
};
struct mtk_scp {
@@ -132,6 +133,7 @@ struct mtk_scp {
struct rproc_subdev *rpmsg_subdev;
+ struct list_head elem;
struct mtk_scp_of_cluster *cluster;
};
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 7a2ba1e1e95a..d67dcabdab9e 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -854,8 +854,8 @@ static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
}
}
-static int scp_rproc_init(struct platform_device *pdev,
- struct mtk_scp_of_cluster *scp_cluster)
+static struct mtk_scp *scp_rproc_init(struct platform_device *pdev,
+ struct mtk_scp_of_cluster *scp_cluster)
{
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
@@ -867,11 +867,13 @@ static int scp_rproc_init(struct platform_device *pdev,
ret = rproc_of_parse_firmware(dev, 0, &fw_name);
if (ret < 0 && ret != -EINVAL)
- return ret;
+ return ERR_PTR(ret);
rproc = devm_rproc_alloc(dev, np->name, &scp_ops, fw_name, sizeof(*scp));
- if (!rproc)
- return dev_err_probe(dev, -ENOMEM, "unable to allocate remoteproc\n");
+ if (!rproc) {
+ dev_err(dev, "unable to allocate remoteproc\n");
+ return ERR_PTR(-ENOMEM);
+ }
scp = rproc->priv;
scp->rproc = rproc;
@@ -882,20 +884,21 @@ static int scp_rproc_init(struct platform_device *pdev,
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sram");
scp->sram_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(scp->sram_base))
- return dev_err_probe(dev, PTR_ERR(scp->sram_base),
- "Failed to parse and map sram memory\n");
+ if (IS_ERR(scp->sram_base)) {
+ dev_err(dev, "Failed to parse and map sram memory\n");
+ return ERR_CAST(scp->sram_base);
+ }
scp->sram_size = resource_size(res);
scp->sram_phys = res->start;
ret = scp->data->scp_clk_get(scp);
if (ret)
- return ret;
+ return ERR_PTR(ret);
ret = scp_map_memory_region(scp);
if (ret)
- return ret;
+ return ERR_PTR(ret);
mutex_init(&scp->send_lock);
for (i = 0; i < SCP_IPI_MAX; i++)
@@ -922,11 +925,7 @@ static int scp_rproc_init(struct platform_device *pdev,
goto remove_subdev;
}
- ret = rproc_add(rproc);
- if (ret)
- goto remove_subdev;
-
- return 0;
+ return scp;
remove_subdev:
scp_remove_rpmsg_subdev(scp);
@@ -937,7 +936,43 @@ static int scp_rproc_init(struct platform_device *pdev,
mutex_destroy(&scp->ipi_desc[i].lock);
mutex_destroy(&scp->send_lock);
- return ret;
+ return ERR_PTR(ret);
+}
+
+static void scp_free(struct mtk_scp *scp)
+{
+ int i;
+
+ scp_remove_rpmsg_subdev(scp);
+ scp_ipi_unregister(scp, SCP_IPI_INIT);
+ scp_unmap_memory_region(scp);
+ for (i = 0; i < SCP_IPI_MAX; i++)
+ mutex_destroy(&scp->ipi_desc[i].lock);
+ mutex_destroy(&scp->send_lock);
+}
+
+static int scp_cluster_init(struct platform_device *pdev,
+ struct mtk_scp_of_cluster *scp_cluster)
+{
+ struct device *dev = &pdev->dev;
+ struct list_head *scp_list = &scp_cluster->mtk_scp_list;
+ struct mtk_scp *scp;
+ int ret;
+
+ scp = scp_rproc_init(pdev, scp_cluster);
+ if (IS_ERR(scp))
+ return PTR_ERR(scp);
+
+ ret = rproc_add(scp->rproc);
+ if (ret) {
+ dev_err(dev, "Failed to add rproc\n");
+ scp_free(scp);
+ return ret;
+ }
+
+ list_add_tail(&scp->elem, scp_list);
+
+ return 0;
}
static int scp_probe(struct platform_device *pdev)
@@ -970,7 +1005,9 @@ static int scp_probe(struct platform_device *pdev)
scp_cluster->l1tcm_phys = res->start;
}
- ret = scp_rproc_init(pdev, scp_cluster);
+ INIT_LIST_HEAD(&scp_cluster->mtk_scp_list);
+
+ ret = scp_cluster_init(pdev, scp_cluster);
if (ret)
return ret;
@@ -980,15 +1017,14 @@ static int scp_probe(struct platform_device *pdev)
static void scp_remove(struct platform_device *pdev)
{
struct mtk_scp *scp = platform_get_drvdata(pdev);
- int i;
+ struct mtk_scp_of_cluster *scp_cluster = scp->cluster;
+ struct mtk_scp *temp;
- rproc_del(scp->rproc);
- scp_remove_rpmsg_subdev(scp);
- scp_ipi_unregister(scp, SCP_IPI_INIT);
- scp_unmap_memory_region(scp);
- for (i = 0; i < SCP_IPI_MAX; i++)
- mutex_destroy(&scp->ipi_desc[i].lock);
- mutex_destroy(&scp->send_lock);
+ list_for_each_entry_safe_reverse(scp, temp, &scp_cluster->mtk_scp_list, elem) {
+ list_del(&scp->elem);
+ rproc_del(scp->rproc);
+ scp_free(scp);
+ }
}
static const struct mtk_scp_of_data mt8183_of_data = {
--
2.18.0
To ensure consistent behavior, the watchdog timeout handling of the
multi-core SCP should reset the whole SCP sub-system when watchdog
timeout. Triggering the rproc recovery flow on all instances will
ensure proper recovery of the SCP sub-system.
Signed-off-by: Tinghan Shen <[email protected]>
---
drivers/remoteproc/mtk_scp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 49b2ca2b30b3..37ee5e6286ee 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -68,8 +68,14 @@ EXPORT_SYMBOL_GPL(scp_put);
static void scp_wdt_handler(struct mtk_scp *scp, u32 scp_to_host)
{
+ struct mtk_scp_of_cluster *scp_cluster = scp->cluster;
+ struct mtk_scp *scp_node;
+
dev_err(scp->dev, "SCP watchdog timeout! 0x%x", scp_to_host);
- rproc_report_crash(scp->rproc, RPROC_WATCHDOG);
+
+ /* report watchdog timeout to all cores */
+ list_for_each_entry(scp_node, &scp_cluster->mtk_scp_list, elem)
+ rproc_report_crash(scp_node->rproc, RPROC_WATCHDOG);
}
static void scp_init_ipi_handler(void *data, unsigned int len, void *priv)
--
2.18.0
On Fri, Sep 01, 2023 at 04:09:21PM +0800, Tinghan Shen wrote:
> The mediatek remoteproc driver currently only allows bringing up a
> single core SCP, e.g. MT8183. It also only bringing up the 1st
> core in SoCs with a dual-core SCP, e.g. MT8195. This series support
> to bring-up the 2nd core of the dual-core SCP.
>
> v16 -> v17:
> 1. add a comment in scp_add_multi_core() at patchset 8
Other than patch 2 and 14, I have applied this set. The remaining patches will
have to be resent to Matthias.
Thanks,
Mathieu
>
> v15 -> v16:
> 1. fix the checkpatch warning at patchset 1
> 2. move changes on scp_probe() to the new added patchset 6
> 3. revise platform_set_drvdata() at patchset 8
> 4. fix commit message at patchset 9
>
> v15 -> v14:
> 1. use the common SCP registers in struct mtk_scp_of_cluster instead of
> copy it to struct mtk_scp at patchset 5
> 2. use platform_set_drvdata instead of platform_device_add_data at patchset 5
> 3. rename l2tcm_lock to cluster_lock at patchset 8
> 4. check l2tcm_refcnt value before decreasing at patchset 8
> 5. revise the commit message at patchset 11
>
> v13 -> v14:
> 1. add review tag to patchset 1,6
> 2. exchange the order of sram power on and reset assert in
> mt8195_scp_c1_before_load at patchset 2
> 3. use ERR_CAST in patchset 5
> 4. re-write patchset 7 to remove dependency between core 0 and core 1
> 5. add patch set 10 to report watchdot timeout to all cores
>
> v12 -> v13:
> 1. replace subdevice with new mediatek scp operations in patchset 7
> 2. add review tag to patchset 3
> 3. modify mediatek,scp phandle name of video-codec@18000000 at patchset 11
>
> v11 -> v12:
> 1. add scp_add_single/multi_core() to patchset 6
> 2. remove unused comment in patchset 6
> 3. rename list name from mtk_scp_cluster to mtk_scp_list
> 4. rewrite the multi-core probe flow
> 5. disable rproc->autoboot and boot rproc by request_firmware_nowait at patchset 7
> 6. remove patchset 7 review tag
>
> v10 -> v11:
> 1. rewrite patchset 5 to probe single-core SCP with the cluster list
> 2. Also in patchset 5, move the pointer of mtk_scp object from the
> platform data property to the driver data property
> 3. move the appearance of mtk_scp cluster property to patcheset 7
>
> v9 -> v10:
> 1. move the global mtk_scp list into the platform device driver data structure
> 2. remove an unnecessary if() condition
>
> v8 -> v9:
> 1. initialize l1tcm_size/l1tcm_phys at patchset 05/11
> 2. rewrite patchset 06/11 to unify the flow and remove hacks
>
> v7 -> v8:
> 1. update the node name of mt8192 asurada SCP rpmsg subnode
> 2. squash register definitions into driver patches
> 3. initialize local variables on the declaration at patch v8 06/11
>
> v6 -> v7:
> 1. merge the mtk_scp_cluster struct into the mtk_scp structure
> at the "Probe multi-core SCP" patch
>
> v5 -> v6:
> 1. move the mtk_scp_of_regs structure from mtk_common.h to mtk_scp.c
> 2. rename the SCP core 0 label from 'scp' to 'scp_c0'
>
> v4 -> v5:
> 1. move resource release actions to the platform driver remove operation
> 2. fix dual-core watchdog handling
>
> v3 -> v4:
> 1. change the representation of dual-core SCP in dts file and update SCP yaml
> 2. rewrite SCP driver to reflect the change of dts node
> 3. drop 'remove redundant call of rproc_boot for SCP' in v3 for further investigation
>
> v2 -> v3:
> 1. change the representation of dual-core SCP in dts file and update SCP yaml
> 2. rewrite SCP driver to reflect the change of dts node
> 3. add SCP core 1 node to mt8195.dtsi
> 4. remove redundant call of rproc_boot for SCP
> 5. refine IPI error message
>
> v1 -> v2:
> 1. update dt-binding property description
> 2. remove kconfig for scp dual driver
> 3. merge mtk_scp_dual.c and mtk_scp_subdev.c to mtk_scp.c
>
>
> Tinghan Shen (14):
> dt-bindings: remoteproc: mediatek: Improve the rpmsg subnode
> definition
> arm64: dts: mediatek: Update the node name of SCP rpmsg subnode
> dt-bindings: remoteproc: mediatek: Support MT8195 dual-core SCP
> remoteproc: mediatek: Add MT8195 SCP core 1 operations
> remoteproc: mediatek: Extract SCP common registers
> remoteproc: mediatek: Revise SCP rproc initialization flow for
> multi-core SCP
> remoteproc: mediatek: Probe SCP cluster on single-core SCP
> remoteproc: mediatek: Probe SCP cluster on multi-core SCP
> remoteproc: mediatek: Remove dependency of MT8195 SCP L2TCM power
> control on dual-core SCP
> remoteproc: mediatek: Setup MT8195 SCP core 1 SRAM offset
> remoteproc: mediatek: Handle MT8195 SCP core 1 watchdog timeout
> remoteproc: mediatek: Report watchdog crash to all cores
> remoteproc: mediatek: Refine ipi handler error message
> arm64: dts: mediatek: mt8195: Add SCP 2nd core
>
> .../bindings/remoteproc/mtk,scp.yaml | 176 +++++-
> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 +-
> .../boot/dts/mediatek/mt8192-asurada.dtsi | 2 +-
> .../boot/dts/mediatek/mt8195-cherry.dtsi | 6 +-
> arch/arm64/boot/dts/mediatek/mt8195.dtsi | 34 +-
> drivers/remoteproc/mtk_common.h | 39 +-
> drivers/remoteproc/mtk_scp.c | 539 ++++++++++++++----
> drivers/remoteproc/mtk_scp_ipi.c | 4 +-
> 8 files changed, 656 insertions(+), 146 deletions(-)
>
> --
> 2.18.0
>
On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <[email protected]> wrote:
>
> > Other than patch 2 and 14, I have applied this set. The remaining patches will
> > have to be resent to Matthias.
>
> > Thanks,
> > Mathieu
>
> Hello,
>
> With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
>
> 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
>
> The issue was caught by KernelCI, complete logs can be found here:
> - asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
> - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
>
> Reporting the issue so that patch 2 and 14 can be resent and merged soon.
This being a backward incompatible DT binding change, maybe we should revert
the node name change. Or, the driver could simply count the number of child
nodes that have the "mediatek,rpmsg-name" property, which is required.
ChenYu
> Other than patch 2 and 14, I have applied this set. The remaining patches will
> have to be resent to Matthias.
> Thanks,
> Mathieu
Hello,
With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
The issue was caught by KernelCI, complete logs can be found here:
- asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
- kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
Reporting the issue so that patch 2 and 14 can be resent and merged soon.
Best,
Laura
On Mon, Sep 18, 2023 at 12:31:41PM +0200, Laura Nao wrote:
> > Other than patch 2 and 14, I have applied this set. The remaining patches will
> > have to be resent to Matthias.
>
> > Thanks,
> > Mathieu
>
> Hello,
>
> With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
>
> 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
>
> The issue was caught by KernelCI, complete logs can be found here:
> - asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
> - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
>
> Reporting the issue so that patch 2 and 14 can be resent and merged soon.
>
Apologies for the trouble here, the error is mine.
I have applied and pushed patch 02 - please confirm that things are working as
expected now. Matthias will need to either ack patch 14 or pick it up himself.
> Best,
>
> Laura
>
On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier
<[email protected]> wrote:
>
> On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <[email protected]> wrote:
> > >
> > > > Other than patch 2 and 14, I have applied this set. The remaining patches will
> > > > have to be resent to Matthias.
> > >
> > > > Thanks,
> > > > Mathieu
> > >
> > > Hello,
> > >
> > > With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
> > >
> > > 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> > > 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> > > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
> > >
> > > The issue was caught by KernelCI, complete logs can be found here:
> > > - asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
> > > - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
> > >
> > > Reporting the issue so that patch 2 and 14 can be resent and merged soon.
> >
> > This being a backward incompatible DT binding change, maybe we should revert
> > the node name change. Or, the driver could simply count the number of child
> > nodes that have the "mediatek,rpmsg-name" property, which is required.
> >
>
> You have a point. Can someone send a patch that makes this patchset backward
> compatible? Please do so as quickly as possible to that it can go in the next
> merge window with the rest of this feature. Otherwize I'll have to back out the
> whole thing.
I sent out a patch [1] implementing my proposed change.
ChenYu
[1] https://lore.kernel.org/linux-remoteproc/[email protected]/
On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote:
> On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <[email protected]> wrote:
> >
> > > Other than patch 2 and 14, I have applied this set. The remaining patches will
> > > have to be resent to Matthias.
> >
> > > Thanks,
> > > Mathieu
> >
> > Hello,
> >
> > With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
> >
> > 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> > 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
> >
> > The issue was caught by KernelCI, complete logs can be found here:
> > - asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
> > - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
> >
> > Reporting the issue so that patch 2 and 14 can be resent and merged soon.
>
> This being a backward incompatible DT binding change, maybe we should revert
> the node name change. Or, the driver could simply count the number of child
> nodes that have the "mediatek,rpmsg-name" property, which is required.
>
You have a point. Can someone send a patch that makes this patchset backward
compatible? Please do so as quickly as possible to that it can go in the next
merge window with the rest of this feature. Otherwize I'll have to back out the
whole thing.
Thanks,
Mathieu
> ChenYu
On 9/19/23 03:14, Mathieu Poirier wrote:
> On Mon, Sep 18, 2023 at 12:31:41PM +0200, Laura Nao wrote:
>>> Other than patch 2 and 14, I have applied this set. The remaining patches will
>>> have to be resent to Matthias.
>>
>>> Thanks,
>>> Mathieu
>>
>> Hello,
>>
>> With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
>>
>> 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
>> 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
>> 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
>>
>> The issue was caught by KernelCI, complete logs can be found here:
>> - asurada: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html
>> - kukui: https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html
>>
>> Reporting the issue so that patch 2 and 14 can be resent and merged soon.
>>
>
> Apologies for the trouble here, the error is mine.
>
> I have applied and pushed patch 02 - please confirm that things are working as
> expected now. Matthias will need to either ack patch 14 or pick it up himself.
>
>
I confirm SCP is probed correctly on MT8192 (spherion) and MT8183 (juniper) on the remoteproc tree (for-next branch) now.
Thank you!
On Tue, 2023-09-19 at 13:07 +0800, Chen-Yu Tsai wrote:
> On Tue, Sep 19, 2023 at 9:17 AM Mathieu Poirier
> <[email protected]> wrote:
> >
> > On Mon, Sep 18, 2023 at 06:44:25PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Sep 18, 2023 at 6:32 PM Laura Nao <[email protected]> wrote:
> > > >
> > > > > Other than patch 2 and 14, I have applied this set. The remaining patches will
> > > > > have to be resent to Matthias.
> > > > > Thanks,
> > > > > Mathieu
> > > >
> > > > Hello,
> > > >
> > > > With patch 2 missing, the SCP is not probed correctly anymore on asurada (MT8192) and kukui (MT8183). The mtk-scp driver relies on the existence of the `cros-ec-rpmsg` node in the dt to determine if the SCP is single or multicore. Without patch 2 the driver wrongly assumes the SCP on MT8192 and MT8183 are multicore, leading to the following errors during initialization:
> > > >
> > > > 10696 04:33:59.126671 <3>[ 15.465714] platform 10500000.scp:cros-ec: invalid resource (null)
> > > > 10697 04:33:59.142855 <3>[ 15.478560] platform 10500000.scp:cros-ec: Failed to parse and map sram memory
> > > > 10698 04:33:59.149650 <3>[ 15.486121] mtk-scp 10500000.scp: Failed to initialize core 0 rproc
> > > >
> > > > The issue was caught by KernelCI, complete logs can be found here:
> > > > - asurada: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OxUmrqNE$
> > > > - kukui: https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230914/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/baseline-nfs-mt8183-kukui-jacuzzi-juniper-sku16.html__;Kys!!CTRNKA9wMg0ARbw!iEMruK4bVWfCmhRmyauJtkTioHdQbYP3DwhnGUZNxbKYhMzusmoIjYOnpVNALoMobUdKhooUYw6OhRxz6NQ$
> > > >
> > > > Reporting the issue so that patch 2 and 14 can be resent and merged soon.
> > >
> > > This being a backward incompatible DT binding change, maybe we should revert
> > > the node name change. Or, the driver could simply count the number of child
> > > nodes that have the "mediatek,rpmsg-name" property, which is required.
> > >
> >
> > You have a point. Can someone send a patch that makes this patchset backward
> > compatible? Please do so as quickly as possible to that it can go in the next
> > merge window with the rest of this feature. Otherwize I'll have to back out the
> > whole thing.
>
> I sent out a patch [1] implementing my proposed change.
>
> ChenYu
>
> [1] https://lore.kernel.org/linux-remoteproc/[email protected]/
My version[1] is inspired by Angelo's work[2].
[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/
Best regards,
TingHan