All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Govindraj <govindraj.ti@gmail.com>
Cc: "Govindraj.R" <govindraj.raja@ti.com>,
	linux-omap@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Tony Lindgren <tony@atomide.com>,
	Benoit Cousson <b-cousson@ti.com>, Paul Walmsley <paul@pwsan.com>,
	Rajendra Nayak <rnayak@ti.com>
Subject: Re: [PATCH v2 05/12] OMAP: Serial: Hold console lock for console usage.
Date: Thu, 05 May 2011 07:52:03 -0700	[thread overview]
Message-ID: <8762ppmc8c.fsf@ti.com> (raw)
In-Reply-To: <BANLkTi=Ded-q777t=fTc_rcX4=HBq5Bh1g@mail.gmail.com> (Govindraj's message of "Thu, 5 May 2011 15:55:17 +0530")

Govindraj <govindraj.ti@gmail.com> writes:

> On Thu, May 5, 2011 at 2:13 AM, Kevin Hilman <khilman@ti.com> wrote:
>> "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
>>
>> By this time, since the device's runtime PM hooks have been called, the
>> device's rutime PM state should be set to RPM_SUSPENDING (not yet
>> RPM_SUSPENDED).
>>
>> In addition to the console lock, you should be able to use that flag to
>> avoid console writes while the console is in the process of suspending.
>>
>
> Yes RPM_SUSPENDING check helps along with console lock

Great!

> << Changes as below >>
> ---------------
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 59f548f..71964c3 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1040,6 +1040,18 @@ serial_omap_console_write(struct console *co,
> const char *s,
>         if (console_trylock())
>                 console_lock = 1;
>
> +       /*
> +        * If console_lock is not available and we are in suspending
> +        * state then we can avoid the console usage scenario
> +        * as this may introduce recursive prints.
> +        * Basically this scenario occurs during boot while
> +        * printing debug bootlogs.
> +        */
> +
> +       if (!console_lock &&
> +               up->pdev->dev.power.runtime_status == RPM_SUSPENDING)
> +               return;
> +
>         local_irq_save(flags);
>         if (up->port.sysrq)
>                 locked = 0;
>
> ------------
>
> Is it ok to check the RPM_SUSPENDING flag in driver ?
> I can't find any API currently available under runtime.h to use.

I would propose a new API in pm_runtime.h similar to
pm_runtime_suspended() that checks for this.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 05/12] OMAP: Serial: Hold console lock for console usage.
Date: Thu, 05 May 2011 07:52:03 -0700	[thread overview]
Message-ID: <8762ppmc8c.fsf@ti.com> (raw)
In-Reply-To: <BANLkTi=Ded-q777t=fTc_rcX4=HBq5Bh1g@mail.gmail.com> (Govindraj's message of "Thu, 5 May 2011 15:55:17 +0530")

Govindraj <govindraj.ti@gmail.com> writes:

> On Thu, May 5, 2011 at 2:13 AM, Kevin Hilman <khilman@ti.com> wrote:
>> "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
>>
>> By this time, since the device's runtime PM hooks have been called, the
>> device's rutime PM state should be set to RPM_SUSPENDING (not yet
>> RPM_SUSPENDED).
>>
>> In addition to the console lock, you should be able to use that flag to
>> avoid console writes while the console is in the process of suspending.
>>
>
> Yes RPM_SUSPENDING check helps along with console lock

Great!

> << Changes as below >>
> ---------------
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 59f548f..71964c3 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1040,6 +1040,18 @@ serial_omap_console_write(struct console *co,
> const char *s,
>         if (console_trylock())
>                 console_lock = 1;
>
> +       /*
> +        * If console_lock is not available and we are in suspending
> +        * state then we can avoid the console usage scenario
> +        * as this may introduce recursive prints.
> +        * Basically this scenario occurs during boot while
> +        * printing debug bootlogs.
> +        */
> +
> +       if (!console_lock &&
> +               up->pdev->dev.power.runtime_status == RPM_SUSPENDING)
> +               return;
> +
>         local_irq_save(flags);
>         if (up->port.sysrq)
>                 locked = 0;
>
> ------------
>
> Is it ok to check the RPM_SUSPENDING flag in driver ?
> I can't find any API currently available under runtime.h to use.

I would propose a new API in pm_runtime.h similar to
pm_runtime_suspended() that checks for this.

Kevin

  reply	other threads:[~2011-05-05 14:52 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-29 12:39 [PATCH v2 00/12] OMAP2+: Serial: Runtime adaptation + cleanup Govindraj.R
2011-04-29 12:39 ` Govindraj.R
2011-04-29 12:39 ` [PATCH v2 01/12] OMAP2+: UART: Remove certain uart calls from sram_idle Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-04-29 12:39 ` [PATCH v2 02/12] OMAP2+: UART: Remove uart clock handling code from serial.c Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-04-29 13:20   ` Alan Cox
2011-04-29 13:20     ` Alan Cox
2011-04-29 12:39 ` [PATCH v2 03/12] OMAP2+: Serial: Add default mux for all uarts Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-04 10:00   ` Tony Lindgren
2011-05-04 10:00     ` Tony Lindgren
2011-05-04 10:34     ` Govindraj
2011-05-04 10:34       ` Govindraj
2011-04-29 12:39 ` [PATCH v2 04/12] Serial: OMAP: Add runtime pm support for omap-serial driver Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-04 20:35   ` Kevin Hilman
2011-05-04 20:35     ` Kevin Hilman
2011-05-04 21:05     ` Paul Walmsley
2011-05-04 21:05       ` Paul Walmsley
2011-05-05  5:48     ` Raja, Govindraj
2011-05-05  5:48       ` Raja, Govindraj
2011-05-05  5:55     ` Govindraj
2011-05-05  5:55       ` Govindraj
2011-04-29 12:39 ` [PATCH v2 05/12] OMAP: Serial: Hold console lock for console usage Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-04 10:02   ` Tony Lindgren
2011-05-04 10:02     ` Tony Lindgren
2011-05-04 10:09     ` Russell King - ARM Linux
2011-05-04 10:09       ` Russell King - ARM Linux
2011-05-04 10:19     ` Govindraj
2011-05-04 10:19       ` Govindraj
2011-05-04 20:43   ` Kevin Hilman
2011-05-04 20:43     ` Kevin Hilman
2011-05-05 10:25     ` Govindraj
2011-05-05 10:25       ` Govindraj
2011-05-05 14:52       ` Kevin Hilman [this message]
2011-05-05 14:52         ` Kevin Hilman
2011-04-29 12:39 ` [PATCH v2 06/12] Serial: OMAP2+: Move erratum handling from serial.c Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-04-29 12:39 ` [PATCH v2 07/12] OMAP: Serial: Allow UART parameters to be configured from board file Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-04  9:55   ` Tony Lindgren
2011-05-04  9:55     ` Tony Lindgren
2011-05-04 10:06     ` Govindraj
2011-05-04 10:06       ` Govindraj
2011-05-04 10:25       ` Tony Lindgren
2011-05-04 10:25         ` Tony Lindgren
2011-05-04 10:39         ` Govindraj
2011-05-04 10:39           ` Govindraj
2011-04-29 12:39 ` [PATCH v2 08/12] Serial: OMAP2+: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-04-29 12:39 ` [PATCH v2 09/12] OMAP3: Serial: Remove uart pads from 3430 board file Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-04-29 12:39 ` [PATCH v2 10/12] OMAP2+: hwmod: Add api to enable io_ring wakeup Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-04 23:59   ` Kevin Hilman
2011-05-04 23:59     ` Kevin Hilman
2011-05-05  5:58     ` Govindraj
2011-05-05  5:58       ` Govindraj
2011-04-29 12:39 ` [PATCH v2 11/12] OMAP: Serial: Use resume call from prcm to enable uart Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-05  0:11   ` Kevin Hilman
2011-05-05  0:11     ` Kevin Hilman
2011-05-05 11:46     ` Govindraj
2011-05-05 11:46       ` Govindraj
2011-05-05 14:58       ` Kevin Hilman
2011-05-05 14:58         ` Kevin Hilman
2011-05-06  9:16         ` Govindraj
2011-05-06  9:16           ` Govindraj
2011-05-06 15:55           ` Kevin Hilman
2011-05-06 15:55             ` Kevin Hilman
2011-05-09 12:23             ` Govindraj
2011-05-09 12:23               ` Govindraj
2011-04-29 12:39 ` [PATCH v2 12/12] OMAP2: Serial: Add no async wake flag Govindraj.R
2011-04-29 12:39   ` Govindraj.R
2011-05-05 17:32   ` Kevin Hilman
2011-05-05 17:32     ` Kevin Hilman
2011-05-06  9:34     ` Govindraj
2011-05-06  9:34       ` Govindraj

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=8762ppmc8c.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=b-cousson@ti.com \
    --cc=govindraj.raja@ti.com \
    --cc=govindraj.ti@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=rnayak@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.