On Wed, Oct 7, 2009 at 11:33 AM, Kevin Hilman <khil...@deeprootsystems.com> wrote: > Tony Lindgren <t...@atomide.com> writes: > >> * Kevin Hilman <khil...@deeprootsystems.com> [091006 15:18]: >>> "Menon, Nishanth" <n...@ti.com> writes: >>> >>> >> -----Original Message----- >>> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>> >> ow...@vger.kernel.org] 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 >
I agree, this sounds like a good approach. Should make a lot of drivers much cleaner and easier to maintain, and we can do away with the 7xx versus all of the rest of omap1 mux nonsense we have right now. Cory -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
