Skip to content

Commit f6e6f0c

Browse files
tmlindgregkh
authored andcommitted
serial: 8250: omap: Fix idling of clocks for unused uarts
commit 13dc04d upstream. I noticed that unused UARTs won't necessarily idle properly always unless at least one byte tx transfer is done first. After some debugging I narrowed down the problem to the scr register dma configuration bits that need to be set before softreset for the clocks to idle. Unless we do this, the module clkctrl idlest bits may be set to 1 instead of 3 meaning the clock will never idle and is blocking deeper idle states for the whole domain. This might be related to the configuration done by the bootloader or kexec booting where certain configurations cause the 8250 or the clkctrl clock to jam in a way where setting of the scr bits and reset is needed to clear it. I've tried diffing the 8250 registers for the various modes, but did not see anything specific. So far I've only seen this on omap4 but I'm suspecting this might also happen on the other clkctrl using SoCs considering they already have a quirk enabled for UART_ERRATA_CLOCK_DISABLE. Let's fix the issue by configuring scr before reset for basic dma even if we don't use it. The scr register will be reset when we do softreset few lines after, and we restore scr on resume. We should do this for all the SoCs with UART_ERRATA_CLOCK_DISABLE quirk flag set since the ones with UART_ERRATA_CLOCK_DISABLE are all based using clkctrl similar to omap4. Looks like both OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL bits are needed for the clkctrl to idle after a softreset. And we need to add omap4 to also use the UART_ERRATA_CLOCK_DISABLE for the related workaround to be enabled. This same compatible value will also be used for omap5. Fixes: cdb929e ("serial: 8250_omap: workaround errata around idling UART after using DMA") Cc: Keerthy <j-keerthy@ti.com> Cc: Matthijs van Duin <matthijsvanduin@gmail.com> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 parent 5b91ae5 commit f6e6f0c

1 file changed

Lines changed: 15 additions & 1 deletion

File tree

drivers/tty/serial/8250/8250_omap.c

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1078,13 +1078,14 @@ static int omap8250_no_handle_irq(struct uart_port *port)
10781078
return 0;
10791079
}
10801080

1081+
static const u8 omap4_habit = UART_ERRATA_CLOCK_DISABLE;
10811082
static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
10821083
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
10831084

10841085
static const struct of_device_id omap8250_dt_ids[] = {
10851086
{ .compatible = "ti,omap2-uart" },
10861087
{ .compatible = "ti,omap3-uart" },
1087-
{ .compatible = "ti,omap4-uart" },
1088+
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
10881089
{ .compatible = "ti,am3352-uart", .data = &am3352_habit, },
10891090
{ .compatible = "ti,am4372-uart", .data = &am3352_habit, },
10901091
{ .compatible = "ti,dra742-uart", .data = &dra742_habit, },
@@ -1326,6 +1327,19 @@ static int omap8250_soft_reset(struct device *dev)
13261327
int sysc;
13271328
int syss;
13281329

1330+
/*
1331+
* At least on omap4, unused uarts may not idle after reset without
1332+
* a basic scr dma configuration even with no dma in use. The
1333+
* module clkctrl status bits will be 1 instead of 3 blocking idle
1334+
* for the whole clockdomain. The softreset below will clear scr,
1335+
* and we restore it on resume so this is safe to do on all SoCs
1336+
* needing omap8250_soft_reset() quirk. Do it in two writes as
1337+
* recommended in the comment for omap8250_update_scr().
1338+
*/
1339+
serial_out(up, UART_OMAP_SCR, OMAP_UART_SCR_DMAMODE_1);
1340+
serial_out(up, UART_OMAP_SCR,
1341+
OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL);
1342+
13291343
sysc = serial_in(up, UART_OMAP_SYSC);
13301344

13311345
/* softreset the UART */

0 commit comments

Comments
 (0)