On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote: > sorry for the delay, just caught this during a list sweep. The maintainer > of the OMAP4 hwmod data is Benoît, so I'd suggest cc'ing him for OMAP4 > hwmod data requests. No worries and thanks for the reply. > On Wed, 4 Jan 2012, Marc Butler wrote: > > Currently omap_hwmod_44xx_data.c has slimbus1/slimbus2 included in the > > list of excluded IPs. > > > > Is it possible to get a version of omap_hwmod_44xx_data.c generated > > with slimbus1/2 included? > > A good starting point is included below. Thank you. > > I am concerned that I do not understand how the pieces for such a > > driver should be put together: should such a driver be built from the > > ground up with hwmod interfaces, or should they be added in as the > > driver stabilizes? > > The driver shouldn't have any hwmod code in it. Any > omap_device/omap_hwmod code that's needed should go into an appropriate > file in arch/arm/mach-omap2. The device resource metadata will flow > through the existing Linux resource system. Also, currently we are using > the pm_runtime*() calls as the way to interface with the > omap_hwmod/omap_device enable/idle code, so your driver should be written > using those. I believe I came to the conclusion that I need the hwmod support, inorder to build out the platform_* infrastructure the driver needs, to query/configure resources. The driver itself does not call hwmod directly. A colleague is looking into this, and we are unclear what should be done in the case where you can choose alternate muxing of the pins? For instance slimbus2 module can be routed two distinct pads. Should this be handled in an appropriate board_*.c? -m -- 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
