On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote: > On Thu, Apr 26, 2012 at 11:54:51, Paul Walmsley wrote: > > > > while working on clock33xx_data.c, it became clear that we would not be > > able to remove the MODULEMODE leaf clocks for several IP blocks that share > > driver code with other DaVinci chips. This is because: > > > > 1. the drivers for these IP blocks only use the clock framework, rather > > than runtime PM; > > > > and > > > > 2. the clk_get() calls in those drivers do not specify a con_id > > parameter, which could cause problems with the clkdev clk_find()'s fuzzy > > matching algorithm. > > > > So perhaps your group can work on converting the drivers to use runtime > > PM? Discussing this with Kevin, it sounds like DaVinci doesn't have > > runtime PM hooks implemented, but you can probably use OMAP1 as an example > > of how to do it. > > > > And then if clk_get() is still needed in the drivers, a specific con_id > > should be supplied, such as "fck", which can also be supplied by the OMAP > > codebase. > > Honestly, I don't want to block AM33xx stuff getting into mainline due to > missing feature in Davinci. > > Also, since AM33xx is not fully supported in the mainline (from peripheral > perspective), it really should not break anything as of now. > > I am expecting, AM33xx core patches will get in by v3.5 and then while > adding peripheral support we will take Davinci migration activity, and can > make sure that nothing breaks (for all Davinci, OMAP and AM33xx). To be clear, I am not suggesting that the AM33xx stuff should be blocked by these changes. I am however suggesting that it be added to the to-do list, so we can remove most or all of the remaining MODULEMODE clocks from the AM33xx clock tree. Sounds like you are planning to work on that at some point, which is good. - Paul -- 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
