* John Sarman <johnsarman@xxxxxxxxx> [090806 05:11]: > On Wed, Aug 5, 2009 at 2:35 PM, Kevin Hilman<khilman@xxxxxxxxxxxxxxxxxxx> wrote: > > Steve Sakoman wrote: > >> > >> On Wed, Aug 5, 2009 at 10:58 AM, Kevin > >> Hilman<khilman@xxxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> Steve Sakoman wrote: > >>>> > >>>> And up to now in each case I shrug and say "no time to do that now, > >>>> I'll just leave kernel pinmuxing turned off and do it in u-boot" > >>> > >>> I agree there are lots of shortcomings in the current mux code and we've > >>> been hitting them regularily lately. > >>> > >>> That being said, for mux settings that done one-time only at boot, what > >>> are > >>> the problems you're running into? > >> > >> It's been a few months since I last encountered this, so the exact > >> details are a bit fuzzy. > >> > >> I seem to recall that there were some basic issues with enabling > >> kernel pinmuxing in that some of the setup that was done for all > >> machines was just wrong for my particular machine. IIRC, it was due > >> to assumptions about which pad was used for a particular function (for > >> those functions which can be steered to multiple GPIO pads). > >> > >> So I faced having to undo that change in my board file as well as any > >> issues that may have arisen from glitches on the GPIO pins during the > >> process. And since there were several of these I gave up and turned > >> off kernel pinmuxing. > >> > >> I'd be happy if we cleaned up the "one size fits all" pinmuxing to > >> just that subset that truly does fit all boards, and leave the rest to > >> the board files. I'd also be content to have it all done in the board > >> file for each machine. > > > > Indeed, any assumptions about common muxing that are not indeed common are > > bugs and should be fixed. > > > > The "right" solution is to have everything in the kernel, and split across > > SoC "common" init and board specific init. Of course u-boot > > will still have to do some early muxing, but it should be redone in > > the kernel so it's trivial to change bootloaders. > > > > So the real missing piece is someone to step up and rework the mux code. > > The bigger problem is that the vast majority of folks don't care about the > > common case and only care about getting thing working for a specific > > platform. > > > > Kevin > > > I like the idea of having the board file configure the mux. First of > all lets address the shortcomings of mux.h. The Pin values are > labeled as so: > <snip from mux.h> > * NOTE: Please use the following naming style for new pin entries. > * For example, W8_1610_MMC2_DAT0, where: > * - W8 = ball > * - 1610 = 1510 or 1610, none if common for both 1510 and 1610 > * - MMC2_DAT0 = function > > But lets take the 3530 as an example. > The 3530 has three separate packages. CBB, CBC, and CUS. Now lets > look at MMC3_clk (the root of my original problem that started this > thread) > CBB CBC CUS > mmc3_clk AB1 / AF10 R9 / AB2 AC1 > > So to properly add these to mux.h we need to add 5 entries for mmc3_clk > AB1_35XXCBB_MMC3_CLK > AF10_35XXCBB_MMC3_CLK > R9_35XXCBC_MMC3_CLK > AB2_35XXCBC_MMC3_CLK > AC1_35XXCUS_MMC3_CLK > We would then have to update mux.c making sure the position matches > and add the proper settings. > > So this is obviously a maintenance nightmare. > > Another option is to add a CONFIG_35XX_CBB or CBC or CUS when selecting a board > example in menuconfig selecting MACH_OVERO would select CONFIG_35XX_CBB. > Then in a new mux_35xx.h located in the mach_omap2 folder have > #ifdef CONFIG_35XX_CBB > //all muxable balls > #define N4 0x078 > #define AB1 0x164 > etc ..... > #endif > where we just use the Ball name defined as its offset in the 35xx case Yeah we need to improve the mux code as discussed many times earlier, it's been limping along since the 15xx days, and now that the mux hardware does not have the mux configuration registers all over the place we can simplify it for later omaps. But doing things with Kconfig won't work as we support compiling in multiple boards and omaps. It needs to be done dynamically in in the board-*.c files. > > then we create a file say board_overo_mux.c > > in it we call > configure_pin(AB1, MODE3, INPUT | PU | PE); > for every ball that is muxable. For the sensible configurations we already have these defines mux.h: /* 34xx active pin states */ #define OMAP34XX_PIN_OUTPUT 0 #define OMAP34XX_PIN_INPUT OMAP3_INPUT_EN #define OMAP34XX_PIN_INPUT_PULLUP (OMAP2_PULL_ENA | OMAP3_INPUT_EN \ | OMAP2_PULL_UP) #define OMAP34XX_PIN_INPUT_PULLDOWN (OMAP2_PULL_ENA | OMAP3_INPUT_EN) /* 34xx off mode states */ #define OMAP34XX_PIN_OFF_NONE 0 #define OMAP34XX_PIN_OFF_OUTPUT_HIGH (OMAP3_OFF_EN | OMAP3_OFFOUT_EN \ | OMAP3_OFFOUT_VAL) #define OMAP34XX_PIN_OFF_OUTPUT_LOW (OMAP3_OFF_EN | OMAP3_OFFOUT_EN) #define OMAP34XX_PIN_OFF_INPUT_PULLUP (OMAP3_OFF_EN | OMAP3_OFF_PULL_EN \ | OMAP3_OFF_PULL_UP) #define OMAP34XX_PIN_OFF_INPUT_PULLDOWN (OMAP3_OFF_EN | OMAP3_OFF_PULL_EN) #define OMAP34XX_PIN_OFF_WAKEUPENABLE OMAP3_WAKEUP_EN So I'd rather stick with those because otherwise we easily end up with wrong combinations. Of course the naming could be more generic there :) Regards, Tony > voila, we have a predefined limit of pins so once mux_35xx.h is fully > defined, and the driver code is in place then the only thing that a > developer would need to do to leverage the mux is edit his board file. > > Im sure I have glossed ove many details but this is a general outline. > -- > 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
