* Tero Kristo <t-kristo@xxxxxx> [150415 05:53]: > Hi, > > This RFC provides support for moving hwmod data into separate modules > which can be registered later during boot. Only system critical parts > of the hwmod data remain in omap_hwmod_*_early_data.c file, rest are > moved into omap_hwmod_*_late_data.c. The late data can alternatively > be built into a module, or built-in to kernel image, in which case > the system behaves pretty much the same way as it does currently. Use > kconfig option OMAP_HWMOD_DATA_MODULES to control the behavior. If > this approach is something that is seen feasible to follow, rest of > the SoCs can be converted in similar manner, and eventually all the > hwmod code should be moved under some driver (drivers/bus/ maybe?) Interesting to see what it would take to move some of this into loadable modules or /lib/firmware. I think we should queue the fixes and anything that makes it easier to initialized hwmods in stages. Then we should wait on the __init changes until there's a clear use case. Meanwhile, to me it seems we can make 81xx/am33x/am437x at least device tree only for the hwmod with the following two changes: 1. Add parsing for the sysc syss properties along the lines of the RFC patches posted by Felipe few months back. 2. Set up the .clkctrl register as a gate clock that gets parsed from the dts files. And then we can also start moving to generic power domains and simple-pm-bus. > This RFC set only provides support for omap3 hwmod data split. Please > note that you probably must use ramdisk rootfs to load the hwmod data > module itself from, as most of the system devices are not initialized > in the early boot. The problem with this is and firmware related approaches is not having the complete set of boot devices like we all know :) Regards, Tony -- 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
