* Philip Balister <philip@xxxxxxxxxxxx> [091007 19:32]: > On 10/07/2009 10:47 AM, Tony Lindgren wrote: >> * 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 > > Does anyone have a reference to Russell's suggestion? Here's a link to the thread discussing the earlier header changes: http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg15087.html Regards, Tony > Philip > > >> >> 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 >> > -- 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
