> -----Original Message----- > From: Hilman, Kevin > Sent: Friday, January 06, 2012 5:34 AM > To: Hiremath, Vaibhav > Cc: linux-omap@xxxxxxxxxxxxxxx; Paul Walmsley > Subject: Re: [RFC/PATCH 3/7] ARM: OMAP3: clock data: treat all AM35x > devices the same > > "Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes: > > >> -----Original Message----- > >> From: Hilman, Kevin > >> Sent: Thursday, January 05, 2012 6:47 AM > >> To: linux-omap@xxxxxxxxxxxxxxx > >> Cc: Paul Walmsley; Hiremath, Vaibhav > >> Subject: [RFC/PATCH 3/7] ARM: OMAP3: clock data: treat all AM35x > devices > >> the same > >> > >> The init for 3505/3517 specific clocks depends on the ordering of > >> cpu_is checks, is error prone and confusing (there are 2 separate > >> checks for cpu_is_omap3505()). > >> > >> Remove the 3505-specific checking since CK_3505 flag is not used, and > >> treat all AM35x clocks the same. > >> > >> This means that the SGX clock (the only AM35x clkdev not currently > >> flagged for 3505) will now be registered on 3505, but that is > >> harmless. That can be cleaned up when the clkdev nodes are removed in > >> favor of them being registered by hwmod. > >> > > [Hiremath, Vaibhav] How do you think we can use hwmod here? > > I haven't thought in detail about the exact fix for this, but it > shouldn't be difficult. For example, it could be as simple as creating > some more per-family hwmod lists of optional hwmods. Then, during init, > register them based on the feature flag. > > Longer term, it may be that we handle this using DT, but I'm not sure we > will use DT to describe that level of SoC detail. > > > Currently hwmod is also dependent on cpu_is_xxxx to register respective > modules. > > In mainline it is only done by CPU family (revision), not using cpu_is* > Yeah, I missed this point (was referring different code base). Thanks, Vaibhav > > I completely understand and agree to the fact that there may not be any > harm > > due to this, but this means, iva will be always registered for 3505 > devices. > > Correct for today, but not difficult to remedy by fixing up the hwmod init. > > Kevin -- 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
