From: Adam Ford <aford173@gmail.com>
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>
Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage
Date: Mon, 16 Jan 2023 08:16:26 -0600 [thread overview]
Message-ID: <CAHCN7xJH+c41Yas+xnWA57KNi9arOOJDxJ=joEDEJr2k6jrRrw@mail.gmail.com> (raw)
In-Reply-To: <20230113211151.2314874-1-andreas@kemnade.info>
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
>
next prev parent reply other threads:[~2023-01-16 14:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 21:11 [PATCH] ARM: dts: gta04: fix excess dma channel usage Andreas Kemnade
2023-01-16 14:16 ` Adam Ford [this message]
2023-01-16 14:51 ` Tony Lindgren
2023-01-16 15:29 ` H. Nikolaus Schaller
2023-01-16 17:00 ` Tony Lindgren
2023-01-16 16:39 ` Andreas Kemnade
2023-01-16 16:56 ` Tony Lindgren
2023-01-16 17:00 ` Adam Ford
2023-01-16 17:08 ` Tony Lindgren
2023-01-19 7:30 ` Tony Lindgren
2023-01-22 9:08 ` Andreas Kemnade
2024-11-07 9:35 ` Andreas Kemnade
2023-03-27 8:13 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHCN7xJH+c41Yas+xnWA57KNi9arOOJDxJ=joEDEJr2k6jrRrw@mail.gmail.com' \
--to=aford173@gmail.com \
--cc=andreas@kemnade.info \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=hns@goldelico.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).