From: trini@ti•com (Tom Rini)
To: linux-arm-kernel@lists•infradead.org
Subject: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Date: Tue, 17 Jun 2014 08:37:09 -0400 [thread overview]
Message-ID: <53A03675.1000908@ti.com> (raw)
In-Reply-To: <20140617090931.GB3705@n2100.arm.linux.org.uk>
On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote:
> On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
>> Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
>>
>> On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner <jkridner@gmail•com> wrote:
>>> I'd like to discuss moving our current library of cape devicetree
>>> overlay sources into a single tree, including the boot .dtb files for
>>> BeagleBoard.org boards and moving towards enabling as much of the cape
>>> support into a single boot-time .dtb file with an approach similar to
>>> the cape-universal overlay
>>> (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not
>>> in an overlay.
>>>
>>> First of all, I want to note this doesn't change my view on the
>>> importance of mainline support for devicetree overlays. They are still
>>> absolutely critical and highly useful, solving problems that cannot be
>>> solved through boot-time devicetrees. I'm simply looking for an
>>> approach that will complement the availability of overlays and provide
>>> the best user experience.
>
> Here's the most obvious question in the world on this topic. Are capes
> hot-pluggable?
>
> Looking at the posts on google+ from David Anders, they're using pin
> headers for connectivity, with no additional protection against hot-
> plugging, and no sequencing of pin connection. In other words, they are
> not hot-pluggable.
>
> So, why do we need to add a load of infrastructure to the kernel to allow
> the device tree to be modified at run time? At present, the way the
> entire DT infrastructure works is that it assumes the DT remains static
> and never changes - this applies not only to the core DT code, but also
> to all the drivers which have been converted.
>
> So, you're asking for a feature which is impossible to really make use
> of on the hardware which you want to use it.
>
> Why should kernel developers go to the extent of adding support for DT
> modification at runtime when the platform you want this for doesn't even
> support hotplugging of these capes?
>
> The logical way to deal with this is to have the boot loader merge DT
> fragments together before it calls the kernel, so the kernel sees a single
> DT blob which describes the whole hardware.
Frankly, if we're going to push device tree merging to be someone elses
problem, I'd like to push it out to userspace.
> A good way that this could have been done is to put an I2C EEPROM on
> each cape, and have that store the DT fragment. The boot loader could
> have then read that from each cape, and used that information to build
> up the final DT. Why this hasn't been thought of, considering that the
> kernel has been moving towards DT for years, is quite unbelievable.
I had actually talked about this a long while back (face to face) with
people, but the problem was (and still kind of is) the bindings
changing, etc.
--
Tom
next prev parent reply other threads:[~2014-06-17 12:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+T6QP==raXdWz9mezK3JxSvZjWhUZZ7aKv4CpCr0SbdaCMgDQ@mail.gmail.com>
2014-06-11 5:11 ` Unifying cape overlays into boot .dtb for BeagleBoard.org boards Jason Kridner
2014-06-17 7:11 ` Gupta, Pekon
2014-06-17 16:25 ` Jason Kridner
2014-06-18 8:51 ` Gupta, Pekon
2014-06-26 7:50 ` Tony Lindgren
2014-06-26 13:06 ` Tom Rini
2014-06-26 15:27 ` Jason Kridner
2014-06-16 13:22 ` Jason Kridner
2014-06-17 9:09 ` Russell King - ARM Linux
2014-06-17 12:37 ` Tom Rini [this message]
2014-06-17 12:56 ` Russell King - ARM Linux
2014-06-17 14:58 ` Tom Rini
2014-06-17 12:58 ` Matt Porter
2014-06-17 13:15 ` Russell King - ARM Linux
2014-06-17 13:30 ` Matt Porter
2014-06-17 13:32 ` Pantelis Antoniou
2014-06-17 16:01 ` Russell King - ARM Linux
2014-06-17 16:33 ` Jason Kridner
2014-06-17 16:59 ` Pantelis Antoniou
2014-06-17 17:05 ` Russell King - ARM Linux
2014-06-17 17:10 ` Pantelis Antoniou
2014-06-17 17:41 ` Russell King - ARM Linux
2014-06-17 19:24 ` Pantelis Antoniou
2014-06-17 13:45 ` Vladimir Pantelic
2014-06-17 13:50 ` Grant Likely
2014-06-17 14:08 ` Iain Paton
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=53A03675.1000908@ti.com \
--to=trini@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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