From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: 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>,
linux-embedded@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: Handling of modular boards
Date: Fri, 4 May 2012 23:55:14 +0100 [thread overview]
Message-ID: <20120504225514.GM897@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20120504185850.GO14230@opensource.wolfsonmicro.com>
On Fri, May 04, 2012 at 07:58:51PM +0100, Mark Brown wrote:
> 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.
I don't think its true to say that there's no support for this kind of
thing.
If you're thinking about a motherboard with separate add-on cards, then
you can view the cards as their own separate platform device. Your
platform device driver would be a "whole board driver" responsible
for creating and registering the specific devices found on the board
in its probe function, and unregistering them in the remove function.
This is exactly how I've now setup the Assabet with Neponset daughter
board - all the Neponset devices sit behind the Neponset platform
device, including things like the SA1111 multifunction chip and SMC91x
network interface. I can bind and unbind the Neponset device from its
driver and have everything behind that driver appear and disappear
appropriately - which is useful if your modules can be hotplugged.
It also helps to give the right model to the power management support,
because you're automatically arranging the child devices below the
board-level device, which means all the child devices should be
suspended before the board level device, and the board level device
should be resumed before the child devices.
next prev parent reply other threads:[~2012-05-04 22:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 18:58 Handling of modular boards Mark Brown
2012-05-04 19:34 ` 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 [this message]
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=20120504225514.GM897@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@ardb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).