All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben@trinity.fluff.org>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org,
	Igor Grinberg <grinberg@compulab.co.il>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@ardb.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Handling of modular boards
Date: Thu, 10 May 2012 11:43:11 +0100	[thread overview]
Message-ID: <20120510104311.GB30103@trinity.fluff.org> (raw)
In-Reply-To: <4FA432E9.9050606@wwwdotorg.org>

On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
> On 05/04/2012 12:58 PM, 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...
> 
> So, I'll respond within the context of device tree, although perhaps you
> were looking for something more general?
> 
> I was just asked basically the same question internally to NVIDIA. One
> option that was floated was to store the device tree in chunks and have
> the bootloader piece them together. You'd start with the DT for the
> basic CPU board, probe what HW was available, and then graft in the
> content of additional DT chunks and pass the final result to the kernel.
> The advantages here are:
> 
> a) The DT is stored in chunks for each plugin board, so there's no bloat
> in the DT that gets passed to the kernel; it contains exactly what's on
> the board.

Interesting, but how does it sort ofu things like mapping GPIO lines from
the add-in board's view to the rest of the system?


-- 
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

WARNING: multiple messages have this Message-ID (diff)
From: ben@trinity.fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: Handling of modular boards
Date: Thu, 10 May 2012 11:43:11 +0100	[thread overview]
Message-ID: <20120510104311.GB30103@trinity.fluff.org> (raw)
In-Reply-To: <4FA432E9.9050606@wwwdotorg.org>

On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
> On 05/04/2012 12:58 PM, 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...
> 
> So, I'll respond within the context of device tree, although perhaps you
> were looking for something more general?
> 
> I was just asked basically the same question internally to NVIDIA. One
> option that was floated was to store the device tree in chunks and have
> the bootloader piece them together. You'd start with the DT for the
> basic CPU board, probe what HW was available, and then graft in the
> content of additional DT chunks and pass the final result to the kernel.
> The advantages here are:
> 
> a) The DT is stored in chunks for each plugin board, so there's no bloat
> in the DT that gets passed to the kernel; it contains exactly what's on
> the board.

Interesting, but how does it sort ofu things like mapping GPIO lines from
the add-in board's view to the rest of the system?


-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

  parent reply	other threads:[~2012-05-10 10:43 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 18:58 Handling of modular boards Mark Brown
2012-05-04 18:58 ` Mark Brown
2012-05-04 19:34 ` Arnd Bergmann
2012-05-04 19:34   ` Arnd Bergmann
2012-05-04 20:07   ` Mark Brown
2012-05-04 20:07     ` Mark Brown
2012-05-04 20:33   ` Wolfgang Denk
2012-05-04 20:33     ` Wolfgang Denk
2012-05-04 20:39     ` Arnd Bergmann
2012-05-04 20:39       ` Arnd Bergmann
2012-05-04 20:54       ` Wolfgang Denk
2012-05-04 20:54         ` Wolfgang Denk
2012-05-04 21:03         ` Arnd Bergmann
2012-05-04 21:03           ` Arnd Bergmann
2012-05-04 21:09           ` Stephen Warren
2012-05-04 21:09             ` Stephen Warren
2012-05-04 21:52             ` Mark Brown
2012-05-04 21:52               ` Mark Brown
2012-05-04 22:09     ` Mark Brown
2012-05-04 22:09       ` Mark Brown
2012-05-10 10:41       ` Ben Dooks
2012-05-10 10:41         ` Ben Dooks
2012-05-10 12:40       ` Igor Grinberg
2012-05-10 12:40         ` Igor Grinberg
2012-05-10 16:15         ` Stephen Warren
2012-05-10 16:15           ` Stephen Warren
2012-05-11  6:15           ` Igor Grinberg
2012-05-11  6:15             ` Igor Grinberg
2012-05-08 12:26   ` Linus Walleij
2012-05-08 12:26     ` Linus Walleij
2012-05-09 17:12     ` Mark Brown
2012-05-09 17:12       ` Mark Brown
2012-05-04 19:50 ` Stephen Warren
2012-05-04 19:50   ` Stephen Warren
2012-05-04 20:38   ` Wolfgang Denk
2012-05-04 20:38     ` Wolfgang Denk
2012-05-04 20:59     ` Stephen Warren
2012-05-04 20:59       ` Stephen Warren
2012-05-04 20:44   ` Mark Brown
2012-05-04 20:44     ` Mark Brown
2012-05-04 20:44     ` Mark Brown
2012-05-08 12:33     ` Linus Walleij
2012-05-08 12:33       ` Linus Walleij
2012-05-09  8:41       ` Alessandro Rubini
2012-05-09  8:41         ` Alessandro Rubini
2012-05-10 10:43   ` Ben Dooks [this message]
2012-05-10 10:43     ` Ben Dooks
2012-05-10 16:11     ` Stephen Warren
2012-05-10 16:11       ` Stephen Warren
2012-05-04 22:55 ` Russell King - ARM Linux
2012-05-04 22:55   ` Russell King - ARM Linux
2012-05-04 23:40   ` Mark Brown
2012-05-04 23:40     ` Mark Brown
2012-05-04 23:52     ` Russell King - ARM Linux
2012-05-04 23:52       ` Russell King - ARM Linux
2012-05-05  0:03       ` Mark Brown
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=20120510104311.GB30103@trinity.fluff.org \
    --to=ben@trinity.fluff.org \
    --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 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.