Steve Sakoman wrote: > On Wed, Aug 5, 2009 at 9:35 AM, John Sarman<[email protected]> wrote: > > On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman<[email protected]> > > wrote: > >> Might I suggest a kernel patch for this rather than fixing u-boot so that > >> all the midnight oil you've burnt does not have to be duplicated by others. > > Well I dont know how to answer that. Because the Mux architecture is > > slightly on the scary side. I personally have had success with it, > > but everytime you need to add a new pin functionality you have to > > update mux.h. I finally decided to just focus on having the MUX > > correct at boot up via u-boot. > > > > I could just add the code to update the mux without using the mux > > architecture. > > > > I would appreciate some opinions on this. > > I get discouraged every time I look at using kernel pinmuxing. It > seems to assume that some mux settings are "standard" when in my > experience that is often not so. So I face having to write code to > undo what it does (and face glitches on the gpio lines), or the bigger > task of restructuring the code to do the right thing. > > 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" >
Does it make sense to do __ALL__ pin-muxing in the board-files for a given board? That way, we have the pin-mux setting in the kernel, plus a nice set of debug logs from CONFIG_MUX_DEBUG to tell if something is not right, plus it's as good as doing it in u-boot anyway? What say? - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
