* Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [091006 15:18]: > "Menon, Nishanth" <nm@xxxxxx> writes: > > >> -----Original Message----- > >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > >> owner@xxxxxxxxxxxxxxx] On Behalf Of Kevin Hilman > >> > >> >>> W17_7XX_USB_VBUSI, > >> >>> + > >> >>> + /* MMC */ > >> >>> + MMC_7XX_CMD, > >> >>> + MMC_7XX_CLK, > >> >>> + MMC_7XX_DAT0, > >> >> > >> >> probably a dumb question -> but should'nt these go off to bootloader > >> >> perhaps? > >> >> > >> > > >> > Perhaps, although we use either EOL (for HTC Wizard) or Haret to boot, > >> > and they don't set up the right mux configuration for our board. > >> > > >> > This way though, we don't have to worry about the boot loader -- we > >> > can set it up right regardless of who boots us. > >> > >> I agree with Cory. > >> > >> I prefer that mux settings go into the kernel, even if they are setup > >> in the bootloader already. It's better to have redundancy than wonder > >> what to do if changing boot loaders. > >> > > Probably opening up a can of worms.. Are the rules different for OMAP3? > > Should'nt we have all mux done at kernel so that kernel is loader > > independent? > > Yes, we should. My preference is to always have muxing in the kernel. Agreed. We still should support bootloader only muxing too. BTW, I've been thinking about the following sets of patches for the next merge window: 1. Do the include directories for mach-omap1 and mach-omap2 as suggested by Russell earlier 2. Move all mux code to only live under arch/arm/*omap*/ and make sure drivers don't call omap_cfg_reg() any longer 3. Remove the enumeration for the mux and require all the boards to register the pins they'll use After these it should be trivial to improve the mux code further. The steps 2 & 3 above will be most likely breaking things for some boards, so help will be needed with testing. 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
