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