Patch "soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1" has been added to the 5.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     soc-ti-omap-prm-fix-boot-time-errors-for-rst_map_012.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 603effe7cbcc8ba82f1600b96599284944e35022
Author: Tony Lindgren <tony@xxxxxxxxxxx>
Date:   Tue Dec 8 16:08:02 2020 +0200

    soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1
    
    [ Upstream commit 7078a5ba7a58e5db07583b176f8a03e0b8714731 ]
    
    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@xxxxxxxx>
    Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
    Cc: Santosh Shilimkar <ssantosh@xxxxxxxxxx>
    Cc: Suman Anna <s-anna@xxxxxx>
    Cc: Tero Kristo <t-kristo@xxxxxx>
    Tested-by: Carl Philipp Klemm <philipp@xxxxxxxx>
    Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 4d41dc3cdce1f..c8b14b3a171f7 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -552,6 +552,7 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 	const struct omap_rst_map *map;
 	struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
 	char buf[32];
+	u32 v;
 
 	/*
 	 * Check if we have controllable resets. If either rstctrl is non-zero
@@ -599,6 +600,16 @@ static int omap_prm_reset_init(struct platform_device *pdev,
 		map++;
 	}
 
+	/* Quirk handling to assert rst_map_012 bits on reset and avoid errors */
+	if (prm->data->rstmap == rst_map_012) {
+		v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
+		if ((v & reset->mask) != reset->mask) {
+			dev_dbg(&pdev->dev, "Asserting all resets: %08x\n", v);
+			writel_relaxed(reset->mask, reset->prm->base +
+				       reset->prm->data->rstctrl);
+		}
+	}
+
 	return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
 }
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux