On Fri, Sep 25, 2009 at 2:19 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> wrote: > On Thu, 2009-09-24 at 17:52 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen wrote: > >> > If it is not like that, and the driver initialization is included, how >> > does the PM layer know how long it takes for the DSS driver to >> > reconfigure the DSS hardware from OFF mode? >> >> Currently it doesn't, but if you were measure it, we can use those >> numbers in the decision making process. > > Ok, now I see. However, I'm not sure if that will work. The problem is > that the wakeup latency depends on many things. When using DPI/RFBI the > wakeup is very fast. With SDI it's probably a bit slower and with DSI > even slower. The varying latencies are not an issues. When in the different modes, just register a different latency requirement. > And at least with DSI PLL, the wakeup time depends on the frequencies > used (according to TRM), and in some cases it can be optimized, in some > cases not. So I don't think there's one single value that fits all. A single value isn't necessary. > Also, I still think it would be better if the driver was also able to > prevent OFF mode explicitely. Defining the max-wakeup-lat with a magic > number sounds a bit prone to breaking up. I disagree. What is important is that the driver communicates *why* it needs to prevent OFF mode (can't handle the latency etc.) and decision making up to the PM core. The drivers should not embed policy in them. > But perhaps, as you said, when drivers work properly they don't have to > care about OFF mode as such, but only about the wakeup latency, and thus > the max-wakeup-lat is enough. I'm just not quite sure about that, as OFF > mode may have side effects as the module is totally powered off, while > with RET the side effects should be minimal. > > I don't have any concrete example about the side effects, but one > particular thing I'm thinking about is DSI PLL. If DSS is in RET, I > believe DSI PLL works normally. But if the DSS is reset via OFF mode, I > believe DSI PLL is also reset. But I'm not sure if DSI PLL is ever > needed while DSS would be off, so this may be theoretical =). > > Tomi This problem is not unique to DSS, and the other drivers are handling this. Therefore, I'm inclined to merge this patch to that it's clear that DSS support for OFF mode is broken and needs to be fixed. As a *temporary*, debug solution, I might accept a hack where DSS2 disables OFF mode explicitly, but this will not go upstream. 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
