From: Kevin Hilman <khilman@deeprootsystems.com>
To: Steve Sakoman <sakoman@gmail.com>
Cc: John Sarman <johnsarman@gmail.com>,
linux-omap <linux-omap@vger.kernel.org>
Subject: Re: Fwd: MMC3 Overo
Date: Wed, 05 Aug 2009 11:35:48 -0700 [thread overview]
Message-ID: <4A79D104.60607@deeprootsystems.com> (raw)
In-Reply-To: <5e088bd90908051121h38678c9fha73b7beb88752156@mail.gmail.com>
Steve Sakoman wrote:
> On Wed, Aug 5, 2009 at 10:58 AM, Kevin
> Hilman<khilman@deeprootsystems.com> 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
next prev parent reply other threads:[~2009-08-05 18:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 15:49 MMC3 Overo John Sarman
2009-07-30 19:23 ` John Sarman
2009-08-03 1:20 ` Paul Walmsley
2009-08-03 10:33 ` John Sarman
[not found] ` <52AC0DF6-BA95-421B-8C56-5F3DC62279DF@mac.com>
[not found] ` <bb2708720908030356p6d7b1cdegf0bd8c39a5c4ecd9@mail.gmail.com>
2009-08-03 10:57 ` Fwd: " John Sarman
2009-08-03 11:11 ` Paul Walmsley
2009-08-04 12:21 ` John Sarman
2009-08-05 8:32 ` Grazvydas Ignotas
[not found] ` <bb2708720908050901lbc67b1cx5a75a7667fa36fd1@mail.gmail.com>
2009-08-05 16:02 ` Fwd: " John Sarman
2009-08-05 16:25 ` Kevin Hilman
2009-08-05 16:35 ` John Sarman
2009-08-05 17:51 ` Steve Sakoman
2009-08-05 17:56 ` Gadiyar, Anand
2009-08-05 17:58 ` Kevin Hilman
2009-08-05 18:21 ` Steve Sakoman
2009-08-05 18:35 ` Kevin Hilman [this message]
2009-08-05 18:55 ` Philip Balister
2009-08-06 2:13 ` Hunyue Yau
[not found] ` <bb2708720908051229x49f10094w9b19b468d4bfaec8@mail.gmail.com>
2009-08-06 2:02 ` John Sarman
2009-08-06 6:44 ` Tony Lindgren
2009-08-06 14:30 ` Kevin Hilman
2009-08-06 14:44 ` Vladimir Pantelic
2009-08-06 15:16 ` Kevin Hilman
2009-08-06 15:35 ` Steve Sakoman
2009-08-06 15:09 ` Philip Balister
2009-08-06 16:09 ` Peter Barada
2009-08-07 8:21 ` Tony Lindgren
2009-08-07 9:24 ` Vladimir Pantelic
2009-08-07 9:55 ` Tony Lindgren
2009-08-07 13:24 ` Steve Sakoman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A79D104.60607@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=johnsarman@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=sakoman@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox