Unifying cape overlays into boot .dtb for BeagleBoard.org boards

[Jason Kridner]

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.

Robert has been talking about the actions required to clean-up Debian
Jessie support in another thread
(https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ)
and I suggested we should add a bit of a detour by cleaning up the
cape support for the mainline kernel and switching away our primary
process of supporting capes from using overlays to using a single
devicetree file provided at boot. I promised a pull-request and hadn't
gotten around to sending it until now (below). No architecture changes
have been made in my pull-request, just bringing in the kernel
devicetree source history. This suggestion is based on several
assumptions, any number of which might be wrong.

The assumptions (for which I'm looking for feedback/corrections):
* The overlays pretty much all need to be compiled into the kernel if
they are going to be loaded using kernel command-line arguments or
/etc/capemgr for the majority of distros. While many cape devicetree
use cases are perfectly happy with loading at run-time rather than
boot-time, it seems there should be a mechanism for pushing cape
support into the category of being available at boot-time across
distributions.
* The devicetree sources, including the primary boot .dts files, will
eventually be removed from the kernel source tree. I'm not too sure if
and when it'll really happen, but starting up a project to maintain
the definitive beagleboard.org board devicetree files outside the
kernel seems to make sense. Given the interdependency of the boot .dtb
and the overlay .dtbo files, combining them into a single repository
where every distribution can pick them up seems like a natural and
obvious choice. There are of course some dependencies on kernel
versions, but I believe most of those have settled out by now and we
should be OK moving forward.
* There seems to be little or no interest in my previous proposal to
use cape EEPROMs to store the overlay fragments. Given some churn in
the devicetree node definitions, it is likely this would have failed
in bad ways anyway. It seems mostly reasonable to expect users to
update their kernel and firmware to gain support for new add-on
hardware and we mostly try to avoid regressions (with the seemingly
ever-living exception of 3D graphics support), so I think I'm better
aligned with the community to drop my older suggestion. Some people,
including CircuitCo, are building capes without configuration EEPROMs
now, so a different recommended mechanism seems like a requirement.
* With the patches in our vendor 3.8 kernels and with all recent
mainline kernels, performing userspace muxing operations has become
easy again. It seems to be possible to turn on drivers not currently
in use without an unacceptable level of bloat or conflict. This has
been partially proven out using Charles' universal cape
(https://github.com/cdsteinkuehler/beaglebone-universal-io), though I
still have some concerns about conflicts. The result might be that
there is still some number of overlays, but the approach of minimizing
the overlays and instead relying on the existing loading/unloading
mechanisms of the mainline drivers as much as possible feels right to
me.
* It will still be some time before devicetree overlay support is
adopted in the mainline kernel. While I still see a strong need to
have devicetree overlay support and CapeMgr in the mainline, the
desire here is to optimize the user experience in the shortest term
possible. Users get really confused by the errors that get generated
by loading incorrect devicetree overlays and it is always nice when
you can avoid confusing users.

My suggestion is:
* Maintain the source for .dtb and .dtbo files for all BeagleBoard.org
boards at http://github.com/beagleboard/devicetree-source, overriding
the sources in the mainline kernel when performing kernel builds. We
can host pre-built .dtb and .dtbo files at a normailzed location
outside the source repository for those that don't want to perform the
builds, since I don't believe the binary format is changing any time
soon other than the overlay support we utilize. Any patches accepted
into mainline as long as these files still exist there as well should
be merged to try to keep these in-line as long as possible,
anticipating eventual removal from mainline.
* Have cape makers submit pull requests to have their cape enabled in
the single boot-time devicetree overlay for each board they support.
The base drivers should be enabled at the earliest point where they
don't cause a conflict, minimizing what gets put into their overlays.
The final mux configuration and other points of conflict should be
kept in a board-specific overlay to make that configuration available
at boot. If the cape is disabled on the kernel command-line, the
kernel doesn't include CapeMgr support, or the board doesn't include a
configuration EEPROM, users would still have the ability to perform
run-time userspace mux configuration without CapeMgr unless
conflicting drivers need to be loaded.

Alternatively, if we don't think this is where things belong, perhaps
we could try to move all of this into the u-boot sources, though
people using other bootloaders might not find this the most useful
approach.

The pull request for http://github.com/beagleboard/devicetree-source:

The following changes since commit a524bf5d5e173795ce4cb214280f304588b1d78d:

capes: add BB-VIEW-LCD4-01-00A0 & BB-VIEW-LCD7-01-00A0 (2014-05-29
15:59:31 -0500)

are available in the git repository at:

g...@github.com:jadonk/cape-firmware master

for you to fetch changes up to 9de20db80056b72d6e1f61b68447ba8f2d12cf9c:

Beagle DTS: remove deleted files from Makefile (2014-06-02 12:35:28 -0400)

----------------------------------------------------------------

[...] Too many changes to list bringing in kernel history.

[Jason Kridner]

Adding devicetree and linux-arm-kernel lists based on feedback on IRC...

[Jason Kridner]

Adding devicetree and linux-arm-kernel lists based on feedback on IRC...

On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner <jkri...@gmail.com> wrote:

[Jason Kridner]

Adding devicetree and linux-arm-kernel lists based on feedback on IRC...

On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner <jkri...@gmail.com> wrote:

[Tom Rini]

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 <jkri...@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

[Vladimir Pantelic]

On 06/17/2014 11:09 AM, Russell King - ARM Linux wrote:

> Here's the most obvious question in the world on this topic. Are capes
> hot-pluggable?

"capes" as in Beaglebone capes might not be due to the mechanical
constraints you listed.

"capes" as a concept of pluggable hardware might well be. here is a real
world example of commercially available pluggable hardware add-ons on a
Linux system back from 2008:

http://en.wikipedia.org/wiki/Archos_Generation_6#Accessories

depending on the add-on, different interfaces like GPIO, UART, USB, SPI
using the same pins were used and there was no reboot needed to load a
new hardware configuration or change the pinmux

[Iain Paton]

On 17/06/14 10:09, Russell King - ARM Linux wrote:

> 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?

I'm not convinced you should, but Grant Likely seemed to be much more open
to the idea with the latest attempt https://lkml.org/lkml/2014/5/29/586

> 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 believe that was Jasons original idea.

From a users perspective, a fixed DT fragment in EEPROM quickly ends up
being out of step with OS implementation and simply becomes another
pain point that needs worked around.

Anyway, there already exist capes in large scale production that don't
have the EEPROM. As well as ones that use the required I2C bus for other
purposes, thereby blocking all other capes connected at the same time
from using that mechanism even when they are capable of doing so.
Not forgetting the number of capes that have shipped already without the
DT fragment in their EEPROMS.

Too late to shut the barn door, question is where to go from here.

Consolidation the dt knowledge in one tree is a good idea, regardless of
how it's eventually used.

[Pantelis Antoniou]

Hi Russell,

CCing gcl.

On Jun 17, 2014, at 4:15 PM, Russell King - ARM Linux wrote:

> On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote:

>> On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
>>> 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?
>>

>> It's important to note that Jason's use case is not the real one driving
>> runtime DT modification. You'll have to go back to threads like
>> https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
>> hashed out. The clearest use cases are the FPGA folks that are loading
>> their bitstream from userspace and due to DT-everywhere also need to
>> initiate runtime modification of the live DT tree from userspace.
>> There's a lot of discussion over many threads where this has been
>> debated.
>
> Okay, so it was debated, and the outcome of that debate has been... no
> change. That's probably because it is an incredible amount of work to
> achieve it, and none of the overloaded DT maintainers (who don't have
> enough time to review new bindings) have any intention of putting their
> precious resources towards it.
>

Wait, wait wait. Who said there's no progress there. We're already proceeding
in that direction.

Apparently you are not aware that runtime modification of DT is part of the
DT capabilities since a few years back, as normally used on pSeries class
of machines.

The overlays are a method of having a sane, easy to use method for reconfigurable
hardware.

> From my rudimentary understanding of the OF code, it seems to mean that
> the way devices are created from the parsed OF tree structures (the
> device_node structures) needs to change such that when an OF tree node
> is removed, its corresponding device is also removed. This probably
> needs a struct device pointer in the device_node struct.
>
> Then there needs to be support to modify the parsed OF tree (not only
> to add nodes but also to remove nodes) and do the right thing when a
> node is added and/or removed.
>

Already done.

> However, there's harder cases to solve. There's several instances where
> device nodes do not correspond with a struct device, and these nodes are
> parsed by the driver. Such things as the of_graph stuff, which describes
> the inter-connectivity of a display subsystem or v4l2 subsystem. The
> nodes may be specified, but the target device for one of the links may
> be disabled at original probe time, but later becomes enabled via
> modification - this is one of the difficult cases since it needs the
> driver to cooperate with the change, and there's no existing way to
> notify it of that change.
>

Actually there is, and we're working on making a generic method of handling
all these cases.

Hint, take a look at of_reconfig_notifier_register please.

> As with any kernel change, it needs people to write code. If no one writes
> code, no change happens. Endlessly discussing it on mailing lists does not
> result in code being written.
>

The code is already written. If you have any specific objections to the patchset
I've already posted, comments are welcome.

> However, going back to the original stated platform - none of this
> complexity is required there. Once power is applied, the platform
> hardware configuration is fixed (unless you want to yank a board off
> and risk destroying the hardware in doing so.) So, if Jason's interest
> is in the capes, then the simplest and easiest approach is to have the
> boot loader deal with it. If it's about FPGAs and dynamically loading
> bitstreams into them, then maybe a dynamic device tree is the answer -
> but /someone/ then has to create patches to achieve that. If no one is
> willing to create those patches, then forget the idea of a dynamic
> device tree, because it won't happen on its own.
>

The complexity is absolutely required, and it has nothing to do with beaglebone
capes.

The fact of the matter is that reconfigurable hardware is here, on shipping system,
and we, as the linux kernel community have to make sure it works, and that it works in
a sane way.


> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

Regards

-- Pantelis

[Grant Likely]

On Tue, 17 Jun 2014 10:09:31 +0100, Russell King - ARM Linux <li...@arm.linux.org.uk> 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 <jkri...@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.

As others have pointed out, capes aren't the only use case. pseries
already modifies the tree at runtime, and the FPGA users want the
ability to add/remove additional DT blocks. I've also heard from
hobbiest/maker developers that by deferring the load of additional data
to userspace means they don't need to mess with the boot path once it is
working. The feature is coming.

g.

[Matt Porter]

On Tue, Jun 17, 2014 at 02:15:22PM +0100, Russell King wrote:
> On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote:
> > On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote:
> > > 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?
> >
> > It's important to note that Jason's use case is not the real one driving
> > runtime DT modification. You'll have to go back to threads like
> > https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
> > hashed out. The clearest use cases are the FPGA folks that are loading
> > their bitstream from userspace and due to DT-everywhere also need to
> > initiate runtime modification of the live DT tree from userspace.
> > There's a lot of discussion over many threads where this has been
> > debated.
>
> Okay, so it was debated, and the outcome of that debate has been... no
> change. That's probably because it is an incredible amount of work to
> achieve it, and none of the overloaded DT maintainers (who don't have
> enough time to review new bindings) have any intention of putting their
> precious resources towards it.

I don't believe this is completely true. Pantelis and Grant are working
together on getting DT overlays upstream. It's pretty far along. It
doesn't mean there aren't serious issues with the way the DT core code
was implement assuming it would be static.

> From my rudimentary understanding of the OF code, it seems to mean that
> the way devices are created from the parsed OF tree structures (the
> device_node structures) needs to change such that when an OF tree node
> is removed, its corresponding device is also removed. This probably
> needs a struct device pointer in the device_node struct.
>
> Then there needs to be support to modify the parsed OF tree (not only
> to add nodes but also to remove nodes) and do the right thing when a
> node is added and/or removed.
>

> However, there's harder cases to solve. There's several instances where
> device nodes do not correspond with a struct device, and these nodes are
> parsed by the driver. Such things as the of_graph stuff, which describes
> the inter-connectivity of a display subsystem or v4l2 subsystem. The
> nodes may be specified, but the target device for one of the links may
> be disabled at original probe time, but later becomes enabled via
> modification - this is one of the difficult cases since it needs the
> driver to cooperate with the change, and there's no existing way to
> notify it of that change.
>

> As with any kernel change, it needs people to write code. If no one writes
> code, no change happens. Endlessly discussing it on mailing lists does not
> result in code being written.

Yes, I suppose you missed the active work on the DT overlay series. As I
mentioned, there's active development on these things. There's also
active discussion on some of the challenges.

> However, going back to the original stated platform - none of this
> complexity is required there. Once power is applied, the platform
> hardware configuration is fixed (unless you want to yank a board off
> and risk destroying the hardware in doing so.) So, if Jason's interest
> is in the capes, then the simplest and easiest approach is to have the
> boot loader deal with it. If it's about FPGAs and dynamically loading
> bitstreams into them, then maybe a dynamic device tree is the answer -
> but /someone/ then has to create patches to achieve that. If no one is
> willing to create those patches, then forget the idea of a dynamic
> device tree, because it won't happen on its own.

https://lkml.org/lkml/2014/5/28/280

-Matt

[Matt Porter]

On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King 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 <jkri...@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?

It's important to note that Jason's use case is not the real one driving
runtime DT modification. You'll have to go back to threads like
https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all
hashed out. The clearest use cases are the FPGA folks that are loading
their bitstream from userspace and due to DT-everywhere also need to
initiate runtime modification of the live DT tree from userspace.
There's a lot of discussion over many threads where this has been
debated.

-Matt

[Russell King - ARM Linux]

On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote:

Okay, so it was debated, and the outcome of that debate has been... no
change. That's probably because it is an incredible amount of work to
achieve it, and none of the overloaded DT maintainers (who don't have
enough time to review new bindings) have any intention of putting their
precious resources towards it.

From my rudimentary understanding of the OF code, it seems to mean that
the way devices are created from the parsed OF tree structures (the
device_node structures) needs to change such that when an OF tree node
is removed, its corresponding device is also removed. This probably
needs a struct device pointer in the device_node struct.

Then there needs to be support to modify the parsed OF tree (not only
to add nodes but also to remove nodes) and do the right thing when a
node is added and/or removed.

However, there's harder cases to solve. There's several instances where
device nodes do not correspond with a struct device, and these nodes are
parsed by the driver. Such things as the of_graph stuff, which describes
the inter-connectivity of a display subsystem or v4l2 subsystem. The
nodes may be specified, but the target device for one of the links may
be disabled at original probe time, but later becomes enabled via
modification - this is one of the difficult cases since it needs the
driver to cooperate with the change, and there's no existing way to
notify it of that change.

As with any kernel change, it needs people to write code. If no one writes
code, no change happens. Endlessly discussing it on mailing lists does not
result in code being written.

However, going back to the original stated platform - none of this
complexity is required there. Once power is applied, the platform
hardware configuration is fixed (unless you want to yank a board off
and risk destroying the hardware in doing so.) So, if Jason's interest
is in the capes, then the simplest and easiest approach is to have the
boot loader deal with it. If it's about FPGAs and dynamically loading
bitstreams into them, then maybe a dynamic device tree is the answer -
but /someone/ then has to create patches to achieve that. If no one is
willing to create those patches, then forget the idea of a dynamic
device tree, because it won't happen on its own.

[Russell King - ARM Linux]

And that's a strong argument for having stable bindings - or at the
very least, ensuring that new bindings which are compatible with older
versions.

We all know how to deal with this, we've had these discussions frequently
with the same outcomes. It's really not something that needs discussing
yet again, just to reach the same conclusions.

Look, go back to the x86 model. Why does the kernel run on virtually
any x86 computer there (firmware bugs not withstanding)? It's not only
because the platform is mostly standardised, but also because it's
standardised at the firmware (BIOS) level as well. So there's standard
ways to find out what hardware is fitted, standard ways to find out how
it's wired up (eg, which interrupts) and such like.

Like it or not, with ARM64 moving into the server space, and (I believe)
we're saying that we want FDT inside ACPI - well, as soon as you go down
that path on servers, FDT _has_ to be standardised and stable. Server
space will /not/ stand having to update the FDT in firmware for each
incremental kernel version change, just because we've decided to change
the bindings.

Exactly the same should start applying here. Yes, we may not want bindings
to be entirely frozen, but when we /do/ change them, we must change them
in a way that is compatible with the old bindings.

Like, for instance, the iMX AHCI driver that I've had for the last five
months patches to fix the incomplete DT bindings for: we have platforms
using it which have hard-coded non-hardware default parameters into the
driver. I need different hardware parameters for it to come close to
working on my hardware, so when introducing new properties for these, I
_must_ ensure that when these properties are not specified (as they aren't
for the existing platforms using the driver) that their non-hardware
default values are used. This even means providing negative options to
_disable_ features on the interface, because providing positive "enable
this feature" options would mean that their bindings break.

This is not rocket science.

[Russell King - ARM Linux]

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 <jkri...@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.

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'm quite sure you're going to say that that introduces additional
hardware expense. Yes it does, but it also eliminates the problem you
are now bringing up.

[Gupta, Pekon]

Hi Jason,

+1
Yes, moving cape DTS out of kernel tree should help developers.
There are quite a few cape patches floating in mail-lists, but as cape
DTS is still not accepted in mainline so they get lost and forgotten.
So one place for collecting all this is a good idea.


However, somehow the universal I/O DTS looked seemed complicated:
(1)
All capes work standalone, but due to share pin-mux some cape
combinations cannot be used simultaneously. But most users of
BeagleBone are already well-versed with DT and kernel infrastructure,
so they need not be spoon fed to get a out-of-box working solution
for each combination. If there is proper documentation is available
about compatibility of capes with each other, then users will figure
out themselves.

(2)
Also, there was a talk of enabling and disabling DT fragments via u-boot.
That should also be explored instead of complicating cape DTS.

(3)
BeagleBone community and outside are coming out with new featured
capes, which might possess a challenge to get a absolute non-conflicting
universal I/O DTS. What might be working today might have conflicts
tomorrow with introduction of new capes.
We should be open to be compatible to capes developed outside
Beaglebone.org. In my view this is important for longer term.
Example: http://valentfx.com/logi-bone/

So, plz review my feedback and if you plan to create an external tree
for beaglebone Capes, I would be happy to submit some cape patches.


with regards, pekon

[Tom Rini]

On 06/17/2014 08:56 AM, Russell King - ARM Linux wrote:
> On Tue, Jun 17, 2014 at 08:37:09AM -0400, Tom Rini wrote:
>> On 06/17/2014 05:09 AM, Russell King - ARM Linux wrote:
>>> 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.
>
> And that's a strong argument for having stable bindings - or at the
> very least, ensuring that new bindings which are compatible with older
> versions.

Yes. This was a few years back (a bit before the first beaglebone was
public) so before we had really pushed up on some level of binding
stability.

--
Tom

[Jason Kridner]

I think you have too much confidence in users. If this doesn't hurt
power users, then why is it bad have an option to spoon feed? This
doesn't prevent anyone with knowledge of DT from doing their own
thing.

>
> (2)
> Also, there was a talk of enabling and disabling DT fragments via u-boot.
> That should also be explored instead of complicating cape DTS.

Link? Relevance?

>
> (3)
> BeagleBone community and outside are coming out with new featured
> capes, which might possess a challenge to get a absolute non-conflicting
> universal I/O DTS. What might be working today might have conflicts
> tomorrow with introduction of new capes.
> We should be open to be compatible to capes developed outside
> Beaglebone.org. In my view this is important for longer term.
> Example: http://valentfx.com/logi-bone/

The tree isn't only for beagleboard.org, but anyone building add-on
boards for beagleboard.org boards. In fact, there are 0 official
add-on boards from beagleboard.org as of now. CircuitCo makes a bunch
and I believe there are some coming from TI soon, but there are none
from beagleboard.org itself and most capes come from other parties.
Registry is at http://beaglebonecapes.com and
http://beagleboard.org/cape.

>
> So, plz review my feedback and if you plan to create an external tree
> for beaglebone Capes, I would be happy to submit some cape patches.

Great. https://github.com/beagleboard/devicetree-source

>
>
> with regards, pekon

[Jason Kridner]

On Tue, Jun 17, 2014 at 12:01 PM, Russell King - ARM Linux
<li...@arm.linux.org.uk> wrote:

> On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote:
>> The complexity is absolutely required, and it has nothing to do with
>> beaglebone capes.
>>
>> The fact of the matter is that reconfigurable hardware is here, on
>> shipping system, and we, as the linux kernel community have to make
>> sure it works, and that it works in a sane way.
>

> Right, so looking back in the git history, this project has been going
> on for... at least four years? Probably longer than the length of time
> that we've been converting ARM to DT. At no point during that has anyone
> brought up the issue of DT being dynamic, so none of the drivers which
> we have been converting caters for this.
>
> Isn't this a bit of a missed opportunity, if this is a direction that
> OF wishes to head towards?

I believe it absolutely is a missed opportunity, but that doesn't mean
it isn't still needed moving forward. We've been using overlays
successfully in the BeagleBoard.org community on BeagleBone Black for
over a year now. It is just a shame we're still shipping a 3.8 kernel.
This universal overlay provides hope to support most add-ons, but it
doesn't address the dynamic nature of some add-on hardware. It is
certainly my hope that this effort doesn't derail the overlay
development work.

>
> Wouldn't it have been relevant to the discussion at kernel summit too,
> concerning DRM/v4l2/componentised systems? What if someone comes along
> tomorrow with part of their multimedia based system inside a FPGA
> which they program up at runtime?

[Russell King - ARM Linux]

On Tue, Jun 17, 2014 at 08:10:46PM +0300, Pantelis Antoniou wrote:
> Hi Russell,
>
> On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:
> > DRM is not hotpluggable in any shape or form, and David Airlie has
> > indicated that he does strongly opposes moving it in that direction.
> >
> > DRM follows the "card" model, where, at probe time, the hardware is
> > known and never changes until the "card" is torn down. No new
> > connectors can be added once the "card" is initialised, and no
> > connectors can be removed. Any changes must be done by tearing down
> > the entire card and reconstructing it (if reconstructing it with a
> > reduced set of hardware is appropriate.)
> >
>
> That is a limitation of the current DRM implementation.

... an implementation which isn't going to change any time soon... and
certainly is not going to change because someone comes along with a
dynamic DT infrastructure.

> I seems to be this is born out of some kind of misunderstanding about how
> DT can (and does) support dynamic changes.
>
> I admit that I haven't done much work on DRM (besides some tinkering with
> Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic
> change notifier support, perhaps it can be made to work.

It can be made to work in the way that I described above - any change
to the hardware which makes up a DRM card would need the entire DRM
card torn down and re-created... as I said above.

The reason I know this is because I've been involved closely in dealing
with imx-drm, and Armada DRM, and the mess that people spew trying to
get their DT representations of their hardware (as multiple, separate
devices which can be probed asynchronously) to work with DT.

If DRM supported hot-plugging of components, dealing with that would
be much easier than it is, but - as I said above - this is not going
to happen. So, if it's not going to happen for the case which we
commonly find on ARM hardware today, it's certainly not going to
happen because DT wants to become dynamic.

> As I said, the next thing coming is transactional DT support, perhaps you
> can share the DT fragment describing your use-case (before/after) and
> I'll try to accommodate in the next patch series.

I don't have any - I'm using it as an example where a device (such as
the iMX6 SoC) which has quite a complex media infrastructure may be
extended externally via an FPGA to provide additional interfaces which
may then require dynamic changes to the DT description, thereby meaning
that we have to reconstruct the DRM "card" in its entirety.

If you want some DT to look at...

ldb: ldb@020e0008 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
gpr = <&gpr>;
status = "disabled";

lvds-channel@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
status = "disabled";

port@0 {
reg = <0>;

lvds0_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds0>;
};
};

port@1 {
reg = <1>;

lvds0_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds0>;
};
};
};

lvds-channel@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
status = "disabled";

port@0 {
reg = <0>;

lvds1_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_lvds1>;
};
};

port@1 {
reg = <1>;

lvds1_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_lvds1>;
};
};
};
};

hdmi: hdmi@0120000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x00120000 0x9000>;
interrupts = <0 115 0x04>;
gpr = <&gpr>;
clocks = <&clks 123>, <&clks 124>;
clock-names = "iahb", "isfr";
status = "disabled";

port@0 {
reg = <0>;

hdmi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_hdmi>;
};
};

port@1 {
reg = <1>;

hdmi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_hdmi>;
};
};
};

mipi_dsi: mipi@021e0000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x021e0000 0x4000>;
status = "disabled";

port@0 {
reg = <0>;

mipi_mux_0: endpoint {
remote-endpoint = <&ipu1_di0_mipi>;
};
};

port@1 {
reg = <1>;

mipi_mux_1: endpoint {
remote-endpoint = <&ipu1_di1_mipi>;
};
};
};

ipu1: ipu@02400000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-ipu";
reg = <0x02400000 0x400000>;
interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>,
<0 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 130>, <&clks 131>, <&clks 132>;
clock-names = "bus", "di0", "di1";
resets = <&src 2>;

ipu1_di0: port@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;

ipu1_di0_disp0: endpoint@0 {
};

ipu1_di0_hdmi: endpoint@1 {
remote-endpoint = <&hdmi_mux_0>;
};

ipu1_di0_mipi: endpoint@2 {
remote-endpoint = <&mipi_mux_0>;
};

ipu1_di0_lvds0: endpoint@3 {
remote-endpoint = <&lvds0_mux_0>;
};

ipu1_di0_lvds1: endpoint@4 {
remote-endpoint = <&lvds1_mux_0>;
};
};

ipu1_di0_lvds1: endpoint@4 {
remote-endpoint = <&lvds1_mux_0>;
};
};

ipu1_di1: port@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;

ipu1_di0_disp1: endpoint@0 {
};

ipu1_di1_hdmi: endpoint@1 {
remote-endpoint = <&hdmi_mux_1>;
};

ipu1_di1_mipi: endpoint@2 {
remote-endpoint = <&mipi_mux_1>;
};

ipu1_di1_lvds0: endpoint@3 {
remote-endpoint = <&lvds0_mux_1>;
};

ipu1_di1_lvds1: endpoint@4 {
remote-endpoint = <&lvds1_mux_1>;
};
};
};

display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
};


ipu1, mipi_dsi, ldb and hdmi are each separate platform devices, which
are combined to look like a single DRM device. Each device can be
enabled by the platform code. All enabled devices must be present to
cause the DRM device to "bind". The above connectivity is parsed via
the of_graph helpers, and enumerated by the driver(s).

Let's say that we have ipu1 and hdmi enabled, but ldb disabled. ldb is
connected to an external FPGA. Someone loads a bitstream after boot
into the FPGA, and then updates the DT dynamically to enable the ldb
device.

Great, so a new platform device gets spawned for the new device. What
triggers the ipu or display subsystem level (which is what's really
needed) to tell it something changed here?

This is exactly my point - such stuff has not been thought about, because
(I reckon) not many people are even aware of DT wanting to become dynamic.
It's certainly not clear from the use model that we've been basing our
driver conversions on that DT is anything but static...

[Pantelis Antoniou]

Hi Russell,

On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:

> On Tue, Jun 17, 2014 at 07:59:21PM +0300, Pantelis Antoniou wrote:
>> That case might already work on FPGA people's trees. I know Altera for sure
>> uses overlays, and some xilinx guys popped up on past discussions.
>> Their vendor trees probably use an older revision of the patches.
>>
>> BTW, there is nothing special about DRM/v4l2 that can't be handled by
>> a generic DT mechanism. What makes this such a big problem?
>
> Really?

>
> DRM is not hotpluggable in any shape or form, and David Airlie has
> indicated that he does strongly opposes moving it in that direction.
>
> DRM follows the "card" model, where, at probe time, the hardware is
> known and never changes until the "card" is torn down. No new
> connectors can be added once the "card" is initialised, and no
> connectors can be removed. Any changes must be done by tearing down
> the entire card and reconstructing it (if reconstructing it with a
> reduced set of hardware is appropriate.)
>

That is a limitation of the current DRM implementation.

I seems to be this is born out of some kind of misunderstanding about how
DT can (and does) support dynamic changes.

I admit that I haven't done much work on DRM (besides some tinkering with
Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic
change notifier support, perhaps it can be made to work.

As I said, the next thing coming is transactional DT support, perhaps you
can share the DT fragment describing your use-case (before/after) and
I'll try to accommodate in the next patch series.

Regards

-- Pantelis

[Russell King - ARM Linux]

On Tue, Jun 17, 2014 at 07:59:21PM +0300, Pantelis Antoniou wrote:
> That case might already work on FPGA people's trees. I know Altera for sure
> uses overlays, and some xilinx guys popped up on past discussions.
> Their vendor trees probably use an older revision of the patches.
>
> BTW, there is nothing special about DRM/v4l2 that can't be handled by
> a generic DT mechanism. What makes this such a big problem?

Really?

DRM is not hotpluggable in any shape or form, and David Airlie has
indicated that he does strongly opposes moving it in that direction.

DRM follows the "card" model, where, at probe time, the hardware is
known and never changes until the "card" is torn down. No new
connectors can be added once the "card" is initialised, and no
connectors can be removed. Any changes must be done by tearing down
the entire card and reconstructing it (if reconstructing it with a
reduced set of hardware is appropriate.)

[Pantelis Antoniou]

Hi Russell,

On Jun 17, 2014, at 7:01 PM, Russell King - ARM Linux wrote:

> On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote:

>> The complexity is absolutely required, and it has nothing to do with
>> beaglebone capes.
>>
>> The fact of the matter is that reconfigurable hardware is here, on
>> shipping system, and we, as the linux kernel community have to make
>> sure it works, and that it works in a sane way.
>

> Right, so looking back in the git history, this project has been going
> on for... at least four years? Probably longer than the length of time
> that we've been converting ARM to DT. At no point during that has anyone
> brought up the issue of DT being dynamic, so none of the drivers which
> we have been converting caters for this.
>

The timeline does not go that far back. The first (non-DT overlay based)
capebus patchset was posted on October 2012 and after feedback (i.e. it
was deemed to suck) it was pointed that a DT based generic method should
be used; hence DT overlays.

The dynamic DT part has always been part of PPC DT support for pSeries.

> Isn't this a bit of a missed opportunity, if this is a direction that
> OF wishes to head towards?
>

I am going to let Grant answer that, but personally I believe a lot of
the troubles we've been having with DT and dynamic device graph changes
can be handled elegantly using something DT overlays (and the follow up
work which is transaction DT support).

> Wouldn't it have been relevant to the discussion at kernel summit too,
> concerning DRM/v4l2/componentised systems? What if someone comes along
> tomorrow with part of their multimedia based system inside a FPGA
> which they program up at runtime?
>

That case might already work on FPGA people's trees. I know Altera for sure
uses overlays, and some xilinx guys popped up on past discussions.
Their vendor trees probably use an older revision of the patches.

BTW, there is nothing special about DRM/v4l2 that can't be handled by a generic
DT mechanism. What makes this such a big problem?

Regards

-- Pantelis

> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

[Russell King - ARM Linux]

On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote:

> The complexity is absolutely required, and it has nothing to do with
> beaglebone capes.
>
> The fact of the matter is that reconfigurable hardware is here, on
> shipping system, and we, as the linux kernel community have to make
> sure it works, and that it works in a sane way.

Right, so looking back in the git history, this project has been going
on for... at least four years? Probably longer than the length of time
that we've been converting ARM to DT. At no point during that has anyone
brought up the issue of DT being dynamic, so none of the drivers which
we have been converting caters for this.

Isn't this a bit of a missed opportunity, if this is a direction that
OF wishes to head towards?

Wouldn't it have been relevant to the discussion at kernel summit too,
concerning DRM/v4l2/componentised systems? What if someone comes along
tomorrow with part of their multimedia based system inside a FPGA
which they program up at runtime?

[Pantelis Antoniou]

Hi Rusell,

On Jun 17, 2014, at 8:41 PM, Russell King - ARM Linux wrote:

> On Tue, Jun 17, 2014 at 08:10:46PM +0300, Pantelis Antoniou wrote:
>> Hi Russell,
>>
>> On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:
>>> DRM is not hotpluggable in any shape or form, and David Airlie has
>>> indicated that he does strongly opposes moving it in that direction.
>>>
>>> DRM follows the "card" model, where, at probe time, the hardware is
>>> known and never changes until the "card" is torn down. No new
>>> connectors can be added once the "card" is initialised, and no
>>> connectors can be removed. Any changes must be done by tearing down
>>> the entire card and reconstructing it (if reconstructing it with a
>>> reduced set of hardware is appropriate.)
>>>
>>
>> That is a limitation of the current DRM implementation.
>
> ... an implementation which isn't going to change any time soon... and
> certainly is not going to change because someone comes along with a
> dynamic DT infrastructure.
>

We can't enforce anyone to use the facilities we provide. We can but point
the benefits of such.

>> I seems to be this is born out of some kind of misunderstanding about how
>> DT can (and does) support dynamic changes.
>>
>> I admit that I haven't done much work on DRM (besides some tinkering with
>> Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic
>> change notifier support, perhaps it can be made to work.
>
> It can be made to work in the way that I described above - any change
> to the hardware which makes up a DRM card would need the entire DRM
> card torn down and re-created... as I said above.
>
> The reason I know this is because I've been involved closely in dealing
> with imx-drm, and Armada DRM, and the mess that people spew trying to
> get their DT representations of their hardware (as multiple, separate
> devices which can be probed asynchronously) to work with DT.
>
> If DRM supported hot-plugging of components, dealing with that would
> be much easier than it is, but - as I said above - this is not going
> to happen. So, if it's not going to happen for the case which we
> commonly find on ARM hardware today, it's certainly not going to
> happen because DT wants to become dynamic.
>

This sounds more like a limitation of DRM than anything that has to do
with DT.

The ipu can register an of_reconfig notifier, and it will be notified of
any changes in the topology. Perhaps this can be part of the DRM core,
I can't be sure.

This is very similar to the way the platform/i2c/spi bus notifiers work
in my patchset; whenever the state of a device node change due to the live
tree changing the status of a child node from/to enabled/disabled the
parent (bus or in this case the ipu) will be notified and then it is
free to take action.

The hairy part (which the patchset provides) is making sure all the
changes are recorded, applied and potentially rolled back in a controlled
manner, so that the state of the DT tree is consistent at all times.

> This is exactly my point - such stuff has not been thought about, because
> (I reckon) not many people are even aware of DT wanting to become dynamic.
> It's certainly not clear from the use model that we've been basing our
> driver conversions on that DT is anything but static...
>

FWIW, the changes to support dynamic DT are not that great.
We know that trying to handle cases where each property change has to be
handled gets hairy fast, so what we're trying to do is make thing easier
by performing the device state change in a well defined manner.

So to return in your previous example, when the FPGA bitstream is loaded
and ldb should be enabled, the DT core will notify the parent bus (which
I can't tell exactly from your fragment but it should be) the platform
bus, which will end up of registering the platform device.

Now if DRM can't handle that, then that's a limitation of the DRM subsystem,
which fortunately is not shared by most of the other subsystems in the kernel.

Regards

-- Pantelis

[Gupta, Pekon]

Hi,

Fair enough.
But plz give a try to u-boot alternative below. It works at my end.

>>
>> (2)
>> Also, there was a talk of enabling and disabling DT fragments via u-boot.
>> That should also be explored instead of complicating cape DTS.
>
>Link? Relevance?
>

we can modify DT from u-boot itself [1].
Example: "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
But using following sequence of commands, you can modify DTB via
u-boot and make NAND cape work _without_any_hack_ in patch [2].

/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disable MMC2 node */
u-boot> fdt list /ocp/mmc@481d8000
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot> fdt list /ocp/gpmc
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt list /ocp/gpmc status
/* enable ELM node */
u-boot> fdt list /ocp/elm
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt list /ocp/elm status
/* boot uImage */
tftp 0x82000000 uImage
bootm 0x82000000 - 0x81000000

Note: "fdt set" command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
"okay" == \o\k\a\y
"disabled" == \d\i\s\a\b\l\e\d"


Hope above solves the pre-requisite because of which 'Tony Lindgren <to...@atomide.com>'
was unable to accept cape related DTS into his tree [3]


[1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT
[2] http://www.spinics.net/lists/linux-omap/msg107307.html
[3] http://www.spinics.net/lists/linux-omap/msg107354.html


with regards, pekon

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
> * Gupta, Pekon <pe...@ti.com> [140618 01:52]:

> Yes. If the capes are disabled by default we can have at
> least some of them included in the mainline kernel and
> enabled by the bootloader as needed. I'd like to hear back
> from the u-boot people too on this approach naturally.
>
> And some things we still cannot merge if they overlap for
> GPMC bindings for example. So we have to carefully check
> the generated .dtb file with dtc -I dtb -O dts.

This sounds really problematic to me from an end-user horror point of
view. And fortunately 3.17 is going to have some level of overlay
support so we can set this problem aside (and even treat the am335x gp
evm "profileN" trees as overlays too).

--
Tom

[Tony Lindgren]

* Gupta, Pekon <pe...@ti.com> [140618 01:52]:

Yes. If the capes are disabled by default we can have at
least some of them included in the mainline kernel and
enabled by the bootloader as needed. I'd like to hear back
from the u-boot people too on this approach naturally.

And some things we still cannot merge if they overlap for
GPMC bindings for example. So we have to carefully check
the generated .dtb file with dtc -I dtb -O dts.

Regards,

Tony

[Jason Kridner]

Great.

>>
>> And some things we still cannot merge if they overlap for
>> GPMC bindings for example. So we have to carefully check
>> the generated .dtb file with dtc -I dtb -O dts.
>
> This sounds really problematic to me from an end-user horror point of
> view. And fortunately 3.17 is going to have some level of overlay
> support so we can set this problem aside (and even treat the am335x gp
> evm "profileN" trees as overlays too).

Thank you Tom for chiming in. I think the end user experience is
horrific. Pekon should at least provide patches to u-boot that would
provide a mechanism to enable/disable a cape with a single operation,
rather than the individual devicetree nodes. This seems to really
break any ability to keep information about a cape consolidated or
usable by mere mortals.

I don't know that pushing it all into the kernel with overlays,
however, is the right answer. We've seen challenges with some
userspaces not exposing /lib/firmware in time and needing to compile
overlays into the kernel to make them work. More troublesome are the
types of errors end-users get when there are syntax errors, conflicts
or other failures, most notably because testing of loading all of the
various overlays in conflict with each other is adhoc at best. We've
gotten a lot of good feedback on using the pinmux-helper and
config-pin utility from end users who are still struggling to learn
how to do devicetree overlays properly. It seems to me that kernel
run-time overlays should be used for development and dynamic hardware
rather than boot-time configuration, despite the convenience they add
to most of us who understand the basics of how to use them.

[Tony DiCola]

Sorry to bump up an old thread, but I was trying to catch up on the general state and future of overlay support and this looks like the best discussion.  I was curious, is there any thought around how bonescript and other tools that use overlays today for dynamic pin control (like setting pull-ups, analog inputs, etc.) would work in a world without overlays?  For example does bonescript work on the 3.14 kernel today without the cape manager?

Also based on this LKML thread that was mentioned in other threads (https://lkml.org/lkml/2014/7/27/57), does it still look like device tree overlay support is on its way into the mainline kernel?

I just wanted to get a better picture of the future of overlays and if libraries that use them today (like bonescript or Adafruit's BBIO library) should continue to use them or start looking at alternatives.  Thanks!

[Jason Kridner]

On Tue, Aug 26, 2014 at 3:50 PM, Tony DiCola <to...@tonydicola.com> wrote:

Sorry to bump up an old thread, but I was trying to catch up on the general state and future of overlay support and this looks like the best discussion.  I was curious, is there any thought around how bonescript and other tools that use overlays today for dynamic pin control (like setting pull-ups, analog inputs, etc.) would work in a world without overlays?  For example does bonescript work on the 3.14 kernel today without the cape manager?

I have a version where I did a bit of a proof-of-concept on this, but I haven't enabled all of the peripherals yet. I have various implementations of the kernel interfaces and here is the one that uses cape-universal:

* https://github.com/jadonk/bonescript/blob/master/src/hw_universal.js

It is triggered by this condition when the library is loaded:

* https://github.com/jadonk/bonescript/blob/master/src/index.js#L33

This is the test condition I used to discover if cape-universal is loaded:

* https://github.com/jadonk/bonescript/blob/master/src/my.js#L43

exports.is_cape_universal = function(callback) {     var ocp = exports.is_ocp();     if(debug) winston.debug('is_ocp() = ' + ocp);     var cape_universal = exports.find_sysfsFile('cape-universal', ocp, 'cape-universal.', callback);     if(debug) winston.debug('is_cape_universal() = ' + cape_universal);     return(cape_universal); }; However, I'm not finding that 3.14 is really using cape-universal. I'm still exploring that, but it seems Robert has implemented things in a different way. When I'm not fighting 'buildbot' (builds.beagleboard.org), I'm looking at what it'll take to align 'config-pin' from cape-universal and Robert's entries. Right now, I'm leaning towards backing out Robert's changes and going back to cape-universal. With cape-universal, there are gpio and pinmux helpers that can be configured from userspace.

 

Also based on this LKML thread that was mentioned in other threads (https://lkml.org/lkml/2014/7/27/57), does it still look like device tree overlay support is on its way into the mainline kernel?

I certainly believe so. We don't want to go away from enabling device tree overlays, but usability seems to be showing that it is better to try to avoid the dependency. Not so much because of getting the CapeMgr merged, but rather the headaches that people are getting trying to keep overlays compatible and derive new ones.

 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Jason,

What is so radically different that capemgr does not work ? Sorry if this is a total newb question, but this is one aspect I've been struggling to try and understand. As I'm not exactly a kernel dev *yet*.

I've read stuff where people have used mmap to configure pins, using the PRU etc, but again this is another area where I lack experience . . . Perhaps the device tree needs to be in place for any of this to work?

[Robert Nelson]

On Tue, Aug 26, 2014 at 4:20 PM, Jason Kridner <jkri...@beagleboard.org> wrote:

On Tue, Aug 26, 2014 at 3:50 PM, Tony DiCola <to...@tonydicola.com> wrote:

Sorry to bump up an old thread, but I was trying to catch up on the general state and future of overlay support and this looks like the best discussion.  I was curious, is there any thought around how bonescript and other tools that use overlays today for dynamic pin control (like setting pull-ups, analog inputs, etc.) would work in a world without overlays?  For example does bonescript work on the 3.14 kernel today without the cape manager?

I have a version where I did a bit of a proof-of-concept on this, but I haven't enabled all of the peripherals yet. I have various implementations of the kernel interfaces and here is the one that uses cape-universal:

* https://github.com/jadonk/bonescript/blob/master/src/hw_universal.js

It is triggered by this condition when the library is loaded:

* https://github.com/jadonk/bonescript/blob/master/src/index.js#L33

This is the test condition I used to discover if cape-universal is loaded:

* https://github.com/jadonk/bonescript/blob/master/src/my.js#L43

exports.is_cape_universal = function(callback) {     var ocp = exports.is_ocp();     if(debug) winston.debug('is_ocp() = ' + ocp);     var cape_universal = exports.find_sysfsFile('cape-universal', ocp, 'cape-universal.', callback);     if(debug) winston.debug('is_cape_universal() = ' + cape_universal);     return(cape_universal); }; However, I'm not finding that 3.14 is really using cape-universal. I'm still exploring that, but it seems Robert has implemented things in a different way. When I'm not fighting 'buildbot' (builds.beagleboard.org), I'm looking at what it'll take to align 'config-pin' from cape-universal and Robert's entries. Right now, I'm leaning towards backing out Robert's changes and going back to cape-universal. With cape-universal, there are gpio and pinmux helpers that can be configured from userspace.

As it currently stands, we should be able to add all of charles' pinmux nodes to (1)

1: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/3.14.17-bone8/arch/arm/boot/dts/am335x-bone-common-pinmux.dtsi

(git.ti.com is done, so i can't push all my work today yet in the v3.14.x-ti branch)

All the lcd's (that i have) are now taken care of.. So the next step, i need u-boot to read the eeprom, so atleast the lcd's work on bootup. 

http://elinux.org/Beagleboard:Capes_3.8_to_3.14

We just need to get pinmux helper to work for the rest..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Jason Kridner]

On Tue, Aug 26, 2014 at 5:35 PM, William Hermans <yyr...@gmail.com> wrote:

Jason,

What is so radically different that capemgr does not work ?

Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree which will require a backport. It looks like it should land upstream in 3.17 and we'll likely backport it from there.

 

Sorry if this is a total newb question, but this is one aspect I've been struggling to try and understand. As I'm not exactly a kernel dev *yet*.

I've read stuff where people have used mmap to configure pins, using the PRU etc, but again this is another area where I lack experience . . . Perhaps the device tree needs to be in place for any of this to work?

Using mmap to configure pins and peripherals bypasses Linux maintaining control over that peripheral and is not the "Linux way". A device tree is required to boot modern ARM kernels, but device tree *overlays* are not. For mmap interfaces to work, you simply need a kernel that will agree to mmap the memory. A device tree overlay may or may not be helpful. The way to know something will work now and in the future is to get a real device driver into the mainline kernel. 

[Robert Nelson]

On Tue, Aug 26, 2014 at 4:50 PM, Jason Kridner <jkri...@beagleboard.org> wrote:

On Tue, Aug 26, 2014 at 5:35 PM, William Hermans <yyr...@gmail.com> wrote:

Jason,

What is so radically different that capemgr does not work ?

Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree which will require a backport. It looks like it should land upstream in 3.17 and we'll likely backport it from there.

1 more step: 

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae36e95cf81c98b111b84317adeb358aaffa80e2

Group changes to the device tree. In preparation for adding device tree overlay support, OF_DYNAMIC is reworked so that a set of device tree changes can be prepared and applied to the tree all at once. OF_RECONFIG notifiers see the most significant change here so that users always get a consistent view of the tree. Notifiers generation is moved from before a change to after it, and notifiers for a group of changes are emitted after the entire block of changes have been applied

Regards,

[William Hermans]

Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree which will require a backport. It looks like it should land upstream in 3.17 and we'll likely backport it from there.

What I mean is this: Why doesn't the capemgr that is in 3.8.x work in 3.14.x *right now* Why is it not a drop-in addition ?  Obviously  something is different, but I am trying to understand why the kernel progresses in a manner that breaks things in previous version, that are not all that old.

--

[Robert Nelson]

On Tue, Aug 26, 2014 at 5:11 PM, William Hermans <yyr...@gmail.com> wrote:
>> Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree
>> which will require a backport. It looks like it should land upstream in 3.17
>> and we'll likely backport it from there.
>
>
> What I mean is this: Why doesn't the capemgr that is in 3.8.x work in 3.14.x
> *right now* Why is it not a drop-in addition ? Obviously something is
> different, but I am trying to understand why the kernel progresses in a
> manner that breaks things in previous version, that are not all that old.

The capemgr patch-set touched code in almost every kernel subsystem.

If it worked that easily, we would have moved off v3.8.x long ago..

[John Syn]

From: William Hermans <yyr...@gmail.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Tuesday, August 26, 2014 at 3:11 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: Re: [beagleboard] Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards

Didn't say that it doesn't work. It hasn't yet been added to our 3.14 tree which will require a backport. It looks like it should land upstream in 3.17 and we'll likely backport it from there.

What I mean is this: Why doesn't the capemgr that is in 3.8.x work in 3.14.x *right now* Why is it not a drop-in addition ?  Obviously  something is different, but I am trying to understand why the kernel progresses in a manner that breaks things in previous version, that are not all that old.

That is because when Pantelis Antoniou worked for Circuitco, he developed cape manager, but his work was never accepted into mainline. When Pantelis left Circuitco, he wasn’t available to merge his work into the newer kernels. However, over the last year, Pantelis did some nice work with some other very smart kernel developers and hopefully dynamic devicetree will be accepted into mainline V3.17. 

Regards,

John

[Tony DiCola]

Awesome, that's good to see Linus has accepted the change.

Regarding bonescript, Jason you mentioned:

> With cape-universal, there are gpio and pinmux helpers that can be configured from userspace.

GPIO and pinmux from userspace sounds great--do you know if there are any examples of cape-universal and the gpio/pinmux helpers to check out?  If there was a straightforward way to control GPIO and pinmux from userspace with those tools then it probably reduces the need for overlays in libraries like bonescript, BBIO, etc.  Realistically I think BBIO will probably mirror bonescript's capabilities, so whatever works for bonescript to dynamically change pins with or without overlays would also work for BBIO and other libraries.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ULhioCVzbYk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Charles Steinkuehler]

On 8/27/2014 12:09 PM, Tony DiCola wrote:
> Awesome, that's good to see Linus has accepted the change.
>
> Regarding bonescript, Jason you mentioned:
>
>> With cape-universal, there are gpio and pinmux helpers that can be
> configured from userspace.
>
> GPIO and pinmux from userspace sounds great--do you know if there are any
> examples of cape-universal and the gpio/pinmux helpers to check out? If
> there was a straightforward way to control GPIO and pinmux from userspace
> with those tools then it probably reduces the need for overlays in
> libraries like bonescript, BBIO, etc.

I've got some setup scripts that setup various GPIO pins as part of
various Machinekit configurations. One example:

https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/CRAMPS/setup.sh#L76-L129

There's also a GUI utility you can use to create a file to feed to the
config-pin utility:

Source:
https://github.com/strahlex/BBIOConfig

Binary download (Linux, Windows, & OSX):
https://github.com/strahlex/BBIOConfig/releases

You can also talk directly to the sysfs nodes if you want, bypassing the
config-pin utility. But part of the whole point of making the universal
cape was to try and make it easier for folks to configure pins rather
than go digging around in sysfs. :)

--
Charles Steinkuehler
cha...@steinkuehler.net