Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> writes: > On Thu, 2009-10-01 at 18:19 +0200, ext Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx> writes: > >> > So is there an API to change that value in resource34xx.h dynamically, >> > depending on what DSS block is in use? Or am I still missing something >> > here? =) >> >> You're right, we currently do not have a way to dynamically update >> this table and we should for completeness. > > Ok. This was what I was after in the first place, but didn't know how to > form the question properly =). > >> Excuse my ignorance of the DSS/DSI/etc., but if a DSI periperal is use >> that requires a continual DSI clock then shouldn't the driver always >> keep the DSI clock enabled (iow, it should never call clk_disable()). >> If a clock is left enabled, even if OFF-mode is targetted for that >> powerdomain, it will not reach OFF because the clockdomain is active. > > Well, this is quite theoretical, and I agree that let's just forget > about this and worry it if such a case ever emerges. But here's what I > was thinking: > > OMAP's DSI block can be clocked by OMAP's normal clocks (DPLL4, if I > recall right), which are handled by clk_enable/disable. But the clock > signal that goes over DSI bus to the peripheral is generated by the DSI > PLL, which is a DSS internal PLL not handled by clk_enable/disable. DSI > PLL usually gets its reference clock from sysclock. > > For example, we have these displays that have their own framebuffer, and > they independently update the actual panel from their internal > framebuffer, while OMAP can be totally sleeping. Currently these > displays generate their own clock for this internal updating. > > There's an option in the OMAP DSI block to set the DSI clock output to > always on (versus DSI clock output enabled automatically when there's > data to transfer over DSI bus). And the reasoning for this option is > that some peripherals may require continuous clock to operate. So we > could have a display that uses DSI clock for staying alive, doing some > internal work like refreshing the panel. OK, I understand the need to keep these clocks going in some cases. Based on how some of the other HW modules work, I would assume that if DSI is active (generating clocks), it would never allow and idle transition so it wouldn't hit off mode. I guess we'd need to dig into the DSS/DSI docs to see if that's true. But the basic model for going into RET or OFF is that the PRCM uses an idle protocol to ask each module if it can idle. Here's a simplified summary: First, PRCM sends and idle request. If the module is idle, it responsds with an idle ack and the PRCM is then free to disable its clocks etc. But, if the module doesn't ack, clocks will not be cut and the module will stay active and prevent full-chip RET/OFF. So, following this model, I assume that the DSS would never idle ack if one of its sub-modules, in this case DSI, is active. That would need to be verified in the docs. >> In the DSS git, the master branch seems to be based at 2.6.31-rc5. Do >> you have an updated version against 2.6.32-rc1 or omap/master? > > Which tree are you referring to? My gitorious tree contains the latest > version that I've been pushing to mainstream. > > git://gitorious.org/linux-omap-dss2/linux.git (master branch) > > It's based on the mainstream tree, but I think it should apply to l-o > easily. I can also make l-o based branch if the conflicts are bad. Hmm, the git tree I was looking at was from bat.org. I'll update to this one and have a look. Thanks, 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
