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

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

[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 <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.
>
> 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:
>
>   git at 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.

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

[Gupta, Pekon]

Hi Jason,

>From: 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 <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.
>>
>> 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.

+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

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

[Jason Kridner]

On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@ti.com> wrote:
> Hi Jason,
>
>>From: 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 <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.
>>>
>>> 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.
>
> +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.

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

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

[Gupta, Pekon]

Hi,

>From: Jason Kridner [mailto:jkridner at gmail.com]
>>On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>>From: Jason Kridner
[...]
>>>> * 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.
>>
>> +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.
>
>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.
>
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 at 481d8000
u-boot> fdt set  /ocp/mmc at 481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc at 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 <tony@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

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

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140618 01:52]:
> Hi,
> 
> >From: Jason Kridner [mailto:jkridner at gmail.com]
> >>On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@ti.com> wrote:
> >>>From: Jason Kridner
> [...]
> >>>> * 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.
> >>
> >> +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.
> >
> >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.
> >
> 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 at 481d8000
> u-boot> fdt set  /ocp/mmc at 481d8000 status \d\i\s\a\b\l\e\d
> u-boot> fdt list /ocp/mmc at 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 <tony@atomide.com>'
> was unable to accept cape related DTS into his tree [3]

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

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

[Tom Rini]

On 06/26/2014 03:50 AM, Tony Lindgren wrote:
> * Gupta, Pekon <pekon@ti.com> [140618 01:52]:
>> Hi,
>>
>>> From: Jason Kridner [mailto:jkridner at gmail.com]
>>>> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>> From: Jason Kridner
>> [...]
>>>>>> * 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.
>>>>
>>>> +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.
>>>
>>> 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.
>>>
>> 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 at 481d8000
>> u-boot> fdt set  /ocp/mmc at 481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc at 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 <tony@atomide.com>'
>> was unable to accept cape related DTS into his tree [3]
> 
> 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

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

[Jason Kridner]

On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini <trini@ti.com> wrote:
> On 06/26/2014 03:50 AM, Tony Lindgren wrote:
>> * Gupta, Pekon <pekon@ti.com> [140618 01:52]:
>>> Hi,
>>>
>>>> From: Jason Kridner [mailto:jkridner at gmail.com]
>>>>> On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>>> From: Jason Kridner
>>> [...]
>>>>>>> * 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.
>>>>>
>>>>> +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.
>>>>
>>>> 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.
>>>>
>>> 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 at 481d8000
>>> u-boot> fdt set  /ocp/mmc at 481d8000 status \d\i\s\a\b\l\e\d
>>> u-boot> fdt list /ocp/mmc at 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 <tony@atomide.com>'
>>> was unable to accept cape related DTS into his tree [3]
>>
>> 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.

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.

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

[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 <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.
>
> 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:
>
>   git at 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.

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

[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 <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.

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.

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

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

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

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

[Russell King - ARM Linux]

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.

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.

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

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

[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

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

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

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

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

[Russell King - ARM Linux]

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.

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

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

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

[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

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

[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

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

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

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

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

[Jason Kridner]

On Tue, Jun 17, 2014 at 12:01 PM, Russell King - ARM Linux
<linux@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?
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

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

[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 majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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.)

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

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

[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

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

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

[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 at 020e0008 {
                                #address-cells = <1>;
                                #size-cells = <0>;
                                compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
                                gpr = <&gpr>;
                                status = "disabled";

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

                                        port at 0 {
                                                reg = <0>;

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

                                        port at 1 {
                                                reg = <1>;

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

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

                                        port at 0 {
                                                reg = <0>;

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

                                        port at 1 {
                                                reg = <1>;

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

                        hdmi: hdmi at 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 at 0 {
                                        reg = <0>;

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

                                port at 1 {
                                        reg = <1>;

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

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

                                port at 0 {
                                        reg = <0>;

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

                                port at 1 {
                                        reg = <1>;

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

                ipu1: ipu at 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 at 2 {
                                #address-cells = <1>;
                                #size-cells = <0>;
                                reg = <2>;

                                ipu1_di0_disp0: endpoint at 0 {
                                };

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

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

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

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

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

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

                                ipu1_di0_disp1: endpoint at 0 {
                                };

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

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

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

                                ipu1_di1_lvds1: endpoint at 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...

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

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

[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.

>> 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 at 020e0008 {
>                                #address-cells = <1>;
>                                #size-cells = <0>;
>                                compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
>                                gpr = <&gpr>;
>                                status = "disabled";
> 
>                                lvds-channel at 0 {
>                                        #address-cells = <1>;
>                                        #size-cells = <0>;
>                                        reg = <0>;
>                                        status = "disabled";
> 
>                                        port at 0 {
>                                                reg = <0>;
> 
>                                                lvds0_mux_0: endpoint {
>                                                        remote-endpoint = <&ipu1_di0_lvds0>;
>                                                };
>                                        };
> 
>                                        port at 1 {
>                                                reg = <1>;
> 
>                                                lvds0_mux_1: endpoint {
>                                                        remote-endpoint = <&ipu1_di1_lvds0>;
>                                                };
>                                        };
>                                };
> 
>                                lvds-channel at 1 {
>                                        #address-cells = <1>;
>                                        #size-cells = <0>;
>                                        reg = <1>;
>                                        status = "disabled";
> 
>                                        port at 0 {
>                                                reg = <0>;
> 
>                                                lvds1_mux_0: endpoint {
>                                                        remote-endpoint = <&ipu1_di0_lvds1>;
>                                                };
>                                        };
> 
>                                        port at 1 {
>                                                reg = <1>;
> 
>                                                lvds1_mux_1: endpoint {
>                                                        remote-endpoint = <&ipu1_di1_lvds1>;
>                                                };
>                                        };
>                                };
>                        };
> 
>                        hdmi: hdmi at 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 at 0 {
>                                        reg = <0>;
> 
>                                        hdmi_mux_0: endpoint {
>                                                remote-endpoint = <&ipu1_di0_hdmi>;
>                                        };
>                                };
> 
>                                port at 1 {
>                                        reg = <1>;
> 
>                                        hdmi_mux_1: endpoint {
>                                                remote-endpoint = <&ipu1_di1_hdmi>;
>                                        };
>                                };
>                        };
> 
>                        mipi_dsi: mipi at 021e0000 {
>                                #address-cells = <1>;
>                                #size-cells = <0>;
>                                reg = <0x021e0000 0x4000>;
>                                status = "disabled";
> 
>                                port at 0 {
>                                        reg = <0>;
> 
>                                        mipi_mux_0: endpoint {
>                                                remote-endpoint = <&ipu1_di0_mipi>;
>                                        };
>                                };
> 
>                                port at 1 {
>                                        reg = <1>;
> 
>                                        mipi_mux_1: endpoint {
>                                                remote-endpoint = <&ipu1_di1_mipi>;
>                                        };
>                                };
>                        };
> 
>                ipu1: ipu at 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 at 2 {
>                                #address-cells = <1>;
>                                #size-cells = <0>;
>                                reg = <2>;
> 
>                                ipu1_di0_disp0: endpoint at 0 {
>                                };
> 
>                                ipu1_di0_hdmi: endpoint at 1 {
>                                        remote-endpoint = <&hdmi_mux_0>;
>                                };
> 
>                                ipu1_di0_mipi: endpoint at 2 {
>                                        remote-endpoint = <&mipi_mux_0>;
>                                };
> 
>                                ipu1_di0_lvds0: endpoint at 3 {
>                                        remote-endpoint = <&lvds0_mux_0>;
>                                };
> 
>                                ipu1_di0_lvds1: endpoint at 4 {
>                                        remote-endpoint = <&lvds1_mux_0>;
>                                };
>                                };
> 
>                                ipu1_di0_lvds1: endpoint at 4 {
>                                        remote-endpoint = <&lvds1_mux_0>;
>                                };
>                        };
> 
>                        ipu1_di1: port at 3 {
>                                #address-cells = <1>;
>                                #size-cells = <0>;
>                                reg = <3>;
> 
>                                ipu1_di0_disp1: endpoint at 0 {
>                                };
> 
>                                ipu1_di1_hdmi: endpoint at 1 {
>                                        remote-endpoint = <&hdmi_mux_1>;
>                                };
> 
>                                ipu1_di1_mipi: endpoint at 2 {
>                                        remote-endpoint = <&mipi_mux_1>;
>                                };
> 
>                                ipu1_di1_lvds0: endpoint at 3 {
>                                        remote-endpoint = <&lvds0_mux_1>;
>                                };
> 
>                                ipu1_di1_lvds1: endpoint at 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?
> 

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

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

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

[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

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

[Grant Likely]

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

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.

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

[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.