From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Samuel Ortiz <sameo@linux.intel.com>,
Arnd Bergmann <arnd@ardb.de>, Olof Johansson <olof@lixom.net>,
Stephen Warren <swarren@wwwdotorg.org>,
Igor Grinberg <grinberg@compulab.co.il>
Cc: linux-arm-kernel@lists.infradead.org,
linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Handling of modular boards
Date: Fri, 4 May 2012 19:58:51 +0100 [thread overview]
Message-ID: <20120504185850.GO14230@opensource.wolfsonmicro.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
Quite a few reference platforms (including Wolfson ones, which is why
I'm particularly interested) use replaceable modules to allow
configuration changes. Since we can often identify the configuration at
runtime we should ideally do that but currently there's no infrastructure
to help with that, generally this seems to be done in arch code for the
machine but this doesn't scale when even the CPU might change and isn't
terribly device tree compatible either.
For reference the code for current Wolfson plugin modules is in
arch/arm/mach-s3c64xx/mach-crag6410-module.c.
The most obvious current fit here is the MFD subsystem but it feels like
we need some slightly different infastructure to what MFD currently
provides. MFD is really set up to handle platform devices with a core
and linear ranges of resources fanning out from that core since they're
really oriented around chips. In contrast these boards are more about
remapping random collections of potentially unrelated resources and
instantiating devices on all sorts of buses and share more with board
files.
I'm just starting to put some stuff together for this so I was wondering
if anyone had been thinking about this and had any bright ideas for how
to handle it, and also if people think that MFD is a good fit for this
or if we should split the silicon MFDs from these PCBs.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next reply other threads:[~2012-05-04 18:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 18:58 Mark Brown [this message]
2012-05-04 19:34 ` Handling of modular boards Arnd Bergmann
2012-05-04 20:07 ` Mark Brown
2012-05-04 20:33 ` Wolfgang Denk
2012-05-04 20:39 ` Arnd Bergmann
2012-05-04 20:54 ` Wolfgang Denk
2012-05-04 21:03 ` Arnd Bergmann
2012-05-04 21:09 ` Stephen Warren
2012-05-04 21:52 ` Mark Brown
2012-05-04 22:09 ` Mark Brown
2012-05-10 10:41 ` Ben Dooks
2012-05-10 12:40 ` Igor Grinberg
2012-05-10 16:15 ` Stephen Warren
2012-05-11 6:15 ` Igor Grinberg
2012-05-08 12:26 ` Linus Walleij
2012-05-09 17:12 ` Mark Brown
2012-05-04 19:50 ` Stephen Warren
2012-05-04 20:38 ` Wolfgang Denk
2012-05-04 20:59 ` Stephen Warren
2012-05-04 20:44 ` Mark Brown
2012-05-08 12:33 ` Linus Walleij
2012-05-09 8:41 ` Alessandro Rubini
2012-05-10 10:43 ` Ben Dooks
2012-05-10 16:11 ` Stephen Warren
2012-05-04 22:55 ` Russell King - ARM Linux
2012-05-04 23:40 ` Mark Brown
2012-05-04 23:52 ` Russell King - ARM Linux
2012-05-05 0:03 ` Mark Brown
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=20120504185850.GO14230@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=arnd@ardb.de \
--cc=grinberg@compulab.co.il \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=sameo@linux.intel.com \
--cc=swarren@wwwdotorg.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).