public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@nokia.com>
To: ext David Brownell <david-b@pacbell.net>
Cc: Steve Sakoman <sakoman@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: Pin mux utility?
Date: Fri, 29 Aug 2008 20:21:09 +0300	[thread overview]
Message-ID: <1220030469.19671.7.camel@localhost> (raw)
In-Reply-To: <200808291017.40151.david-b@pacbell.net>

Hi,
On Fri, 2008-08-29 at 10:17 -0700, ext David Brownell wrote:
> On Friday 29 August 2008, Steve Sakoman wrote:
> > Is anyone aware of a utility to report the state of pin mux settings?
> > 
> > I'd like to verify that u-boot is setting things up properly.
> 
> CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly":
> when Linux needs one setting, but the boot loader leaves a different
> one, you get a warning.  That's usually interpreted as u-boot doing
> it wrong, except on devboards where the boot loader can't actually
> know about all external hardware that might be hooked up (and how)

I'm probably a bit off topic, but since Tony started promoting the
concept of multi-arch binary, well, i see it as a huge limitation the
fact that the bootloader is expected to the right thing.

When thinking about our Nokia HW vs the TI SDP, even the bootloader is
different (yes, we should move to uboot and i couldn't be happier, but
it's not gonna happen at the moment).

In the multi arch case (but even single-arch, if we would like to
support multiple boards with one single kernel binary) i see as a much
more reasonable solution the case where the bootloader passes the board
id to the kernel and the kernel loads the board-specific configuration
in the form of a module.

DVFS for example defeats the idea that the bootloader would be enough to
setup properly the clock tree (of course it will do it, but only for 1
OP and the setting can get lost the first time another OP is selected).

Imho the bootloader should just do what the name suggests: load the
kernel and boot it. In as minimal configuration as possible.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

  reply	other threads:[~2008-08-29 17:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-29 14:56 Pin mux utility? Steve Sakoman
2008-08-29 15:01 ` Gadiyar, Anand
2008-08-29 15:05   ` Steve Sakoman
2008-08-29 15:08     ` Gadiyar, Anand
2008-08-29 17:17 ` David Brownell
2008-08-29 17:21   ` Igor Stoppa [this message]
2008-08-29 18:12     ` David Brownell
2008-09-02 22:51       ` Tony Lindgren

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=1220030469.19671.7.camel@localhost \
    --to=igor.stoppa@nokia.com \
    --cc=david-b@pacbell.net \
    --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