From: NeilBrown <neilb@suse.de>
To: Kevin Hilman <khilman@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Paul Walmsley <paul@pwsan.com>,
t-kristo@ti.com, govindraj.r@ti.com, linux-omap@vger.kernel.org
Subject: Re: DSS2/PM on 3.2 broken?
Date: Fri, 20 Jan 2012 08:05:08 +1100 [thread overview]
Message-ID: <20120120080508.0dc0c758@notabene.brown> (raw)
In-Reply-To: <87y5t3trek.fsf@ti.com>
[-- Attachment #1: Type: text/plain, Size: 10803 bytes --]
On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman <khilman@ti.com> wrote:
> "Joe Woodward" <jw@terrafix.co.uk> writes:
>
> [...]
>
> > If I do (either from the console or via a button press on the screen)
> > then I never get a SYNC_LOST.
> >
> > echo 0 > /sys/devices/omapdss/display0/enabled
> > echo 1 > /sys/devices/omapdss/display0/enabled
> >
> > Just trying to think of some ideas that may be affecting the DSS...
> > - Could it to be to do with the GPIO being used as a wake source (i.e. does the GPIO driver do runtime_pm properly?)?
> > - Could it to be to do with the UART as it seems to fix itself whenever a character is pressed?
> > - Could it to be to do with the ordering in which drivers are resumed?
>
> Here's my guess/hunch as to why the UART wakeup helps and GPIO doesn't.
>
> The UART's are idled using timeouts, so after any activity (including a
> wakeup) the UART timeout will not alow the UARTs to idle (and thus the
> system to hit low power states) for a given timeout period.
While I agree with that, I'm wondering if there might be something else odd
relating to the UARTs that we haven't spotted yet.
I'm chasing done the different problem of HDQ not coping with CPUIDLE but I
think it is very likely to have a similar root cause, as HDQ goes wrong at
the same time that DSS goes wrong, and is a vaguely similar way.
I just tried compiling omap_hwmod.c with "#define DEBUG" and got some strange
results.
Firstly: something strange early in boot. Here is an annotated extract from
the dmesg log:
[ 0.862304] omap_hwmod: l4_wkup: enabling
[ 0.866546] omap_hwmod: l4_wkup: enabling clocks
[ 0.871429] omap_hwmod: l4_wkup: resetting
[ 0.875732] omap_hwmod: l4_wkup: idling
[ 0.879791] omap_hwmod: l4_wkup: disabling clocks
[ 0.884765] omap_hwmod: mmc3: enabling
[ 0.888702] omap_hwmod: mmc3: enabling clocks
[ 0.893341] omap_hwmod: mmc3: resetting
[ 0.897430] omap_hwmod: mmc3: resetting via OCP SOFTRESET
[ 0.903106] omap_hwmod: mmc3: softreset in 0 usec
[ 0.908050] omap_hwmod: mmc3: idling
[ 0.911834] omap_hwmod: mmc3: disabling clocks
At this point my serial console (UART3, 19200bps) start emitting nuls rather than what
it should, so I don't see the next few lines.
154 nuls instread of 91 characters.
[ 0.916534] omap_hwmod: hdq: enabling
[ 0.944793] omap_hwmod: hdq: enabling clocks
Then normal text resumes for a short while:
[ 0.977691] omap_hwmod: hdq: resetting
[ 0.981658] omap_hwmod: hdq: resetting via OCP SOFTRESET
[ 0.998413] omap_hwmod: hdq: softreset failed (waited 10000 usec)
[ 1.004791] omap_hwmod: hdq: idling
[ 1.008483] omap_hwmod: hdq: disabling clocks
Here again we switch to all nuls.
7959 nuls instead of 4701 characters.
[ 1.013092] omap_hwmod: timer1: enabling
[ 1.043334] omap_hwmod: timer1: enabling clocks
[ 1.078155] omap_hwmod: timer1: resetting
[ 1.109008] omap_hwmod: timer1: resetting via OCP SOFTRESET
[ 1.151702] omap_hwmod: timer1: softreset in 0 usec
[ 1.189147] omap_hwmod: timer1: idling
[ 1.218048] omap_hwmod: timer1: disabling clocks
[ 1.253540] omap_hwmod: timer2: enabling
[ 1.283752] omap_hwmod: timer2: enabling clocks
[ 1.318572] omap_hwmod: timer2: resetting
[ 1.349456] omap_hwmod: timer2: resetting via OCP SOFTRESET
[ 1.392150] omap_hwmod: timer2: softreset in 0 usec
[ 1.429565] omap_hwmod: timer2: idling
[ 1.458496] omap_hwmod: timer2: disabling clocks
[ 1.493957] omap_hwmod: timer3: enabling
[ 1.524169] omap_hwmod: timer3: enabling clocks
[ 1.558990] omap_hwmod: timer3: resetting
[ 1.589874] omap_hwmod: timer3: resetting via OCP SOFTRESET
[ 1.632568] omap_hwmod: timer3: softreset in 0 usec
[ 1.669982] omap_hwmod: timer3: idling
[ 1.698913] omap_hwmod: timer3: disabling clocks
[ 1.734374] omap_hwmod: timer4: enabling
[ 1.764617] omap_hwmod: timer4: enabling clocks
[ 1.799438] omap_hwmod: timer4: resetting
[ 1.830291] omap_hwmod: timer4: resetting via OCP SOFTRESET
[ 1.872985] omap_hwmod: timer4: softreset in 0 usec
[ 1.910430] omap_hwmod: timer4: idling
[ 1.939331] omap_hwmod: timer4: disabling clocks
[ 1.974822] omap_hwmod: timer5: enabling
[ 2.005035] omap_hwmod: timer5: enabling clocks
[ 2.039855] omap_hwmod: timer5: resetting
[ 2.070739] omap_hwmod: timer5: resetting via OCP SOFTRESET
[ 2.113403] omap_hwmod: timer5: softreset in 0 usec
[ 2.150848] omap_hwmod: timer5: idling
[ 2.179748] omap_hwmod: timer5: disabling clocks
[ 2.215270] omap_hwmod: timer6: enabling
[ 2.245483] omap_hwmod: timer6: enabling clocks
[ 2.280303] omap_hwmod: timer6: resetting
[ 2.311157] omap_hwmod: timer6: resetting via OCP SOFTRESET
[ 2.353851] omap_hwmod: timer6: softreset in 0 usec
[ 2.391296] omap_hwmod: timer6: idling
[ 2.420196] omap_hwmod: timer6: disabling clocks
[ 2.455688] omap_hwmod: timer7: enabling
[ 2.485900] omap_hwmod: timer7: enabling clocks
[ 2.520721] omap_hwmod: timer7: resetting
[ 2.551605] omap_hwmod: timer7: resetting via OCP SOFTRESET
[ 2.594268] omap_hwmod: timer7: softreset in 0 usec
[ 2.631713] omap_hwmod: timer7: idling
[ 2.660614] omap_hwmod: timer7: disabling clocks
[ 2.696105] omap_hwmod: timer8: enabling
[ 2.726318] omap_hwmod: timer8: enabling clocks
[ 2.761138] omap_hwmod: timer8: resetting
[ 2.792022] omap_hwmod: timer8: resetting via OCP SOFTRESET
[ 2.834716] omap_hwmod: timer8: softreset in 0 usec
[ 2.872131] omap_hwmod: timer8: idling
[ 2.901062] omap_hwmod: timer8: disabling clocks
[ 2.936523] omap_hwmod: timer9: enabling
[ 2.966735] omap_hwmod: timer9: enabling clocks
[ 3.001556] omap_hwmod: timer9: resetting
[ 3.032440] omap_hwmod: timer9: resetting via OCP SOFTRESET
[ 3.075134] omap_hwmod: timer9: softreset in 0 usec
[ 3.112579] omap_hwmod: timer9: idling
[ 3.141510] omap_hwmod: timer9: disabling clocks
[ 3.176971] omap_hwmod: timer10: enabling
[ 3.207855] omap_hwmod: timer10: enabling clocks
[ 3.243316] omap_hwmod: timer10: resetting
[ 3.274871] omap_hwmod: timer10: resetting via OCP SOFTRESET
[ 3.318206] omap_hwmod: timer10: softreset in 0 usec
[ 3.356292] omap_hwmod: timer10: idling
[ 3.385864] omap_hwmod: timer10: disabling clocks
[ 3.421997] omap_hwmod: timer11: enabling
[ 3.452880] omap_hwmod: timer11: enabling clocks
[ 3.488342] omap_hwmod: timer11: resetting
[ 3.519866] omap_hwmod: timer11: resetting via OCP SOFTRESET
[ 3.563232] omap_hwmod: timer11: softreset in 0 usec
[ 3.601318] omap_hwmod: timer11: idling
[ 3.630889] omap_hwmod: timer11: disabling clocks
[ 3.667022] omap_hwmod: wd_timer2: enabling
[ 3.699188] omap_hwmod: wd_timer2: enabling clocks
[ 3.735992] omap_hwmod: wd_timer2: resetting
[ 3.768829] omap_hwmod: wd_timer2: resetting via OCP SOFTRESET
[ 3.813629] omap_hwmod: wd_timer2: softreset in 62 usec
[ 3.853698] omap_hwmod: wd_timer2: disabling
[ 3.886779] omap_hwmod: wd_timer2: disabling clocks
[ 3.924224] omap_hwmod: uart1: enabling
[ 3.953796] omap_hwmod: uart1: enabling clocks
Here the serial port starts working again and I get the right text.
[ 3.988006] omap_hwmod: uart2: enabling
[ 3.992065] omap_hwmod: uart2: enabling clocks
[ 3.996765] omap_hwmod: uart3: enabling
[ 4.000793] omap_hwmod: uart3: enabling clocks
[ 4.005523] omap_hwmod: dss_dispc: enabling
[ 4.009948] omap_hwmod: dss_dispc: enabling clocks
[ 4.014984] omap_hwmod: dss_dispc: resetting
[ 4.019500] omap_hwmod: dss_dispc: resetting via OCP SOFTRESET
[ 4.025634] omap_hwmod: dss_dispc: softreset in 0 usec
[ 4.031005] omap_hwmod: dss_dispc: idling
[ 4.035247] omap_hwmod: dss_dispc: disabling clocks
This is quite repeatable.
It seems to me that there might be something odd going on with clocks.
Maybe there is some dependency that isn't encoded properly or something?
The fact that UART3 has problems while the HDQ is originally being reset is
certainly very strange.
The other thing I discovered is that when I set the uart 'sleep_timeout' to 5
(all uarts) so that CPUIDLE can let CORE enter the lower power states, I get
a fairly steady stream of:
[ 1168.490478] omap_hwmod: uart1: enabling
[ 1168.490509] omap_hwmod: uart1: enabling clocks
[ 1168.490539] omap_hwmod: uart2: enabling
[ 1168.490539] omap_hwmod: uart2: enabling clocks
[ 1168.490631] omap_hwmod: uart3: enabling
[ 1168.490661] omap_hwmod: uart3: enabling clocks
[ 1168.490661] omap_hwmod: uart4: enabling
[ 1168.490692] omap_hwmod: uart4: enabling clocks
[ 1168.578796] omap_hwmod: uart3: idling
[ 1168.578796] omap_hwmod: uart3: disabling clocks
[ 1168.578826] omap_hwmod: uart4: idling
[ 1168.578826] omap_hwmod: uart4: disabling clocks
[ 1168.578857] omap_hwmod: uart1: idling
[ 1168.578857] omap_hwmod: uart1: disabling clocks
[ 1168.578887] omap_hwmod: uart2: idling
[ 1168.578887] omap_hwmod: uart2: disabling clocks
[ 1168.714263] omap_hwmod: uart1: enabling
[ 1168.714294] omap_hwmod: uart1: enabling clocks
[ 1168.714324] omap_hwmod: uart2: enabling
[ 1168.714324] omap_hwmod: uart2: enabling clocks
[ 1168.714416] omap_hwmod: uart3: enabling
[ 1168.714447] omap_hwmod: uart3: enabling clocks
[ 1168.714447] omap_hwmod: uart4: enabling
[ 1168.714477] omap_hwmod: uart4: enabling clocks
[ 1168.803344] omap_hwmod: uart3: idling
[ 1168.803344] omap_hwmod: uart3: disabling clocks
[ 1168.803375] omap_hwmod: uart4: idling
[ 1168.803375] omap_hwmod: uart4: disabling clocks
[ 1168.851257] omap_hwmod: uart3: enabling
[ 1168.851287] omap_hwmod: uart3: enabling clocks
[ 1168.851318] omap_hwmod: uart4: enabling
[ 1168.851318] omap_hwmod: uart4: enabling clocks
[ 1168.885955] omap_hwmod: uart3: idling
[ 1168.885986] omap_hwmod: uart3: disabling clocks
[ 1168.885986] omap_hwmod: uart4: idling
[ 1168.886016] omap_hwmod: uart4: disabling clocks
[ 1168.886383] omap_hwmod: uart3: enabling
[ 1168.886383] omap_hwmod: uart3: enabling clocks
[ 1168.886383] omap_hwmod: uart4: enabling
[ 1168.886413] omap_hwmod: uart4: enabling clocks
[ 1168.944885] omap_hwmod: uart3: idling
[ 1168.944915] omap_hwmod: uart3: disabling clocks
It seems to mostly be uart3 and uart4.
If there is any interaction between the uart clock and the hdq clock, this
could explain why the HDQ gets confused when all this is happening.
And if there is a connection there, then there could also be a connection
with a DSS clock which could be confusing it.
I admit this is largely surmise and hypothesis - but there is definitely
something odd here!
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-01-19 21:05 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 12:46 DSS2/PM on 3.2 broken? Joe Woodward
2012-01-09 21:08 ` NeilBrown
2012-01-10 9:58 ` Joe Woodward
2012-01-11 13:43 ` Paul Walmsley
2012-01-11 14:22 ` Archit
2012-01-11 15:15 ` Joe Woodward
2012-01-11 15:52 ` Archit
2012-01-11 16:13 ` Joe Woodward
2012-01-11 16:54 ` Archit
2012-01-12 9:28 ` Tomi Valkeinen
2012-01-12 9:30 ` Tomi Valkeinen
2012-01-12 9:51 ` Tomi Valkeinen
2012-01-11 22:59 ` NeilBrown
2012-01-13 10:05 ` Paul Walmsley
2012-01-13 11:20 ` NeilBrown
2012-01-13 11:31 ` Paul Walmsley
2012-01-13 23:09 ` NeilBrown
2012-01-13 23:35 ` Paul Walmsley
2012-01-17 21:24 ` NeilBrown
2012-01-22 0:07 ` Paul Walmsley
2012-01-22 11:30 ` NeilBrown
2012-01-24 10:37 ` OMAP HDQ: was " NeilBrown
2012-01-26 14:19 ` Paul Walmsley
2012-01-27 22:35 ` NeilBrown
2012-01-27 22:58 ` Paul Walmsley
2012-01-28 0:40 ` NeilBrown
2012-01-28 6:02 ` Paul Walmsley
2012-02-01 7:51 ` NeilBrown
2012-02-01 18:36 ` Paul Walmsley
2012-01-18 7:13 ` Tomi Valkeinen
2012-01-18 11:15 ` NeilBrown
2012-01-18 11:42 ` Tomi Valkeinen
2012-01-18 20:30 ` NeilBrown
2012-01-19 10:17 ` Joe Woodward
2012-01-19 10:40 ` Tomi Valkeinen
2012-01-19 11:29 ` Joe Woodward
2012-01-19 11:36 ` Tomi Valkeinen
2012-01-19 12:21 ` Joe Woodward
2012-01-19 14:52 ` Tomi Valkeinen
2012-01-19 19:37 ` Kevin Hilman
2012-01-19 21:05 ` NeilBrown [this message]
2012-01-20 0:22 ` Kevin Hilman
2012-01-21 12:12 ` NeilBrown
2012-01-23 22:11 ` Kevin Hilman
2012-01-25 0:32 ` NeilBrown
2012-01-13 11:34 ` Govindraj
2012-01-13 13:23 ` Paul Walmsley
2012-01-13 19:21 ` Kevin Hilman
2012-01-13 22:37 ` Kevin Hilman
2012-01-13 23:06 ` Paul Walmsley
2012-01-13 23:34 ` Paul Walmsley
2012-01-14 1:17 ` NeilBrown
2012-01-14 1:28 ` Paul Walmsley
2012-01-13 23:39 ` Paul Walmsley
2012-01-13 11:19 ` Paul Walmsley
2012-01-11 13:32 ` Paul Walmsley
2012-01-12 16:42 ` Tomi Valkeinen
2012-01-12 22:40 ` Kevin Hilman
2012-01-13 5:29 ` Tomi Valkeinen
2012-01-13 19:30 ` Kevin Hilman
2012-01-16 11:11 ` Tomi Valkeinen
2012-01-19 19:24 ` Kevin Hilman
2012-01-20 7:16 ` Tomi Valkeinen
2012-01-20 18:06 ` Kevin Hilman
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=20120120080508.0dc0c758@notabene.brown \
--to=neilb@suse.de \
--cc=govindraj.r@ti.com \
--cc=jw@terrafix.co.uk \
--cc=khilman@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
--cc=tomi.valkeinen@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).