Re: Fwd: MMC3 Overo

[Kevin Hilman <khilman@deeprootsystems.com>]

Steve Sakoman wrote:
> On Wed, Aug 5, 2009 at 9:35 AM, John Sarman<johnsarman@gmail.com> wrote:
>> On Wed, Aug 5, 2009 at 12:25 PM, Kevin Hilman<khilman@deeprootsystems.com> 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"

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?

All that should be necessary for a one-time setup is possibly adding and 
entry to mux.h and then calling omap_cfg_reg() in your board init code.

Kevin