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 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. 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
