Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
* Gupta, Pekon pe...@ti.com [140618 01:52]: Hi, From: Jason Kridner [mailto:jkrid...@gmail.com] On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@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 0x8100 am335x-boneblack.dtb u-boot fdt addr 0x8100 /* disable MMC2 node */ u-boot fdt list /ocp/mmc@481d8000 u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d u-boot fdt list /ocp/mmc@481d8000 status /* enable GPMC node */ u-boot fdt list /ocp/gpmc u-boot fdt set /ocp/gpmc status \o\k\a\y u-boot fdt list /ocp/gpmc status /* enable ELM node */ u-boot fdt list /ocp/elm u-boot fdt set /ocp/elm status \o\k\a\y u-boot fdt list /ocp/elm status /* boot uImage */ tftp 0x8200 uImage bootm 0x8200 - 0x8100 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 t...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On 06/26/2014 03:50 AM, Tony Lindgren wrote: * Gupta, Pekon pe...@ti.com [140618 01:52]: Hi, From: Jason Kridner [mailto:jkrid...@gmail.com] On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@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 0x8100 am335x-boneblack.dtb u-boot fdt addr 0x8100 /* disable MMC2 node */ u-boot fdt list /ocp/mmc@481d8000 u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d u-boot fdt list /ocp/mmc@481d8000 status /* enable GPMC node */ u-boot fdt list /ocp/gpmc u-boot fdt set /ocp/gpmc status \o\k\a\y u-boot fdt list /ocp/gpmc status /* enable ELM node */ u-boot fdt list /ocp/elm u-boot fdt set /ocp/elm status \o\k\a\y u-boot fdt list /ocp/elm status /* boot uImage */ tftp 0x8200 uImage bootm 0x8200 - 0x8100 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 t...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini tr...@ti.com wrote: On 06/26/2014 03:50 AM, Tony Lindgren wrote: * Gupta, Pekon pe...@ti.com [140618 01:52]: Hi, From: Jason Kridner [mailto:jkrid...@gmail.com] On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@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 0x8100 am335x-boneblack.dtb u-boot fdt addr 0x8100 /* disable MMC2 node */ u-boot fdt list /ocp/mmc@481d8000 u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d u-boot fdt list /ocp/mmc@481d8000 status /* enable GPMC node */ u-boot fdt list /ocp/gpmc u-boot fdt set /ocp/gpmc status \o\k\a\y u-boot fdt list /ocp/gpmc status /* enable ELM node */ u-boot fdt list /ocp/elm u-boot fdt set /ocp/elm status \o\k\a\y u-boot fdt list /ocp/elm status /* boot uImage */ tftp 0x8200 uImage bootm 0x8200 - 0x8100 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 t...@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
RE: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi,
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@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 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* disable MMC2 node */
u-boot fdt list /ocp/mmc@481d8000
u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot fdt list /ocp/gpmc
u-boot fdt set /ocp/gpmc status \o\k\a\y
u-boot fdt list /ocp/gpmc status
/* enable ELM node */
u-boot fdt list /ocp/elm
u-boot fdt set /ocp/elm status \o\k\a\y
u-boot fdt list /ocp/elm status
/* boot uImage */
tftp 0x8200 uImage
bootm 0x8200 - 0x8100
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
t...@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
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 jkrid...@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
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 jkrid...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 jkrid...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 jkrid...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, 17 Jun 2014 10:09:31 +0100, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote: Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 12:01 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote: The complexity is absolutely required, and it has nothing to do with beaglebone capes. The fact of the matter is that reconfigurable hardware is here, on shipping system, and we, as the linux kernel community have to make sure it works, and that it works in a sane way. Right, so looking back in the git history, this project has been going on for... at least four years? Probably longer than the length of time that we've been converting ARM to DT. At no point during that has anyone brought up the issue of DT being dynamic, so none of the drivers which we have been converting caters for this. Isn't this a bit of a missed opportunity, if this is a direction that OF wishes to head towards? I believe it absolutely is a missed opportunity, but that doesn't mean it isn't still needed moving forward. We've been using overlays successfully in the BeagleBoard.org community on BeagleBone Black for over a year now. It is just a shame we're still shipping a 3.8 kernel. This universal overlay provides hope to support most add-ons, but it doesn't address the dynamic nature of some add-on hardware. It is certainly my hope that this effort doesn't derail the overlay development work. Wouldn't it have been relevant to the discussion at kernel summit too, concerning DRM/v4l2/componentised systems? What if someone comes along tomorrow with part of their multimedia based system inside a FPGA which they program up at runtime? -- 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 linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@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 jkrid...@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.
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 08:10:46PM +0300, Pantelis Antoniou wrote:
Hi Russell,
On Jun 17, 2014, at 8:05 PM, Russell King - ARM Linux wrote:
DRM is not hotpluggable in any shape or form, and David Airlie has
indicated that he does strongly opposes moving it in that direction.
DRM follows the card model, where, at probe time, the hardware is
known and never changes until the card is torn down. No new
connectors can be added once the card is initialised, and no
connectors can be removed. Any changes must be done by tearing down
the entire card and reconstructing it (if reconstructing it with a
reduced set of hardware is appropriate.)
That is a limitation of the current DRM implementation.
... an implementation which isn't going to change any time soon... and
certainly is not going to change because someone comes along with a
dynamic DT infrastructure.
I seems to be this is born out of some kind of misunderstanding about how
DT can (and does) support dynamic changes.
I admit that I haven't done much work on DRM (besides some tinkering with
Rob Clark's ti_lcdc DRM driver), but knowing what DT does have a dynamic
change notifier support, perhaps it can be made to work.
It can be made to work in the way that I described above - any change
to the hardware which makes up a DRM card would need the entire DRM
card torn down and re-created... as I said above.
The reason I know this is because I've been involved closely in dealing
with imx-drm, and Armada DRM, and the mess that people spew trying to
get their DT representations of their hardware (as multiple, separate
devices which can be probed asynchronously) to work with DT.
If DRM supported hot-plugging of components, dealing with that would
be much easier than it is, but - as I said above - this is not going
to happen. So, if it's not going to happen for the case which we
commonly find on ARM hardware today, it's certainly not going to
happen because DT wants to become dynamic.
As I said, the next thing coming is transactional DT support, perhaps you
can share the DT fragment describing your use-case (before/after) and
I'll try to accommodate in the next patch series.
I don't have any - I'm using it as an example where a device (such as
the iMX6 SoC) which has quite a complex media infrastructure may be
extended externally via an FPGA to provide additional interfaces which
may then require dynamic changes to the DT description, thereby meaning
that we have to reconstruct the DRM card in its entirety.
If you want some DT to look at...
ldb: ldb@020e0008 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,imx6q-ldb, fsl,imx53-ldb;
gpr = gpr;
status = disabled;
lvds-channel@0 {
#address-cells = 1;
#size-cells = 0;
reg = 0;
status = disabled;
port@0 {
reg = 0;
lvds0_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds0;
};
};
port@1 {
reg = 1;
lvds0_mux_1: endpoint {
remote-endpoint =
ipu1_di1_lvds0;
};
};
};
lvds-channel@1 {
#address-cells = 1;
#size-cells = 0;
reg = 1;
status = disabled;
port@0 {
reg = 0;
lvds1_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds1;
};
};
port@1 {
reg = 1;
lvds1_mux_1: endpoint {
remote-endpoint =
ipu1_di1_lvds1;
};
};
};
};
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
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@020e0008 {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,imx6q-ldb, fsl,imx53-ldb;
gpr = gpr;
status = disabled;
lvds-channel@0 {
#address-cells = 1;
#size-cells = 0;
reg = 0;
status = disabled;
port@0 {
reg = 0;
lvds0_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds0;
};
};
port@1 {
reg = 1;
lvds0_mux_1: endpoint {
remote-endpoint =
ipu1_di1_lvds0;
};
};
};
lvds-channel@1 {
#address-cells = 1;
#size-cells = 0;
reg = 1;
status = disabled;
port@0 {
reg = 0;
lvds1_mux_0: endpoint {
remote-endpoint =
ipu1_di0_lvds1;
};
};
port@1 {
reg = 1;
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@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
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@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
