linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>,
	t-kristo@ti.com,
	linux-omap mailing list <linux-omap@vger.kernel.org>,
	NeilBrown <neilb@suse.de>, Joe Woodward <jw@terrafix.co.uk>
Subject: Re: PM(?) problems on v3.3-rc1 on OMAP3
Date: Sat, 21 Jan 2012 17:57:07 +0200	[thread overview]
Message-ID: <1327161427.1863.5.camel@lappy> (raw)
In-Reply-To: <alpine.DEB.2.00.1201210042030.28153@utopia.booyaka.com>

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote:
> On Fri, 20 Jan 2012, Tomi Valkeinen wrote:
> 
> > Third, when I load the DSS modules, I see only ON state increasing for
> > dss_pwrdm, as it should be. However, I'm getting constant stream of sync
> > losts from DSS, and the display doesn't basically work at all.
> > 
> > I can see MPU pwrdm going into RET a lot, and if I do "while true; do
> > echo foo; done", which I presume basically prevents RET for MPU, the
> > display becomes stable.
> 
> If this particular problem persists after you apply the patch set that I 
> sent earlier, it suggests that something in the DSS is sensitive to the 
> amount of time it takes the MPU to wake up and service an interrupt when 
> the MPU powerdomain is in a low-power state.  Total guess, but perhaps  
> omap_dispc_irq_handler() is getting called after each frame and needs to 
> run within a certain bounded time when that happens?

No. After the DSS has been configured and started (by the MPU), it runs
by itself, reading the pixels from the memory displaying them on the
screen. Only when the user wants to change the configs or the frame, the
MPU does something. And interrupts are only needed to handle the
changing of configs or frame data using VSYNCs as the interval. The user
probably doesn't like it if the VSYNC irq is handled a few seconds
later, but the DSS HW doesn't care, and functions normally.

In this case something is affecting the DSS (clocks? powers?), or the
memory, or the process of reading the pixels. I really don't see the MPU
or IRQs affecting this problem, except indirectly.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-01-21 15:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-20 10:33 PM(?) problems on v3.3-rc1 on OMAP3 Tomi Valkeinen
2012-01-20 10:49 ` Govindraj
2012-01-20 11:07   ` Tomi Valkeinen
2012-01-20 11:21     ` Govindraj
2012-01-20 12:32       ` Jean Pihet
2012-01-20 12:44         ` Govindraj
2012-01-21  7:39       ` Paul Walmsley
2012-01-21  7:38     ` Paul Walmsley
2012-01-20 11:56 ` Govindraj
2012-01-20 12:01   ` Tomi Valkeinen
2012-01-20 12:34     ` Jean Pihet
2012-01-20 12:40       ` Tomi Valkeinen
2012-01-20 13:36         ` Jean Pihet
2012-01-20 15:00           ` Tomi Valkeinen
2012-01-22 11:11             ` NeilBrown
2012-01-23  8:53               ` Tomi Valkeinen
2012-01-23  9:04                 ` Paul Walmsley
2012-01-23  9:24                   ` Tomi Valkeinen
2012-01-23  9:31                     ` Paul Walmsley
2012-01-23 10:48                       ` Tomi Valkeinen
2012-01-23 11:02                         ` Paul Walmsley
2012-01-23 11:06                           ` Tomi Valkeinen
2012-01-24 10:39                   ` Tomi Valkeinen
2012-01-20 12:45     ` Govindraj
2012-01-20 12:47   ` Shubhrajyoti
2012-01-21  7:35 ` Paul Walmsley
2012-01-21  7:47 ` Paul Walmsley
2012-01-21 15:57   ` Tomi Valkeinen [this message]
2012-01-21 20:46     ` NeilBrown
2012-01-23  8:25       ` Tomi Valkeinen
2012-01-21 20:47     ` Paul Walmsley
2012-01-22 11:11       ` Valkeinen, Tomi

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=1327161427.1863.5.camel@lappy \
    --to=tomi.valkeinen@ti.com \
    --cc=jw@terrafix.co.uk \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=paul@pwsan.com \
    --cc=t-kristo@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).