From: Alessandro Rubini <rubini@gnudd.com>
To: hpa@zytor.com
Cc: linux-kernel@vger.kernel.org, giancarlo.asnaghi@st.com,
alan@linux.intel.com, tglx@linutronix.de, mingo@redhat.com,
sameo@linux.intel.com, x86@kernel.org
Subject: Re: [PATCH] x86/platform: sta2x11: add platform code
Date: Tue, 29 May 2012 09:05:57 +0200 [thread overview]
Message-ID: <20120529070557.GA23373@mail.gnudd.com> (raw)
In-Reply-To: <4FC47003.1080906@zytor.com>
> We have two mechanisms for parameterizing this kind of information: ACPI
> 5 (which can be considered the "native" method on x86) or flattened
> device tree (as already used by the CE4100 platform.) Keep in mind that
> an explicit goal for Linux/x86 is that the same kernel should boot on
> all platforms, and backsliding on that is not acceptable.
Yes, it indeed does (the original code I received did not, but mine
doesn't break stuff for other systems). What I posted uses a kernel
command-line argument to tell what board it is: the sta2x11 is the
computer's chipset in most cases, so it should know the wiring soon.
> The best is for the firmware on your platforms to provide the ACPI or
> DTB information, as it should. If it doesn't, it gets nastier, but
> there is absolutely no way we are going into the ARM swamp of having
> different kernels for different boards.
It doesn't. I'm currently developing using an add-on pci card running
on a more conventional computer (and there you may object it is not
even x86-specific, actually I'd love to see it sold as a separate card
for industrial use).
In short, the whole thing is about passing different platform data
according to which card it is (which includes the DMA configuration
for uart ports, the card-detect pin for mmci etc). Most such drivers
are already in the kernel and we are reusing them -- whereas original
code I got rewrote them all from scratch. But for this we need to pass
the platform data.
I'm pretty sure we don't have ACPI, and I'd avoid device tree if
possible (especially thinking of add-on cards). If you think it makes
more sense, I can offer the code to drivers/pci or other more generic
places.
thanks
/alessandro
next prev parent reply other threads:[~2012-05-29 7:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-27 20:50 [PATCH] x86/platform: sta2x11: add platform code Alessandro Rubini
2012-05-28 23:38 ` H. Peter Anvin
2012-05-29 6:37 ` Alessandro Rubini
2012-05-29 6:43 ` H. Peter Anvin
2012-05-29 7:05 ` Alessandro Rubini [this message]
2012-05-29 7:15 ` H. Peter Anvin
2012-05-29 7:34 ` Alessandro Rubini
2012-05-29 7:39 ` H. Peter Anvin
2012-06-04 10:16 ` Benjamin Herrenschmidt
2012-06-04 10:21 ` Alessandro Rubini
2012-05-29 7:44 ` Alessandro Rubini
2012-06-04 10:17 ` Benjamin Herrenschmidt
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=20120529070557.GA23373@mail.gnudd.com \
--to=rubini@gnudd.com \
--cc=alan@linux.intel.com \
--cc=giancarlo.asnaghi@st.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sameo@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).