On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote: > Tomi Valkeinen <tomi.valkeinen@xxxxxx> writes: > > > On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote: > >> Any news on this? > >> > >> This thread seems to have gone a little quiet... > > > > Hi, > > > > I've been doing testing to understand the problem, but so far I don't > > have any idea why things go wrong. I haven't found out any logic in > > which configuration works and which doesn't. Looks to me that for some > > reason the PM prevents DSS from getting data fast enough with certain > > fifo thresholds. > > > > I have two ways to avoid the problem, but I've been reluctant to make > > patches for those because I feel it's just hiding the problem. One way > > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The > > other is to use certain fifo threshold values, which just seem to work > > for unknown reasons. > > > > Considering that we already have a SIDLEMODE hack in DSS for omap3 when > > using DSI, I wonder if the omap3 PM + DSS combination is just plain > > broken, and we should disallow idle. I'm not quite sure what are the > > implications of that. > > > > I'd appreciate comments from the PM people =). > > Unfortunately, without the bandwidth to dig into this deeply myself, I > don't have much to add. Yes, that's understandable. However, can you shed some light about the PM in OMAP3. What is it that happens here regarding PM, which does not happen is USB gadget driver is compiled in? Or when I set DSS to no-idle or no-standby? Something about L3/core/memory going into idle state? I tried to look at the debugfs/pm_debug/ files, but I couldn't see a difference between working and non-working cases. At least the OFF/RET/ON/etc states were not affected. Are there some other debug files to look at? Are there power saving features that are not observable via debug files? > As we know, it's not unheard of for various IPs to have bugs in > smart-idle mode ;) > > The one thing I can say is that the reason it probably worked on earlier > kernels was because the UART driver was not actually idling, so you were > probably never hitting low power states. There is also a change in the DSS fifos, which probably triggered this. I think I can fall back to the old behavior. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
