On Friday 04 May 2012, 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
On Fri, May 04, 2012 at 07:34:08PM +, Arnd Bergmann wrote:
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence of a specific device.
This obviously
Dear Arnd,
In message 201205041934.08830.a...@arndb.de you wrote:
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence of a specific device.
This
On Friday 04 May 2012, Wolfgang Denk wrote:
In message 201205041934.08830.a...@arndb.de you wrote:
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence
Dear Arnd,
In message 201205042039.25794.a...@arndb.de you wrote:
On the other hand, some of the issues we're trying to solve here
for the kernel are also present in the boot loader, so this needs to
do this anyway - whether by inserting new or modifying (enabling or
disabling) existing
On 05/04/2012 02:38 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 4fa432e9.9050...@wwwdotorg.org you wrote:
representation of how to identify the child boards, and then have the
kernel only use/parse certain chunks of the DT based on the ID results.
I expect that this will quickly
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
On Friday 04 May 2012, Wolfgang Denk wrote:
There are systems (and I bet it will be a growing number) where U-Boot
itself uses the DT for configuration. Also, there are functions that
are needed both by the boot loader and the kernel - for example to
dislay a splash screen the boot loader
On 05/04/2012 03:03 PM, Arnd Bergmann wrote:
On Friday 04 May 2012, Wolfgang Denk wrote:
There are systems (and I bet it will be a growing number) where U-Boot
itself uses the DT for configuration. Also, there are functions that
are needed both by the boot loader and the kernel - for example
On Fri, May 04, 2012 at 03:09:19PM -0600, Stephen Warren wrote:
On 05/04/2012 03:03 PM, Arnd Bergmann wrote:
Sure, there are a lot of things that the boot loader can use from the
device tree, but I'm not sure if the LCD panel connection fits into
the same category as the devices that Mark
On Sat, May 05, 2012 at 12:40:57AM +0100, Mark Brown wrote:
On Fri, May 04, 2012 at 11:55:14PM +0100, Russell King - ARM Linux wrote:
On Fri, May 04, 2012 at 07:58:51PM +0100, Mark Brown wrote:
I'm just starting to put some stuff together for this so I was wondering
if anyone had been
On Sat, May 05, 2012 at 12:52:25AM +0100, Russell King - ARM Linux wrote:
How about this - we have struct platform_device_info, which is used to
create platform devices. We can use this as an array to describe what
platform devices to create in the sub-driver, including what the resources
12 matches
Mail list logo
