Message ID | 20230209074021.13936-11-tinghan.shen@mediatek.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Add support for MT8195 SCP 2nd core | expand |
Il 09/02/23 08:40, Tinghan Shen ha scritto: > The MT8195 SCP core 1 watchdog timeout needs to be handled in the > SCP core 0 IRQ handler because the MT8195 SCP core 1 watchdog timeout > IRQ is wired on the same IRQ entry for core 0 watchdog timeout. > MT8195 SCP has a watchdog status register to identify the watchdog > timeout source when IRQ triggered. > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> > --- > drivers/remoteproc/mtk_common.h | 4 ++++ > drivers/remoteproc/mtk_scp.c | 24 +++++++++++++++++++++++- > 2 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h > index e4ef97f2d3a1..ca2395b98d27 100644 > --- a/drivers/remoteproc/mtk_common.h > +++ b/drivers/remoteproc/mtk_common.h > @@ -55,6 +55,10 @@ > #define MT8192_CORE0_WDT_IRQ 0x10030 > #define MT8192_CORE0_WDT_CFG 0x10034 > > +#define MT8195_SYS_STATUS 0x4004 > +#define MT8195_CORE0_WDT BIT(16) > +#define MT8195_CORE1_WDT BIT(17) > + > #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS GENMASK(7, 4) > > #define MT8195_CPU1_SRAM_PD 0x1084 > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c > index cfcb719ba50b..9fbbc4751433 100644 > --- a/drivers/remoteproc/mtk_scp.c > +++ b/drivers/remoteproc/mtk_scp.c > @@ -222,6 +222,28 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp) > } > } > > +static void mt8195_scp_irq_handler(struct mtk_scp *scp) Looking at the C1 interrupt handler, I don't see any WDT timeout handling, hence a question naturally arises: Would it ever be possible for *both* CORE0 and CORE1 WDT timeout to happen at the same time? Meaning that MT8195_SYS_STATUS has *both* CORE0_WDT and CORE1_WDT bits set when we reach this interrupt handler? In that case, the fix would be to just change.... > +{ > + u32 scp_to_host; > + > + scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET); > + > + if (scp_to_host & MT8192_SCP_IPC_INT_BIT) { > + scp_ipi_handler(scp); > + } else { > + u32 reason = readl(scp->reg_base + MT8195_SYS_STATUS); > + > + if (reason & MT8195_CORE1_WDT) > + writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ); > + else ...the 'else' to another conditional :-) Regards, Angelo
On Thu, 2023-02-09 at 13:48 +0100, AngeloGioacchino Del Regno wrote: > Il 09/02/23 08:40, Tinghan Shen ha scritto: > > The MT8195 SCP core 1 watchdog timeout needs to be handled in the > > SCP core 0 IRQ handler because the MT8195 SCP core 1 watchdog timeout > > IRQ is wired on the same IRQ entry for core 0 watchdog timeout. > > MT8195 SCP has a watchdog status register to identify the watchdog > > timeout source when IRQ triggered. > > > > Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> > > --- > > drivers/remoteproc/mtk_common.h | 4 ++++ > > drivers/remoteproc/mtk_scp.c | 24 +++++++++++++++++++++++- > > 2 files changed, 27 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h > > index e4ef97f2d3a1..ca2395b98d27 100644 > > --- a/drivers/remoteproc/mtk_common.h > > +++ b/drivers/remoteproc/mtk_common.h > > @@ -55,6 +55,10 @@ > > #define MT8192_CORE0_WDT_IRQ 0x10030 > > #define MT8192_CORE0_WDT_CFG 0x10034 > > > > +#define MT8195_SYS_STATUS 0x4004 > > +#define MT8195_CORE0_WDT BIT(16) > > +#define MT8195_CORE1_WDT BIT(17) > > + > > #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS GENMASK(7, 4) > > > > #define MT8195_CPU1_SRAM_PD 0x1084 > > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c > > index cfcb719ba50b..9fbbc4751433 100644 > > --- a/drivers/remoteproc/mtk_scp.c > > +++ b/drivers/remoteproc/mtk_scp.c > > @@ -222,6 +222,28 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp) > > } > > } > > > > +static void mt8195_scp_irq_handler(struct mtk_scp *scp) > > Looking at the C1 interrupt handler, I don't see any WDT timeout handling, hence > a question naturally arises: > > Would it ever be possible for *both* CORE0 and CORE1 WDT timeout to happen > at the same time? > > Meaning that MT8195_SYS_STATUS has *both* CORE0_WDT and CORE1_WDT bits set when > we reach this interrupt handler? > In that case, the fix would be to just change.... > > > +{ > > + u32 scp_to_host; > > + > > + scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET); > > + > > + if (scp_to_host & MT8192_SCP_IPC_INT_BIT) { > > + scp_ipi_handler(scp); > > + } else { > > + u32 reason = readl(scp->reg_base + MT8195_SYS_STATUS); > > + > > + if (reason & MT8195_CORE1_WDT) > > + writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ); > > + else > > ...the 'else' to another conditional :-) > > Regards, > Angelo > > Yes, it's possible. I overlooked this case. Thanks!
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h index e4ef97f2d3a1..ca2395b98d27 100644 --- a/drivers/remoteproc/mtk_common.h +++ b/drivers/remoteproc/mtk_common.h @@ -55,6 +55,10 @@ #define MT8192_CORE0_WDT_IRQ 0x10030 #define MT8192_CORE0_WDT_CFG 0x10034 +#define MT8195_SYS_STATUS 0x4004 +#define MT8195_CORE0_WDT BIT(16) +#define MT8195_CORE1_WDT BIT(17) + #define MT8195_L1TCM_SRAM_PDN_RESERVED_RSI_BITS GENMASK(7, 4) #define MT8195_CPU1_SRAM_PD 0x1084 diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c index cfcb719ba50b..9fbbc4751433 100644 --- a/drivers/remoteproc/mtk_scp.c +++ b/drivers/remoteproc/mtk_scp.c @@ -222,6 +222,28 @@ static void mt8192_scp_irq_handler(struct mtk_scp *scp) } } +static void mt8195_scp_irq_handler(struct mtk_scp *scp) +{ + u32 scp_to_host; + + scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET); + + if (scp_to_host & MT8192_SCP_IPC_INT_BIT) { + scp_ipi_handler(scp); + } else { + u32 reason = readl(scp->reg_base + MT8195_SYS_STATUS); + + if (reason & MT8195_CORE1_WDT) + writel(1, scp->reg_base + MT8195_CORE1_WDT_IRQ); + else + writel(1, scp->reg_base + MT8192_CORE0_WDT_IRQ); + + scp_wdt_handler(scp, reason); + } + + writel(scp_to_host, scp->reg_base + MT8192_SCP2APMCU_IPC_CLR); +} + static void mt8195_scp_c1_irq_handler(struct mtk_scp *scp) { u32 scp_to_host; @@ -1260,7 +1282,7 @@ static const struct mtk_scp_of_data mt8192_of_data = { static const struct mtk_scp_of_data mt8195_of_data = { .scp_clk_get = mt8195_scp_clk_get, .scp_before_load = mt8195_scp_before_load, - .scp_irq_handler = mt8192_scp_irq_handler, + .scp_irq_handler = mt8195_scp_irq_handler, .scp_reset_assert = mt8192_scp_reset_assert, .scp_reset_deassert = mt8192_scp_reset_deassert, .scp_stop = mt8195_scp_stop,
The MT8195 SCP core 1 watchdog timeout needs to be handled in the SCP core 0 IRQ handler because the MT8195 SCP core 1 watchdog timeout IRQ is wired on the same IRQ entry for core 0 watchdog timeout. MT8195 SCP has a watchdog status register to identify the watchdog timeout source when IRQ triggered. Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com> --- drivers/remoteproc/mtk_common.h | 4 ++++ drivers/remoteproc/mtk_scp.c | 24 +++++++++++++++++++++++- 2 files changed, 27 insertions(+), 1 deletion(-)