Hi, On Fri, 18 Jan 2013, J Keerthy wrote: > The previous logic to detect the clocks for OMAP4460 > was to combine the clocks marked as CK_443X and CK_446X. This would be > fine as long as OMAP4460 was a super set of OMAP4430 clock set. > This is not the case as there are clocks which are specific to OMAP4430 > (for example bandgap_fclk) and some which are specific to OMAP4460(for example > bandgap_ts_fclk). > The clock "bandgap_fclk" is specific for OMAP4430 and > this was added as part of OMAP4460 clock set which should not be done. > > Hence changing the convention. > > CK_446X --------> Clocks specific to OMAP4460 > CK_443X --------> Clocks specific to OMAP4430 > CK_44XX (CK_446X | CK_443X) --------> Common to both OMAP4460 and OMAP4430 > > Boot Tested on both Panda and Panda-es. > > Signed-off-by: J Keerthy <j-keerthy@xxxxxx> > Reviewed-by: Rajendra Nayak <rnayak@xxxxxx> > Cc: Paul Walmsley <paul@xxxxxxxxx> > Cc: Eduardo Valentin <eduardo.valentin@xxxxxx> While I agree with this patch, my understanding is that Tony wishes to shift to list-based initialization for clocks, similar to how the hwmod initialization is done for OMAP3. This will result in moving away from the CK_* flags. There are some previous public mailing list messages on this topic that you can probably find by searching for CK_446X. Now that we've switched to the common clock framework, it should be more practical to do this conversion, since we can refer to parent clocks by name rather than by pointer. Could you please update your patch to take that approach instead? - 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
