On 2013-03-20 13:08, Archit Taneja wrote: > Hi, > > On Friday 08 March 2013 05:22 PM, Tomi Valkeinen wrote: >> Store dispc core clock rate so that it's available for calculations even >> if the HW is disabled. > > I think the core_clk_rate variable should change when we change the lcd > clock source through dss_select_lcd_clk_source() for omap3. > > If we have the following sequence: > > ... > dispc_mgr_set_lcd_divisor(); > dss_select_lcd_clk_source(); > ... > > The value of core_clock variable would be based on the previous clock > source, and not the current one. > > This situation doesn't occur currently as the 'apply' framework delays > all dispc writes to the point when we enable the manager. So the > sequence above cannot occur. But maybe we should keep this in mind when > we move more things to omapdrm, where 'apply' isn't in use. Hmm. Good point. I don't think this has to do with apply system. The clock source is set by the output drivers, and the output drivers also calculate the divisors, and call the functions to set the divisors. Both DPI and DSI drivers first set the clock source, and then call the dss_mgr_set_lcd_config() which sets the divisors (causing the recalc). Whether using the apply or not, I think it should work correctly. But it's clearly something that is a bit fragile. *cough*commonclockframework*cough*. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
