ARM: dts: gta04: fix excess dma channel usage
authorH. Nikolaus Schaller <hns@goldelico.com>
Fri, 13 Jan 2023 21:11:51 +0000 (22:11 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 11 May 2023 14:03:11 +0000 (23:03 +0900)
commitda3babe96be764c7996c08a5624e4b650356825e
tree8ab38869508f2d765f8585a2a2d3762cfe83d6ad
parentfd67875ebaeae8bbee142f30a2b88a174f989929
ARM: dts: gta04: fix excess dma channel usage

[ Upstream commit a622310f7f0185da02e42cdb06475f533efaae60 ]

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).

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>
Message-Id: <20230113211151.2314874-1-andreas@kemnade.info>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/arm/boot/dts/omap3-gta04.dtsi