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. 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. Kevin -- 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