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