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