On Wed, 18 Apr 2012, Cousson, Benoit wrote: > Well, the point is that we do not need this warning even for that. This > is something we have to ensure by reviewing carefully the code. My perspective is slightly different. Until we're sure that we don't need clock framework-based clockdomain control in mainline for main clocks, we shouldn't remove that warning. That is because clock framework-based clockdomain control works via the struct clk's clkdm field. So until we switch away from that model, we should ensure that each clock is associated with the clockdomain that its clock control FSM is associated with (in OMAP3 terms). I don't have a problem with switching away from that model, or switching individual SoCs away from that model, as long as regressions aren't introduced. But until that switch happens, it seems wise to avoid weakening its consistency assumptions. > If you look today, the warning is complaining about clocks that are > perfectly fine. Actually, mainline is only complaining about one clock: http://www.pwsan.com/omap/bootlogs/20120417/sparse_cppcheck_cleanup_3.5__0b93afd5d945a8c002f4d380a88b5d7a61c49289/4430es2panda_bootlog.txt In the current model, the right fix for that clock is to associate it with a CM clockdomain (see for example the 4430 TRM vX Figure 3-70 "CD_DMA Overview"). > So keeping it will just add some noise and not necessarily highlighting > the real issue. > > FYI here is what we have after the clock cleanup on OMAP4 (i.e removal of modulemode clock nodes): > [ lots of warnings elided ] > That's a lot of noise for nothing. That's why Rajendra's patch is needed now. Sounds like the patch to alter the warnings should be associated with this clock cleanup series, then, since it sounds like it changes the clockdomain control model. And if the model change is only affecting OMAP4+, then the warning change should also only apply to OMAP4+. - 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
