diff mbox

[RFC,2/2] tty:msm_serial: Do not reset IP if we use bootconsole

Message ID 1402410732-13021-1-git-send-email-srinivas.kandagatla@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Srinivas Kandagatla June 10, 2014, 2:32 p.m. UTC
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(-)

Comments

Srinivas Kandagatla June 10, 2014, 2:37 p.m. UTC | #1
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
Stephen Boyd June 17, 2014, 9:09 p.m. UTC | #2
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?
Srinivas Kandagatla June 17, 2014, 10:04 p.m. UTC | #3
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
Srinivas Kandagatla July 10, 2014, 1:38 p.m. UTC | #4
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 mbox

Patch

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);