ARM: dts: am335x-bone-common: Add i2c2 definition

Add missing i2c2 bus define to access various cape and prototype/breakout board devices.

Signed-off-by Matt Ranostay <[email protected]>

---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

arch/arm/boot/dts/am335x-bone-common.dtsi +7 -0

index 2e7d932..5fdae2e 100644
@@ -84,6 +84,13 @@
 		>;
 	};
 
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0x178 (PIN_INPUT_PULLUP | MUX_MODE3)	/* uart1_ctsn.i2c2_sda */
+			0x17c (PIN_INPUT_PULLUP | MUX_MODE3)	/* uart1_rtsn.i2c2_scl */
+		>;
+	};
+
 	uart0_pins: pinmux_uart0_pins {
 		pinctrl-single,pins = <
 			0x170 (PIN_INPUT_PULLUP | MUX_MODE0)	/* uart0_rxd.uart0_rxd */

@@ -222,6 +229,15 @@
 
 };

Quoted 16 lines

arch/arm/boot/dts/am335x-bone-common.dtsi +7 -0

+     i2c2_pins: pinmux_i2c2_pins {
+             pinctrl-single,pins = <
+                     0x178 (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_ctsn.i2c2_sda */
+                     0x17c (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_rtsn.i2c2_scl */
+             >;
+     };
+
      uart0_pins: pinmux_uart0_pins {
              pinctrl-single,pins = <
                      0x170 (PIN_INPUT_PULLUP | MUX_MODE0)    /* uart0_rxd.uart0_rxd */

@@ -222,6 +229,15 @@
 
 };
 

arch/arm/boot/dts/am335x-bone-common.dtsi line 240

Quoted 9 lines

arch/arm/boot/dts/am335x-bone-common.dtsi +9 -0

+
+&i2c2 {
+     pinctrl-names = "default";
+     pinctrl-0 = <&i2c2_pins>;
+
+     status = "okay";
+     clock-frequency = <100000>;
+};
+

If these pins are not used for i2c2 on some capes, this device should be set to status = "disabled" state by default. Then u-boot could re-enable it on the boards that have i2c2 in use.

Quoted 16 lines

Quoted 16 lines

arch/arm/boot/dts/am335x-bone-common.dtsi +7 -0

+     i2c2_pins: pinmux_i2c2_pins {
+             pinctrl-single,pins = <
+                     0x178 (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_ctsn.i2c2_sda */
+                     0x17c (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_rtsn.i2c2_scl */
+             >;
+     };
+
      uart0_pins: pinmux_uart0_pins {
              pinctrl-single,pins = <
                      0x170 (PIN_INPUT_PULLUP | MUX_MODE0)    /* uart0_rxd.uart0_rxd */

@@ -222,6 +229,15 @@
 
 };
 

Quoted 13 lines

arch/arm/boot/dts/am335x-bone-common.dtsi line 240

Quoted 9 lines

arch/arm/boot/dts/am335x-bone-common.dtsi +9 -0

+
+&i2c2 {
+     pinctrl-names = "default";
+     pinctrl-0 = <&i2c2_pins>;
+
+     status = "okay";
+     clock-frequency = <100000>;
+};
+

If these pins are not used for i2c2 on some capes, this device should be set to status = "disabled" state by default. Then u-boot could re-enable it on the boards that have i2c2 in use.

To-date, this is the i2c bus that all capes have placed an at24 eeprom for cape identification.

Quoted 7 lines

Quoted 4 lines

If these pins are not used for i2c2 on some capes, this device should be set to status = "disabled" state by default. Then u-boot could re-enable it on the boards that have i2c2 in use.

To-date, this is the i2c bus that all capes have placed an at24 eeprom for cape identification.

And how many capes actually implement the eeprom cape identification out of the available capes? :)

Quoted 10 lines

Quoted 7 lines

Quoted 4 lines

If these pins are not used for i2c2 on some capes, this device should be set to status = "disabled" state by default. Then u-boot could re-enable it on the boards that have i2c2 in use.

To-date, this is the i2c bus that all capes have placed an at24 eeprom for cape identification.

And how many capes actually implement the eeprom cape identification out of the available capes? :)

Not including one off designs in someone's lab. We will never have an accurate number. ;)

So far; just the ones that want their "cape" detected in the default image currently being shipped by CircuitCo. Otherwise the few that I've seen without an eeprom, usually follow this default pinmux.

http://elinux.org/CircuitCo:Basic_Proto_Cape

Which includes that i2c bus enabled.

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

--
Tom

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 11 lines · Tom Rini

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then are two different hardware where each need its proper FDT that describes it.

Quoted 7 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 39 lines · Javier Martinez Canillas

Quoted 11 lines · Tom Rini

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then are two different hardware where each need its proper FDT that describes it.

Quoted 7 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

Quoted 5 lines

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

-Matt

Quoted 46 lines · Matt Porter

Quoted 44 lines · Javier Martinez Canillas

Quoted 11 lines · Tom Rini

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then are two different hardware where each need its proper FDT that describes it.

Quoted 7 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 5 lines

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

Unfortunately I don't have a solution but what I'm pretty sure is that mangling the DTS from the bootloader is not the right one :-)

Quoted 1 line

-Matt

Best regards,
Javier

Hi Javier,

Quoted 47 lines · Javier Martinez Canillas

Quoted 46 lines · Matt Porter

Quoted 44 lines · Javier Martinez Canillas

Quoted 11 lines · Tom Rini

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then are two different hardware where each need its proper FDT that describes it.

Quoted 7 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 6 lines

Quoted 5 lines

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Since this appears to be all coming back to DT overlays, let me try to address some points.

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for the base board and the cape in question. Doing that he essentially cuts himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his own base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic hardware configuration. There are a number of FPGA people that seem interested as well.

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 3 lines

Unfortunately I don't have a solution but what I'm pretty sure is that mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

Hello Pantelis,

Quoted 72 lines · Pantelis Antoniou

Hi Javier,

Quoted 61 lines · Javier Martinez Canillas

Quoted 59 lines · Matt Porter

Quoted 56 lines · Javier Martinez Canillas

Quoted 19 lines · Tom Rini

Quoted 18 lines · Robert Nelson

Quoted 13 lines

Quoted 5 lines

Either case if fine with me. As who knows when the dtc "overlay" will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.

Quoted 2 lines

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Quoted 8 lines

Quoted 8 lines

Would Tom even approve of that in mainline u-boot? He didn't want my
"invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that describes it.

Quoted 9 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 6 lines

Quoted 5 lines

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Quoted 3 lines

Since this appears to be all coming back to DT overlays, let me try to address some points.

It seems that you misunderstood my comments. I do think that DT overlays and the cape manager are a great solution for any hardware that could be expanded on runtime and I really hope that they can eventually land into mainline.

In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into mainline..."

Quoted 38 lines

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their
design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.

Quoted 9 lines

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 3 lines

Unfortunately I don't have a solution but what I'm pretty sure is that mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

What I said that I'm against is modifying a FDT using U-Boot scripts commands that is something that mentioned in this thread. That is not a robust way to do it and also is not something that a newbie could do it neither.

Also, doing these FDT changes in the bootloader has several disadvantages, besides having to implement on each bootloaders like Tom said, you need to upgrade your bootloader which is something that just can't be done on many boards and also is still a static configuration since you need to reboot in order to use a different FDT. So the hardware can't really be expanded on runtime unlike with DT overlays where the overlays are loaded from regular files.

But I guess you agree with me on all those points and you just misunderstood my comments. So DT overlays is definitely the way to go (or something similar) but my point is that until we have that solution merged, you can use a static DT in mainline for your stacked cape or use a vendor kernel that already has DT overlays support.

I hope I explained myself better this time ;-)

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 150 lines · Javier Martinez Canillas

Hello Pantelis,

Quoted 72 lines · Pantelis Antoniou

Hi Javier,

Quoted 61 lines · Javier Martinez Canillas

Quoted 59 lines · Matt Porter

Quoted 56 lines · Javier Martinez Canillas

Quoted 19 lines · Tom Rini

Quoted 18 lines · Robert Nelson

Quoted 13 lines

Quoted 5 lines

Either case if fine with me. As who knows when the dtc "overlay" will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.

Quoted 2 lines

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Quoted 8 lines

Quoted 8 lines

Would Tom even approve of that in mainline u-boot? He didn't want my
"invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that describes it.

Quoted 9 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 6 lines

Quoted 5 lines

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Quoted 3 lines

Since this appears to be all coming back to DT overlays, let me try to address some points.

It seems that you misunderstood my comments. I do think that DT overlays and the cape manager are a great solution for any hardware that could be expanded on runtime and I really hope that they can eventually land into mainline.

In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into mainline..."

Quoted 38 lines

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their
design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his own
base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.

Quoted 9 lines

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 3 lines

Unfortunately I don't have a solution but what I'm pretty sure is that mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

What I said that I'm against is modifying a FDT using U-Boot scripts commands that is something that mentioned in this thread. That is not a robust way to do it and also is not something that a newbie could do it neither.

Also, doing these FDT changes in the bootloader has several disadvantages, besides having to implement on each bootloaders like Tom said, you need to upgrade your bootloader which is something that just can't be done on many boards and also is still a static configuration since you need to reboot in order to use a different FDT. So the hardware can't really be expanded on runtime unlike with DT overlays where the overlays are loaded from regular files.

Quoted 5 lines

But I guess you agree with me on all those points and you just misunderstood my comments. So DT overlays is definitely the way to go (or something similar) but my point is that until we have that solution merged, you can use a static DT in mainline for your stacked cape or use a vendor kernel that already has DT overlays support.

Given that we are not hot plugging capes, why do we need to modify the DT at runtime? Even FPGA developers are not modifying their I/O at runtime. For example, using the BBB as a reference, why not add an am335x-cape-dtsi to the am335x-boneblack.dts as follows:

/dts-v1/;

/include/ "am33xx.dtsi"

/include/ "am335x-bone-common.dtsi²

/include/ ³am335x-cape.dtsi"

&am33xx_pinmux {
xxx

and ³am335x-cape.dtsi² would look like this:

/include/ ³BB-BONE-AUDI-00A0.dtsi²
/include/ ³BB-BONE-UART1-00A0.dtsi²
xxx

So, cape developers create their own DTSI and users only update the am335x-cape.dtsi to include the cape DT required.

What am I missing?

BTW, DTC should be updated to detect I/O conflicts. Waiting for the kernel to boot before detecting DT conflicts isn¹t OK.

Regards,
John

Quoted 10 lines

I hope I explained myself better this time ;-)

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

Hi John,

Quoted 195 lines · John Syn

Quoted 158 lines · Javier Martinez Canillas

Hello Pantelis,

Quoted 77 lines · Pantelis Antoniou

Hi Javier,

Quoted 65 lines · Javier Martinez Canillas

Quoted 63 lines · Matt Porter

Quoted 60 lines · Javier Martinez Canillas

Quoted 19 lines · Tom Rini

Quoted 18 lines · Robert Nelson

Quoted 13 lines

Quoted 5 lines

Either case if fine with me. As who knows when the dtc "overlay" will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.

Quoted 2 lines

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Quoted 8 lines

Quoted 8 lines

Would Tom even approve of that in mainline u-boot? He didn't want my
"invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that describes it.

Quoted 10 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.

Quoted 7 lines

Quoted 6 lines

It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Quoted 3 lines

Since this appears to be all coming back to DT overlays, let me try to address some points.

It seems that you misunderstood my comments. I do think that DT overlays and the cape manager are a great solution for any hardware that could be expanded on runtime and I really hope that they can eventually land into mainline.

In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into mainline..."

Quoted 43 lines

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their
design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his
own
base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 7 lines

Quoted 4 lines

Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

What I said that I'm against is modifying a FDT using U-Boot scripts commands that is something that mentioned in this thread. That is not a robust way to do it and also is not something that a newbie could do it neither.

Also, doing these FDT changes in the bootloader has several disadvantages, besides having to implement on each bootloaders like Tom said, you need to upgrade your bootloader which is something that just can't be done on many boards and also is still a static configuration since you need to reboot in order to use a different FDT. So the hardware can't really be expanded on runtime unlike with DT overlays where the overlays are loaded from regular files.

Quoted 5 lines

But I guess you agree with me on all those points and you just misunderstood my comments. So DT overlays is definitely the way to go (or something similar) but my point is that until we have that solution merged, you can use a static DT in mainline for your stacked cape or use a vendor kernel that already has DT overlays support.

Given that we are not hot plugging capes, why do we need to modify the DT
at runtime? Even FPGA developers are not modifying their I/O at runtime. For example, using the BBB as a reference, why not add an am335x-cape-dtsi
to the am335x-boneblack.dts as follows:

/dts-v1/;

/include/ "am33xx.dtsi"

/include/ "am335x-bone-common.dtsi²

/include/ ³am335x-cape.dtsi"

&am33xx_pinmux {
xxx

and ³am335x-cape.dtsi² would look like this:

/include/ ³BB-BONE-AUDI-00A0.dtsi²
/include/ ³BB-BONE-UART1-00A0.dtsi²
xxx

So, cape developers create their own DTSI and users only update the am335x-cape.dtsi to include the cape DT required.

Quoted 10 lines

What am I missing?

BTW, DTC should be updated to detect I/O conflicts. Waiting for the kernel
to boot before detecting DT conflicts isn¹t OK.

Regards,
John

For a single cape that's fine.

Now handle the case where your cape must work with any kind of cape combination with a same
kernel+dtb+rootfs image.

The point is that you want to get each cape developer contribute back to the official release,
and to get people to use your stuff without recompiling anything.

No-one making distro-releases is willing to handle a few dozens of DTBs for all the combinations.

Regards

-- Pantelis

Quoted 17 lines

Quoted 11 lines

I hope I explained myself better this time ;-)

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

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

Quoted 216 lines · Pantelis Antoniou

Hi John,

Quoted 195 lines · John Syn

Quoted 158 lines · Javier Martinez Canillas

Hello Pantelis,

Quoted 77 lines · Pantelis Antoniou

Hi Javier,

Quoted 65 lines · Javier Martinez Canillas

Quoted 63 lines · Matt Porter

Quoted 60 lines · Javier Martinez Canillas

Quoted 19 lines · Tom Rini

Quoted 18 lines · Robert Nelson

Quoted 13 lines

Quoted 5 lines

Either case if fine with me. As who knows when the dtc "overlay" will
every truly make it mainline, as the capemgr was the only real kernel
user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.

Quoted 2 lines

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Well,

Quoted 8 lines

Quoted 8 lines

Would Tom even approve of that in mainline u-boot? He didn't want my
"invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to
replicate what we used to do from boards files where it was possible
to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then
are two different hardware where each need its proper FDT that describes it.

Quoted 10 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone
to madness quite quickly. Moving all of Pantelis' work for dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they
were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi
and not something that can be added on runtime.

Quoted 7 lines

Quoted 6 lines

It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Quoted 3 lines

Since this appears to be all coming back to DT overlays, let me try to address some points.

It seems that you misunderstood my comments. I do think that DT overlays and the cape manager are a great solution for any hardware that could be expanded on runtime and I really hope that they can eventually land into mainline.

In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into mainline..."

Quoted 43 lines

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for
the base board and the cape in question. Doing that he essentially cuts
himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their
design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his
own
base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic
hardware configuration. There are a number of FPGA people that seem interested
as well.

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 7 lines

Quoted 4 lines

Unfortunately I don't have a solution but what I'm pretty sure is that
mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

What I said that I'm against is modifying a FDT using U-Boot scripts commands that is something that mentioned in this thread. That is not a robust way to do it and also is not something that a newbie could do it neither.

Also, doing these FDT changes in the bootloader has several disadvantages, besides having to implement on each bootloaders like Tom said, you need to upgrade your bootloader which is something that just can't be done on many boards and also is still a static configuration since you need to reboot in order to use a different FDT. So the hardware can't really be expanded on runtime unlike with DT overlays where the overlays are loaded from regular files.

Quoted 5 lines

But I guess you agree with me on all those points and you just misunderstood my comments. So DT overlays is definitely the way to go (or something similar) but my point is that until we have that solution merged, you can use a static DT in mainline for your stacked cape or use a vendor kernel that already has DT overlays support.

Given that we are not hot plugging capes, why do we need to modify the DT
at runtime? Even FPGA developers are not modifying their I/O at runtime. For example, using the BBB as a reference, why not add an am335x-cape-dtsi
to the am335x-boneblack.dts as follows:

/dts-v1/;

/include/ "am33xx.dtsi"

/include/ "am335x-bone-common.dtsi²

/include/ ³am335x-cape.dtsi"

&am33xx_pinmux {
xxx

and ³am335x-cape.dtsi² would look like this:

/include/ ³BB-BONE-AUDI-00A0.dtsi²
/include/ ³BB-BONE-UART1-00A0.dtsi²
xxx

So, cape developers create their own DTSI and users only update the am335x-cape.dtsi to include the cape DT required.

Quoted 10 lines

What am I missing?

BTW, DTC should be updated to detect I/O conflicts. Waiting for the kernel
to boot before detecting DT conflicts isn¹t OK.

Regards,
John

For a single cape that's fine.

Now handle the case where your cape must work with any kind of cape combination with a same
kernel+dtb+rootfs image.

Quoted 6 lines

The point is that you want to get each cape developer contribute back to the official release,
and to get people to use your stuff without recompiling anything.

No-one making distro-releases is willing to handle a few dozens of DTBs for all the combinations.

Hi Pantelis,

I’m not sure I understand the “single cape” comment. If a developer modifies the cape DTSI (e.g. am335x-cape.dtsi) and include definitions for all attached capes, surely this will work for any combinations of capes. From your explanation, it seems you don’t want the developer to run DTC, but you are OK with updating the uEnv.txt file or modifying some cape manager script file to load the DT overlays at boot time.

Until DT overlay makes it into mainline, wouldn’t the cape DTSI solution suffice for now? Can some component that is initally disabled (status = “disabled") be enabled (status = “okay”) via one of the cape DTSI referenced in am335x-cape.dtsi? I prefer not to pollute u-boot with DT info because synching u-boot and the kernel could be a nightmare.

Regards,
John

Quoted 1 line

Hello Pantelis,

Quoted 58 lines · Pantelis Antoniou

Hi Javier,

Quoted 47 lines · Javier Martinez Canillas

Quoted 46 lines · Matt Porter

Quoted 44 lines · Javier Martinez Canillas

Quoted 11 lines · Tom Rini

Quoted 10 lines · Robert Nelson

Quoted 9 lines

Quoted 3 lines

Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information.

Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes.

Anybody working on enabling/disabling cape dtb configurations in u-boot?

Quoted 8 lines

Quoted 8 lines

Well,

Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B..

http://lists.denx.de/pipermail/u-boot/2014-January/172154.html

http://lists.denx.de/pipermail/u-boot/2014-January/172274.html

Using fdt set from the bootloader to use the same FDT for similar boards (like the example with Beagle xM variants) is kind of trying to replicate what we used to do from boards files where it was possible to manage a set of boards using the same platform code.

But Device Trees are meant to describe hardware and thus should be static, if two board are almost identical but slightly different, then are two different hardware where each need its proper FDT that describes it.

Quoted 7 lines

I would think that using the 'fdt' command in U-Boot to add all properties of every cape found on a running system would drive someone to madness quite quickly. Moving all of Pantelis' work for dynamic device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI, etc) sounds like a step in the wrong direction.

Agreed. I think that until the device tree overlay and the cape manager find their way into mainline we should treat capes as if they were expansion boards attached to a Computer-on-Module. That is, a static based board which its own DTS including the BB{B,W} as an dtsi and not something that can be added on runtime.

Quoted 6 lines

Quoted 5 lines

It's far more complicated than a SOM plus carrier board. Consider that you can have any 4 of these capes stacked on the BBB/BBW in any combination (assuming no resource conflicts). Capturing all possible combinations in static dtsis is not practical.

Quoted 3 lines

Since this appears to be all coming back to DT overlays, let me try to address some points.

It seems that you misunderstood my comments. I do think that DT overlays and the cape manager are a great solution for any hardware that could be expanded on runtime and I really hope that they can eventually land into mainline.

In fact if you look on my previous mail you will see that I said:
"until device tree overlay and the cape manager find their way into mainline..."

Quoted 32 lines

Quoted 5 lines

Right, I forgot that the capes were stackable so is indeed not practical to model every single combination as DTS in mainline. Even if stacking was not possible there are just too many capes out there to have a DTS for every single cape.

Each cape does have a DTS as dynamically loaded fragment; it works absolutely fine.

Trying to come up with a base DTS for all the capes you've stacked up is an exponential problem.

Quoted 3 lines

My point was that someone who wants to use a BBB + a set of capes can today write a DTS for its own stacked setup.

No, the guy that designs a cape (or learns how to) can not write a DTS for the base board and the cape in question. Doing that he essentially cuts himself off from the community.

Let me explain, the point is for people to easily design capes, open-source their design as well as their software, and share them to the community.

This requires that things are easily shareable.

Requiring a relative newbie in kernel development not only generate his own base DT, but also to merge all of the other capes DT into his own is a nightmare.

BTW, on another tangent, it's not just the BB people that care about dynamic hardware configuration. There are a number of FPGA people that seem interested as well.

Quoted 8 lines

The notion of hardware as something static that never changes is obsolete IMHO.

Quoted 3 lines

Unfortunately I don't have a solution but what I'm pretty sure is that mangling the DTS from the bootloader is not the right one :-)

No, it is not. And this is what we're trying to solve here.

What I said that I'm against is modifying a FDT using U-Boot scripts commands that is something that mentioned in this thread. That is not a robust way to do it and also is not something that a newbie could do it neither.

Also, doing these FDT changes in the bootloader has several disadvantages, besides having to implement on each bootloaders like Tom said, you need to upgrade your bootloader which is something that just can't be done on many boards and also is still a static configuration since you need to reboot in order to use a different FDT. So the hardware can't really be expanded on runtime unlike with DT overlays where the overlays are loaded from regular files.

But I guess you agree with me on all those points and you just misunderstood my comments. So DT overlays is definitely the way to go (or something similar) but my point is that until we have that solution merged, you can use a static DT in mainline for your stacked cape or use a vendor kernel that already has DT overlays support.

I hope I explained myself better this time ;-)

Best regards,
Javier

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