* Mark Brown <[email protected]> [091015 02:01]: > On Wed, Oct 14, 2009 at 10:15:48AM -0700, Tony Lindgren wrote: > > * Mark Brown <[email protected]> [091012 02:18]: > > > On Mon, Oct 12, 2009 at 11:08:58AM +0300, Eduardo Valentin wrote: > > > > > I'm afraid using dev_name is not that easy. The mmc driver generates > > > > device > > > > name at runtime. That's why this board file setups .dev at runtime as > > > > well. > > ... > > > > > So, changing this supply to something static using .dev_name it is not > > > > possible with current code. That would need refactoring the whole mmc > > > > and > > > > hsmmc setup. And the device naming procedure is dependent on cpu as > > > > well. > > > > Check arch/arm/mach-omap2/device.c:omap2_init_mmc. > > > > same answer each time it's run? How does this work with the clock API? > > > The clocks are matched using clkdev. Basically the driver just requests > > functional clock (fck) and interface clock (ick): > > > $ grep mmci arch/arm/*omap*/clock*.c > > arch/arm/mach-omap1/clock.c: CLK("mmci-omap.0", "fck", > > &mmc1_ck, CK_16XX | CK_1510 | CK_310), > > arch/arm/mach-omap1/clock.c: CLK("mmci-omap.0", "ick", > > &armper_ck.clk, CK_16XX | CK_1510 | CK_310), > > So this is using the standard dev_name based clkdev matching which > Eduardo said was impossible for the regulators. Is it just that this > will actually work fine for the regulators or is there some other magic > in the OMAP code that joins things up?
Well the mmc regulators are just passed from board-*.c files to mmc-twl4030.c which does all the low-level init needed. No other special magic going on. Eduardro, care to check the dev_name issue one more time? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
