On Wed, Nov 04, 2009 at 08:00:52PM +0530, Gadiyar, Anand wrote: > Mark Brown wrote: > > On Wed, Nov 04, 2009 at 06:02:48PM +0530, Gupta, Ajay Kumar wrote: > > > I can do regulator_get() and regulator_enable() but where ? Are you referring to board file? > > > I was thinking of doing it in a generic form within EHCI driver (ehci-omap.c). > > Do it in the EHCI driver. The EHCI driver should just unconditionally > > use the regulators, the regulator API will be compiled out if support is > > disabled in Kconfig. > NAK to do it unconditionally in the driver. This is board specific. > It just so happens that this is the regulator used on the beagleboard > and EVM, but it could very easily be another one (like on the SDP). Obviously the physical regulator hookup is board specific - please take a look at how the regulator API operates here, none of this needs to be handled by drivers using the API which was what the discussion above (regarding regulator_get() and regulator_enable()) was about. regulator_get() takes the struct device for the consumer (the EHCI controller in this case) and a name for the supply both of which depend only on the consumer. The board drivers set up the mapping from these to actual physical regulators during initialisation and the whole process is completely transparent to the consumer drivers, they can just ask for a fixed thing. > How about a hook from the platform code in mach-omap2/usb-ehci.c instead? If this is needed something is broken. -- 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
