Hi Paul, On Thu, Aug 09, 2012 at 01:49:34, Paul Walmsley wrote: > Hi Vaibhav > > On Wed, 8 Aug 2012, Bedia, Vaibhav wrote: > > > On Wed, Aug 08, 2012 at 19:35:50, Paul Walmsley wrote: > > > > > It doesn't seem to me that this would necessarily always be an error. > > > Suppose some init code to create cpsw devices is running on an OMAP3430. > > > Then a omap_hwmod_for_each_by_class() that doesn't locate anything > > > wouldn't be an error, right? > > > > Well, I think a failed lookup operation will be a bit expensive since it > > iterates over the whole list of registered hwmods and hence put in the > > pr_err(). > > If performance is a serious problem there, we can maintain a list of hwmod > pointers inside each struct omap_hwmod_class, updated when the hwmods are > registered. But as far as I know, performance hasn't been an issue here > yet. If performance is the real motivation, I'd rather see an > implementation of per-class lists as described above. > Ok. I'll try to do some profiling using a timer to see how much time we spend over here. On AM335x there are 2 such lookups, one for the dma and one for the mcbsp. I could get this done today but will get to it tomorrow. Based on how this goes I'll try out the omap_hwmod_class list like you suggested. > > But I don't see how the SoC specific example that you pointed out > > could be handled without putting in cpu_is_* checks in the registration > > process itself :( > > Hmm, why not? > > To continue the earlier example, the init code in the platform code simply > calls omap_hwmod_for_each_by_class(), and creates the appropriate device > if anything was found. If no cpsw IP blocks are present on a given SoC, > nothing would happen. No cpu_is_*() would be needed. > > I was thinking of avoiding the lookup process itself and hence mentioned the need for cpu checks surrounding the platform init code. The current API does help avoid all this in an excellent manner. Regards, Vaibhav B. -- 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
