From: rnayak@ti•com (Rajendra Nayak)
To: linux-arm-kernel@lists•infradead.org
Subject: Boot hang regression 3.10.0-rc4 -> 3.10.0
Date: Thu, 11 Jul 2013 11:48:39 +0530 [thread overview]
Message-ID: <51DE4E3F.6030503@ti.com> (raw)
In-Reply-To: <20130710142633.GV5523@atomide.com>
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> * Kevin Hilman <khilman@linaro•org> [130710 01:29]:
>> Felipe Balbi <balbi@ti•com> writes:
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>>
>>> Am I missing something ?
>>
>> You're right, the _set_active() is crucial in the case when we prevent
>> the console UART from idling during boot (though that shouldn't be
>> happening in mainline unless the fix for "Issue 1" is done.)
>
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
>
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me.
On what platform? Like I said there are flags set statically in hmwod
data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
in mach-omap2/serial.c. But it won't work for am33xx.
We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
>
> Regards,
>
> Tony
>
>
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
> u32 calc_latency;
> struct work_struct qos_work;
> struct pinctrl *pins;
> + bool initialized;
> bool is_suspending;
> };
>
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>
> pm_runtime_mark_last_busy(up->dev);
> pm_runtime_put_autosuspend(up->dev);
> + up->initialized = true;
This won't help as the context save for serial happens as part of set_termios() and not
when the device is probed.
> +
> return 0;
>
> err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
> #ifdef CONFIG_PM_RUNTIME
> static void serial_omap_restore_context(struct uart_omap_port *up)
> {
> + if (!up->initialized)
> + return;
> +
> if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
> serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
> else
>
next prev parent reply other threads:[~2013-07-11 6:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 13:25 Boot hang regression 3.10.0-rc4 -> 3.10.0 Mark Jackson
2013-07-04 15:14 ` Mark Jackson
2013-07-04 16:00 ` Mark Jackson
2013-07-05 8:11 ` Bedia, Vaibhav
2013-07-05 11:59 ` Tony Lindgren
2013-07-05 13:20 ` Bedia, Vaibhav
2013-07-05 13:31 ` Bedia, Vaibhav
2013-07-08 11:25 ` Tony Lindgren
2013-07-08 12:16 ` Tony Lindgren
2013-07-08 12:41 ` Rajendra Nayak
2013-07-08 13:10 ` Tony Lindgren
2013-07-08 13:20 ` Rajendra Nayak
2013-07-08 13:25 ` Rajendra Nayak
2013-07-08 13:35 ` Felipe Balbi
2013-07-09 5:33 ` Rajendra Nayak
2013-07-09 6:42 ` Felipe Balbi
2013-07-09 7:19 ` Rajendra Nayak
2013-07-09 7:40 ` Felipe Balbi
2013-07-09 18:59 ` Grygorii Strashko
2013-07-09 19:41 ` Felipe Balbi
2013-07-10 12:16 ` Grygorii Strashko
2013-07-10 12:25 ` Felipe Balbi
2013-07-10 8:22 ` Kevin Hilman
2013-07-10 12:10 ` Tony Lindgren
2013-07-10 12:27 ` Tony Lindgren
2013-07-10 14:26 ` Tony Lindgren
2013-07-10 16:07 ` Felipe Balbi
2013-07-10 16:11 ` Felipe Balbi
2013-07-11 6:32 ` Tony Lindgren
2013-07-11 9:59 ` Grygorii Strashko
2013-07-12 0:40 ` Suman Anna
2013-07-15 6:44 ` Rajendra Nayak
2013-07-15 10:01 ` Rajendra Nayak
2013-07-15 19:23 ` Suman Anna
2013-07-16 6:30 ` Rajendra Nayak
2013-07-11 9:17 ` Rajendra Nayak
2013-07-11 9:26 ` Felipe Balbi
2013-07-11 10:16 ` [PATCH] arm: omap2plus: unidle devices which are about to probe Felipe Balbi
2013-07-12 11:58 ` Grygorii Strashko
2013-07-12 12:10 ` Felipe Balbi
2013-07-12 12:27 ` Rajendra Nayak
2013-07-13 22:21 ` Kevin Hilman
2013-07-11 9:59 ` Boot hang regression 3.10.0-rc4 -> 3.10.0 Grygorii Strashko
2013-07-16 10:27 ` Grygorii Strashko
2013-07-17 7:10 ` Rajendra Nayak
2013-07-11 6:18 ` Rajendra Nayak [this message]
2013-07-11 6:24 ` Tony Lindgren
2013-07-11 9:11 ` Rajendra Nayak
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=51DE4E3F.6030503@ti.com \
--to=rnayak@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