Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230113211151.2314874-1-andreas@kemnade.info>
In-Reply-To: <20230113211151.2314874-1-andreas@kemnade.info>
From:   Adam Ford <aford173@gmail.com>
Date:   Mon, 16 Jan 2023 08:16:26 -0600
Message-ID: <CAHCN7xJH+c41Yas+xnWA57KNi9arOOJDxJ=joEDEJr2k6jrRrw@mail.gmail.com>
Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage
To:     Andreas Kemnade <andreas@kemnade.info>
Cc:     bcousson@baylibre.com, tony@atomide.com, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, linux-omap@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        "H. Nikolaus Schaller" <hns@goldelico.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jan 13, 2023 at 3:12 PM Andreas Kemnade <andreas@kemnade.info> wrote:
>
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
>
> OMAP processors support 32 channels but there is no check or
> inspect this except booting a device and looking at dmesg reports
> of not available channels.
>
> Recently some more subsystems with DMA (aes1+2) were added filling
> the list of dma channels beyond the limit of 32 (even if other
> parameters indicate 96 or 128 channels). This leads to random
> subsystem failures i(e.g. mcbsp for audio) after boot or boot
> messages that DMA can not be initialized.
>
> Another symptom is that
>
> /sys/kernel/debug/dmaengine/summary
>
> has 32 entries and does not show all required channels.
>
> Fix by disabling unused (on the GTA04 hardware) mcspi1...4.
> Each SPI channel allocates 4 DMA channels rapidly filling
> the available ones.
>
> Disabling unused SPI modules on the OMAP3 SoC may also save
> some energy (has not been checked).

Tony,

Would it make sense to make this default in the omap3.dtsi file and
enable them in the individual boards that need it?

From what I can tell the following use mcspi1:

logicpd-som-lv.dtsi
logicpd-torpedo-som.dtsi
omap3-evm-common.dtsi
omap3-ldp.dts
omap3-n900.dts
omap3-pandora-common.dtsi
omap3-tao3530.dtsi

The following use mcspi2:
omap3-lilly-a83x.dtsi

mscpi3 is used on:
omap3-tao3530.dtsi

and mcspi4:
omap3-n900.dts

In theory that would save a bunch of boards duplicating the disabled
status if they were to all follow suit.

I was looking into doing something like that for the mmc drivers on
various OMAP3 boards while disabling it on the omap3.dtsi. It seems
like some drivers are disabled by default (dss, ssi, mcbsp)  while
others are enabled by default (i2c, spi, mmc, usb_otg_hs, gpmc,
usbhshost, and a bunch of timers).  Disabling some of these also might
help speed up boot times if less devices need to enumerate.  I am
willing to do some of that work if the idea makes sense.

adam
>
> Fixes: c312f066314e ("ARM: dts: omap3: Migrate AES from hwmods to sysc-omap2")
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> [re-enabled aes2, improved commit subject line]
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 87e0ab1bbe95..e0be0fb23f80 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -612,6 +612,22 @@ &i2c3 {
>         clock-frequency = <100000>;
>  };
>
> +&mcspi1 {
> +       status = "disabled";
> +};
> +
> +&mcspi2 {
> +       status = "disabled";
> +};
> +
> +&mcspi3 {
> +       status = "disabled";
> +};
> +
> +&mcspi4 {
> +       status = "disabled";
> +};
> +
>  &usb_otg_hs {
>         interface-type = <0>;
>         usb-phy = <&usb2_phy>;
> --
> 2.30.2
>