Re: PM(?) problems on v3.3-rc1 on OMAP3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 21, 2012 at 10:47 PM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> On Sat, 21 Jan 2012, Tomi Valkeinen wrote:
>
>> 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.
>
> Okay, thanks for the quick response.
>
> Would you expect to see these "sync lost" messages if the DSS FIFO(s) are
> underflowing?  Or would that return a different error?  Am wondering if
> CORE may be entering some low power state, so DSS FIFO refill may be
> taking too long.

I would expect to see FIFO_UNDERFLOW errors. Then again, I have to
admit I'm not totally sure what SYNC LOST error means. My
understanding is that it's about DSS internal timings and fifos, for
example when DSS is scaling the image and if the scaler cannot get
pixels fast enough from the preceding HW block.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux