ram: k3-ddrss: drop debug() in timing-sensitive sequence
Those debug() calls might be useful, but beware. They can cause the DDR
controller to hang if we do not run the sequence quickly enough.
They usually are not an issue with upstream U-Boot and the default DDR
config, but they have become troublesome with custom DDR configs.
Drop those debug() statements that shouldn't be present in
time-sensitive code, to avoid anyone else falling into the trap.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index 525b6d5..6e9202b 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -216,9 +216,6 @@
req_type = readl(ddrss->ddrss_ctrl_mmr +
CTRLMMR_DDR4_FSP_CLKCHNG_REQ_OFFS + ddrss->instance * 0x10) & 0x03;
- debug("%s: received freq change req: req type = %d, req no. = %d, instance = %d\n",
- __func__, req_type, counter, ddrss->instance);
-
if (req_type == 1)
clk_set_rate(&ddrss->ddr_clk, ddrss->ddr_freq1);
else if (req_type == 2)
@@ -245,8 +242,6 @@
{
struct k3_ddrss_desc *ddrss = (struct k3_ddrss_desc *)pd->ddr_instance;
- debug("--->>> LPDDR4 Initialization is in progress ... <<<---\n");
-
switch (ddrss->dram_class) {
case DENALI_CTL_0_DRAM_CLASS_DDR4:
break;