From: david.jander@protonic.nl (David Jander)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM Machine SoC I/O setup and PAD initialization code
Date: Wed, 21 Jul 2010 10:29:29 +0200 [thread overview]
Message-ID: <201007211029.29529.david.jander@protonic.nl> (raw)
Hi all,
Having some experience with powerpc linux and being fairly new to ARM, I
wonder about the following I have observed on ARM-linux so far:
General machine initialization like I/O-multiplexing and I/O-pad setup seems
to be done twice most of the time: Once in the bootloader (i.e. u-boot), and
once in the machine support file in the linux kernel. This seems awfully
redundant and error-prone to me. Why is it like this?
Shouldn't I/O-pad setup and such stuff be duty of the bootloader alone? Why do
I see so much platform setup code in the linux kernel that repeats this?
For example:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
#define MX51_UART1_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_PKE | PAD_CTL_PUE | \
PAD_CTL_DSE_HIGH)
...
IMHO this shouldn't be in the kernel, much less in this place. This define
assumes somehow that on every i.MX51 based board I should configure any UART1
pad as having high drive-strength and a pull-up. What drive strength the pad
should have is a decision that the board hardware-designer must make
individually for each board and pin of the UART. It cannot be something as
generic as to put it into such a header-file. The kernel definitely shouldn't
mess with those things.
So, why is it done like this?
Is it historically grown like this, and has noone yet had the time to fix
this?
Or is it that boot-loaders on ARM in general don't do hardware setup correctly
so that it has to be re-done in the kernel? What about fixing bootloaders
then?
Best regards,
--
David Jander
Protonic Holland.
next reply other threads:[~2010-07-21 8:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 8:29 David Jander [this message]
2010-07-21 8:47 ` ARM Machine SoC I/O setup and PAD initialization code Russell King - ARM Linux
2010-07-22 2:32 ` Simon Horman
2010-07-22 7:20 ` Russell King - ARM Linux
2010-07-22 7:29 ` Simon Horman
2010-07-22 8:38 ` Magnus Damm
2010-07-22 8:49 ` Eric Miao
2010-07-22 9:01 ` Magnus Damm
2010-07-22 9:02 ` Russell King - ARM Linux
2010-07-22 8:46 ` Russell King - ARM Linux
2010-07-22 9:14 ` Simon Horman
2010-07-24 21:36 ` Grant Likely
2010-07-22 8:16 ` Magnus Damm
2010-07-22 12:10 ` David Jander
2010-07-22 12:35 ` Russell King - ARM Linux
2010-07-22 12:56 ` Mark Brown
2010-07-22 13:31 ` David Jander
2010-07-22 13:54 ` Russell King - ARM Linux
2010-07-23 10:35 ` David Jander
2010-07-23 13:02 ` Russell King - ARM Linux
2010-07-22 14:20 ` Mark Brown
2010-07-23 10:18 ` David Jander
2010-07-23 12:57 ` Russell King - ARM Linux
2010-07-23 14:17 ` Mark Brown
2010-07-23 18:38 ` david at protonic.nl
2010-07-23 19:59 ` Jason McMullan
2010-07-23 21:03 ` Robert Schwebel
2010-07-26 1:37 ` Magnus Damm
2010-07-26 6:56 ` Robert Schwebel
2010-07-24 18:50 ` Mark Brown
2010-07-22 15:00 ` Nicolas Pitre
2010-07-23 10:31 ` David Jander
2010-07-22 13:41 ` Rob Herring
2010-07-22 21:20 ` Linus Walleij
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=201007211029.29529.david.jander@protonic.nl \
--to=david.jander@protonic.nl \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.