]> git.baikalelectronics.ru Git - kernel.git/commit
soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1
authorTony Lindgren <tony@atomide.com>
Tue, 8 Dec 2020 14:08:02 +0000 (16:08 +0200)
committerTony Lindgren <tony@atomide.com>
Wed, 30 Dec 2020 08:47:26 +0000 (10:47 +0200)
commit302d051fb16f82d66408d0be0da8dc78bfd030d0
tree47e7b2fa4a497406895b612731b33cf1d927f653
parent8918423530d8e117b22e902a5c25845adf4ec5b7
soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1

We have rst_map_012 used for various accelerators like dsp, ipu and iva.
For these use cases, we have rstctrl bit 2 control the subsystem module
reset, and have and bits 0 and 1 control the accelerator specific
features.

If the bootloader, or kexec boot, has left any accelerator specific
reset bits deasserted, deasserting bit 2 reset will potentially enable
an accelerator with unconfigured MMU and no firmware. And we may get
spammed with a lot by warnings on boot with "Data Access in User mode
during Functional access", or depending on the accelerator, the system
can also just hang.

This issue can be quite easily reproduced by setting a rst_map_012 type
rstctrl register to 0 or 4 in the bootloader, and booting the system.

Let's just assert all reset bits for rst_map_012 type resets. So far
it looks like the other rstctrl types don't need this. If it turns out
that the other type rstctrl bits also need reset on init, we need to
add an instance specific reset mask for the bits to avoid resetting
unwanted bits.

Reported-by: Carl Philipp Klemm <philipp@uvos.xyz>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Suman Anna <s-anna@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Carl Philipp Klemm <philipp@uvos.xyz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
drivers/soc/ti/omap_prm.c