| Message ID | 1402410732-13021-1-git-send-email-srinivas.kandagatla@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10/06/14 15:32, Srinivas Kandagatla wrote: > + * do not reset if we are the boot console > + * can result in a lockup from bootconsole > + */ > + if (have_boot_console()) > + msm_reset(port); Oops.. I think I sent a wrong changeset I this patch... this should be. if (!have_boot_console()) msm_reset(port); Will fix it in next version.. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/10/14 07:32, Srinivas Kandagatla wrote: > The use case is when we boot the platform with bootconsole enabled. What > I noticed is that the console gets locked sometimes up before the bootconsole > is disabled. > > As part of console setup in serial driver it resets that hardware which > is a race condition to bootconsole using the same hardware. This > patch adds a check to see if there is bootconsole before reseting the hardware. > > Am sure there are better ways to solve this, so marking this patch as > RFC. Any suggestions are welcome. > > Isn't there some way to check and wait for the hardware to be unused before we reset it? I recall being able to overcome this "race condition" by removing the printks in the serial driver setup. Does that work for you?
On 17/06/14 22:09, Stephen Boyd wrote: > On 06/10/14 07:32, Srinivas Kandagatla wrote: >> The use case is when we boot the platform with bootconsole enabled. What >> I noticed is that the console gets locked sometimes up before the bootconsole >> is disabled. >> >> As part of console setup in serial driver it resets that hardware which >> is a race condition to bootconsole using the same hardware. This >> patch adds a check to see if there is bootconsole before reseting the hardware. >> >> Am sure there are better ways to solve this, so marking this patch as >> RFC. Any suggestions are welcome. >> >> > > Isn't there some way to check and wait for the hardware to be unused > before we reset it? > > I recall being able to overcome this "race condition" by removing the > printks in the serial driver setup. Does that work for you? > Good point, Its possible that removing prints during the transition fixes the issue. I will give it a try. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stephen, Did bit more testing on this. I could not reproduce this issue (across 40+ reboots) once I removed some of my debug, so we can ignore this patch for now, But we still need gsbi patch for clock. Thanks, srini On 17/06/14 22:09, Stephen Boyd wrote: > On 06/10/14 07:32, Srinivas Kandagatla wrote: >> The use case is when we boot the platform with bootconsole enabled. What >> I noticed is that the console gets locked sometimes up before the bootconsole >> is disabled. >> >> As part of console setup in serial driver it resets that hardware which >> is a race condition to bootconsole using the same hardware. This >> patch adds a check to see if there is bootconsole before reseting the hardware. >> >> Am sure there are better ways to solve this, so marking this patch as >> RFC. Any suggestions are welcome. >> >> > > Isn't there some way to check and wait for the hardware to be unused > before we reset it? > > I recall being able to overcome this "race condition" by removing the > printks in the serial driver setup. Does that work for you? > -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c index 778e376..7078153 100644 --- a/drivers/tty/serial/msm_serial.c +++ b/drivers/tty/serial/msm_serial.c @@ -913,6 +913,17 @@ static void msm_console_write(struct console *co, const char *s, spin_unlock(&port->lock); } +static int have_boot_console(void) +{ + struct console *con; + + for_each_console(con) + if (con->flags & CON_BOOT) + return 1; + + return 0; +} + static int __init msm_console_setup(struct console *co, char *options) { struct uart_port *port; @@ -943,7 +954,12 @@ static int __init msm_console_setup(struct console *co, char *options) baud = 115200; msm_set_baud_rate(port, baud); - msm_reset(port); + /* + * do not reset if we are the boot console + * can result in a lockup from bootconsole + */ + if (have_boot_console()) + msm_reset(port); if (msm_port->is_uartdm) { msm_write(port, UART_CR_CMD_PROTECTION_EN, UART_CR);
The use case is when we boot the platform with bootconsole enabled. What I noticed is that the console gets locked sometimes up before the bootconsole is disabled. As part of console setup in serial driver it resets that hardware which is a race condition to bootconsole using the same hardware. This patch adds a check to see if there is bootconsole before reseting the hardware. Am sure there are better ways to solve this, so marking this patch as RFC. Any suggestions are welcome. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> --- drivers/tty/serial/msm_serial.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)