From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 05/12] OMAP: Serial: Hold console lock for console usage.
Date: Fri, 24 Jun 2011 17:06:30 -0700 [thread overview]
Message-ID: <87boxmsrjt.fsf@ti.com> (raw)
In-Reply-To: <1307532194-13039-6-git-send-email-govindraj.raja@ti.com> (Govindraj R.'s message of "Wed, 8 Jun 2011 16:53:07 +0530")
"Govindraj.R" <govindraj.raja@ti•com> writes:
> Acquire console lock before enabling and writing to console-uart
> to avoid any recursive prints from console write.
> for ex:
> --> printk
> --> uart_console_write
> --> get_sync
> --> printk from omap_device enable
> --> uart_console write
>
> Use RPM_SUSPENDING check to avoid below scenario during bootup
> As during bootup console_lock is not available.
> --> uart_add_one_port
> --> console_register
> --> console_lock
> --> console_unlock
> --> call_console_drivers (here yet console_lock is not released)
> --> uart_console_write
>
> Acked-by: Alan Cox <alan@linux•intel.com>
> Signed-off-by: Govindraj.R <govindraj.raja@ti•com>
> ---
> drivers/tty/serial/omap-serial.c | 20 +++++++++++++++++++-
> 1 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 897416f..ee94291 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1008,7 +1008,22 @@ serial_omap_console_write(struct console *co, const char *s,
> struct uart_omap_port *up = serial_omap_console_ports[co->index];
> unsigned long flags;
> unsigned int ier;
> - int locked = 1;
> + int console_lock = 0, locked = 1;
> +
> + if (console_trylock())
> + console_lock = 1;
So now we take the console lock on *every* console write? Even if the
device is not about to be idled? This is rather over-protective, don't
you think?
> + /*
> + * If console_lock is not available and we are in suspending
> + * state then we can avoid the console usage scenario
s/in suspending state/runtime suspending/
> + * as this may introduce recursive prints.
> + * Basically this scenario occurs during boot while
> + * printing debug bootlogs.
The exact scenario for triggering this still not well described, and
thus still I don't get it.
I still don't fully understand this problem, but if it's isolated to
runtime suspending, maybe you need a console lock in the runtime_suspend
path (like you already have in the static suspend path.)
> + */
> +
> + if (!console_lock &&
> + up->pdev->dev.power.runtime_status == RPM_SUSPENDING)
> + return;
Assuming this was a printk, it's now lost, right? Not sure that's an
acceptable solution.
> local_irq_save(flags);
> if (up->port.sysrq)
> @@ -1044,6 +1059,9 @@ serial_omap_console_write(struct console *co, const char *s,
> if (up->msr_saved_flags)
> check_modem_status(up);
>
> + if (console_lock)
> + console_unlock();
> +
> serial_omap_port_disable(up);
> if (locked)
> spin_unlock(&up->port.lock);
Kevin
next prev parent reply other threads:[~2011-06-25 0:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 11:23 [PATCH v3 00/12] OMAP2+: Serial: Runtime adaptation + cleanup Govindraj.R
2011-06-08 11:23 ` [PATCH v3 01/12] OMAP2+: UART: Remove certain uart calls from sram_idle Govindraj.R
2011-06-08 11:23 ` [PATCH v3 02/12] OMAP2+: UART: Remove uart clock handling code from serial.c Govindraj.R
2011-06-24 22:28 ` Kevin Hilman
2011-06-27 12:49 ` Govindraj
2011-06-08 11:23 ` [PATCH v3 03/12] OMAP2+: Serial: Add default mux for all uarts Govindraj.R
2011-06-08 11:23 ` [PATCH v3 04/12] Serial: OMAP: Add runtime pm support for omap-serial driver Govindraj.R
2011-06-08 20:39 ` Jon Hunter
2011-06-09 4:35 ` Govindraj
2011-06-09 20:49 ` Jon Hunter
2011-06-09 20:51 ` Jon Hunter
2011-06-24 23:30 ` Kevin Hilman
2011-06-27 14:31 ` Govindraj
2011-06-27 22:57 ` Kevin Hilman
2011-06-08 11:23 ` [PATCH v3 05/12] OMAP: Serial: Hold console lock for console usage Govindraj.R
2011-06-25 0:06 ` Kevin Hilman [this message]
2011-06-27 13:35 ` Govindraj
2011-06-27 22:41 ` Kevin Hilman
2011-06-08 11:23 ` [PATCH v3 06/12] Serial: OMAP2+: Move erratum handling from serial.c Govindraj.R
2011-06-08 11:23 ` [PATCH v3 07/12] OMAP: Serial: Allow UART parameters to be configured from board file Govindraj.R
2011-06-25 0:12 ` Kevin Hilman
2011-06-27 12:53 ` Govindraj
2011-06-08 11:23 ` [PATCH v3 08/12] Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-06-25 0:16 ` Kevin Hilman
2011-06-08 11:23 ` [PATCH v3 09/12] OMAP3: Serial: Remove uart pads from 3430 board file Govindraj.R
2011-06-24 22:29 ` Kevin Hilman
2011-06-27 12:51 ` Govindraj
2011-06-08 11:23 ` [PATCH v3 10/12] OMAP: Serial: Use resume call from prcm to enable uart Govindraj.R
2011-06-25 0:23 ` Kevin Hilman
2011-06-27 15:03 ` Govindraj
2011-06-08 11:23 ` [PATCH v3 11/12] OMAP2: Serial: Add has_async_wake flag Govindraj.R
2011-06-25 0:29 ` Kevin Hilman
2011-06-27 13:09 ` Govindraj
2011-06-27 22:28 ` Kevin Hilman
2011-06-08 11:23 ` [PATCH v3 12/12] OMAP4: Serial: Set TX_FIFO_THRESHOLD if uart in dma mode for es2.0 Govindraj.R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87boxmsrjt.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox