Tony Lindgren <tony@xxxxxxxxxxx> writes: > * 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. Sounds like a good start on a mux rework to me. :) Kevin -- 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
