Re: [PATCH 1/9] arm64: dts: qcom: sc7180: Make watchdog bark interrupt edge triggered
On Fri, Nov 03, 2023 at 04:34:27PM -0700, Douglas Anderson wrote:
> On sc7180 when the watchdog timer fires your logs get filled with:
> watchdog0: pretimeout event
> watchdog0: pretimeout event
> watchdog0: pretimeout event
> ...
> watchdog0: pretimeout event
>
> If you're using console-ramoops to debug crashes the above gets quite
> annoying since it blows away any other log messages that might have
> been there.
>
> The issue is that the "bark" interrupt (AKA the "pretimeout"
> interrupt) remains high until the watchdog is pet. Since we've got
> things configured as "level" triggered we'll keep getting interrupted
> over and over.
>
> Let's switch to edge triggered. Now we'll get one interrupt when the
> "bark" interrupt goes off we'll get one interrupt and won't get
> another one until the "bark" interrupt is cleared and asserts again.
>
> This matches how many older Qualcomm SoCs have things configured.
>
> Fixes: 28cc13e4060c ("arm64: dts: qcom: sc7180: Add watchdog bark interrupt")
> Signed-off-by: Douglas Anderson
Reviewed-by: Guenter Roeck
> ---
>
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 11f353d416b4..c0365832c315 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -3576,7 +3576,7 @@ watchdog@17c1 {
> compatible = "qcom,apss-wdt-sc7180", "qcom,kpss-wdt";
> reg = <0 0x17c1 0 0x1000>;
> clocks = <_clk>;
> - interrupts = ;
> + interrupts = ;
> };
>
> timer@17c2 {
> --
> 2.42.0.869.gea05f2083d-goog
>
[PATCH 1/9] arm64: dts: qcom: sc7180: Make watchdog bark interrupt edge triggered
On sc7180 when the watchdog timer fires your logs get filled with:
watchdog0: pretimeout event
watchdog0: pretimeout event
watchdog0: pretimeout event
...
watchdog0: pretimeout event
If you're using console-ramoops to debug crashes the above gets quite
annoying since it blows away any other log messages that might have
been there.
The issue is that the "bark" interrupt (AKA the "pretimeout"
interrupt) remains high until the watchdog is pet. Since we've got
things configured as "level" triggered we'll keep getting interrupted
over and over.
Let's switch to edge triggered. Now we'll get one interrupt when the
"bark" interrupt goes off we'll get one interrupt and won't get
another one until the "bark" interrupt is cleared and asserts again.
This matches how many older Qualcomm SoCs have things configured.
Fixes: 28cc13e4060c ("arm64: dts: qcom: sc7180: Add watchdog bark interrupt")
Signed-off-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 11f353d416b4..c0365832c315 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -3576,7 +3576,7 @@ watchdog@17c1 {
compatible = "qcom,apss-wdt-sc7180", "qcom,kpss-wdt";
reg = <0 0x17c1 0 0x1000>;
clocks = <_clk>;
- interrupts = ;
+ interrupts = ;
};
timer@17c2 {
--
2.42.0.869.gea05f2083d-goog
Re: [PATCH v7 08/10] arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
On 2023-11-03 5:02 pm, Duje Mihanović wrote: On Friday, November 3, 2023 4:34:54 PM CET Robin Murphy wrote: On 2023-11-02 3:20 pm, Duje Mihanović wrote: +config ARCH_MMP + bool "Marvell MMP SoC Family" + select ARM_GIC + select ARM_ARCH_TIMER + select ARM_SMMU NAK, not only is selecting user-visible symbols generally frowned upon, and ignoring their dependencies even worse, but for a multiplatform kernel the user may well want this to be a module. If having the SMMU driver built-in is somehow fundamentally required for this platform to boot, that would represent much bigger problems. The SoC can boot without SMMU and PDMA, but not GIC, pinctrl or the arch timer. I see that most other SoCs still select drivers and frameworks they presumably need for booting, with the exceptions of ARCH_BITMAIN, ARCH_LG1K and a couple others. Which of these two options should I go for? Well, you don't really need to select ARM_GIC or ARM_ARCH_TIMER here either, since those are already selected by ARM64 itself. Keeping PINCTRL_SINGLE is fair, although you should also select PINCTRL as its dependency. As an additional nit, the file seems to be primarily ordered by symbol name, so it might be nice to slip ARCH_MMC in between ARCH_MESON and ARCH_MVEBU. Cheers, Robin.
Re: [PATCH v7 08/10] arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
On Friday, November 3, 2023 4:34:54 PM CET Robin Murphy wrote: > On 2023-11-02 3:20 pm, Duje Mihanović wrote: > > +config ARCH_MMP > > + bool "Marvell MMP SoC Family" > > + select ARM_GIC > > + select ARM_ARCH_TIMER > > + select ARM_SMMU > > NAK, not only is selecting user-visible symbols generally frowned upon, > and ignoring their dependencies even worse, but for a multiplatform > kernel the user may well want this to be a module. > > If having the SMMU driver built-in is somehow fundamentally required for > this platform to boot, that would represent much bigger problems. The SoC can boot without SMMU and PDMA, but not GIC, pinctrl or the arch timer. I see that most other SoCs still select drivers and frameworks they presumably need for booting, with the exceptions of ARCH_BITMAIN, ARCH_LG1K and a couple others. Which of these two options should I go for? Regards, Duje
Re: [PATCH v7 06/10] ASoC: pxa: Suppress SSPA on ARM64
On Friday, November 3, 2023 4:23:28 PM CET Robin Murphy wrote: > On 2023-11-02 3:26 pm, Mark Brown wrote: > > This isn't a fix for the existing code, AFAICT the issue here is that > > ARCH_MMP is currently only available for arm and presumably something in > > the rest of your series makes it available for arm64. This would be a > > prerequisite for that patch. > > > > Please don't just insert random fixes tags just because you can. > > FWIW it doesn't even seem to be the right reason either. AFACIT the > issue being introduced is that SND_MMP_SOC_SSPA selects SND_ARM which > depends on ARM, but after patch #8 ARCH_MMP itself will no longer > necessarily imply ARM. The fact that selecting SND_ARM with unmet > dependencies also allows SND_ARMAACI to be enabled (which appears to be > the only thing actually containing open-coded Arm asm) is tangential. I just looked at it again and it looks like no code in sound/soc/pxa/* or sound/arm/pxa* depends on AACI in any way. Therefore, I believe that to fix this correctly, I would have to remove "select SND_ARM" from sound/soc/pxa/ Kconfig and optionally move the PXA2xx code out of sound/arm/ and into sound/ soc/pxa/. Is this correct? If so, I'd also split that fix into a separate series. Regards, Duje
Re: [PATCH v7 08/10] arm64: Kconfig.platforms: Add config for Marvell PXA1908 platform
On 2023-11-02 3:20 pm, Duje Mihanović wrote: Add ARCH_MMP configuration option for Marvell PXA1908 SoC. Signed-off-by: Duje Mihanović --- arch/arm64/Kconfig.platforms | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 6069120199bb..b417cae42c84 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -89,6 +89,17 @@ config ARCH_BERLIN help This enables support for Marvell Berlin SoC Family +config ARCH_MMP + bool "Marvell MMP SoC Family" + select ARM_GIC + select ARM_ARCH_TIMER + select ARM_SMMU NAK, not only is selecting user-visible symbols generally frowned upon, and ignoring their dependencies even worse, but for a multiplatform kernel the user may well want this to be a module. If having the SMMU driver built-in is somehow fundamentally required for this platform to boot, that would represent much bigger problems. Thanks, Robin. + select MMP_PDMA + select PINCTRL_SINGLE + help + This enables support for Marvell MMP SoC family, currently + supporting PXA1908 aka IAP140. + config ARCH_BITMAIN bool "Bitmain SoC Platforms" help
Re: [PATCH v7 06/10] ASoC: pxa: Suppress SSPA on ARM64
On 2023-11-02 3:26 pm, Mark Brown wrote:
On Thu, Nov 02, 2023 at 04:20:29PM +0100, Duje Mihanović wrote:
The SSPA driver currently seems to generate ARM32 assembly, which causes
build errors when building a kernel for an ARM64 ARCH_MMP platform.
Fixes: fa375d42f0e5 ("ASoC: mmp: add sspa support")
Reported-by: kernel test robot
tristate "SoC Audio via MMP SSPA ports"
- depends on ARCH_MMP
+ depends on ARCH_MMP && ARM
This isn't a fix for the existing code, AFAICT the issue here is that
ARCH_MMP is currently only available for arm and presumably something in
the rest of your series makes it available for arm64. This would be a
prerequisite for that patch.
Please don't just insert random fixes tags just because you can.
FWIW it doesn't even seem to be the right reason either. AFACIT the
issue being introduced is that SND_MMP_SOC_SSPA selects SND_ARM which
depends on ARM, but after patch #8 ARCH_MMP itself will no longer
necessarily imply ARM. The fact that selecting SND_ARM with unmet
dependencies also allows SND_ARMAACI to be enabled (which appears to be
the only thing actually containing open-coded Arm asm) is tangential.
Robin.
