[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

Add support for the National Instruments Project Sulfur SDR
motherboards Rev 2,3 and 4.

Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
 arch/arm/boot/dts/Makefile                |   3 +
 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
 arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
 5 files changed, 364 insertions(+)
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..9c3317c00aee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -991,6 +991,9 @@ dtb-$(CONFIG_ARCH_VT8500) += \
 dtb-$(CONFIG_ARCH_ZYNQ) += \
 	zynq-microzed.dtb \
 	zynq-parallella.dtb \
+	zynq-ni-sulfur-rev2.dtb \
+	zynq-ni-sulfur-rev3.dtb \
+	zynq-ni-sulfur-rev4.dtb \
 	zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb \
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
new file mode 100644
index 000000000000..8b7c54fe9c59
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
@@ -0,0 +1,84 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev2";
+	compatible = "ettus,zynq-sulfur-rev2", "xlnx,zynq-7000";
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+
+	i2c@4 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+
+		tpm: tpm@20 {
+			compatible = "infineon,slb9645tt";
+			reg = <0x20>;
+
+			interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-parent = <&gpio0>;
+
+			reset-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+
+&spi1 {
+	status = "okay";
+
+	cros_ec: ec@0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		google,cros-ec-spi-msg-delay = <200>;
+		google,cros-ec-spi-pre-delay = <60>;
+		google,has-vbc-nvram;
+		spi-max-frequency = <3000000>;
+
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <1>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+			rtc0: rtc@68 {
+				compatible = "dallas,ds1374";
+				reg = <0x68>;
+			};
+		};
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
new file mode 100644
index 000000000000..fff3a40b507b
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
@@ -0,0 +1,118 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev3";
+	compatible = "ettus,zynq-sulfur-rev3", "xlnx,zynq-7000";
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		power-button {
+			label = "Power Button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+	};
+
+	leds {
+		led0 {
+			label = "sulfur:ledn";
+			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+
+	i2c@3 {
+		reg = <3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio1: gpio@22 {
+			compatible = "ti,tca6424";
+			reg = <0x22>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+	};
+
+	i2c@5 {
+		reg = <5>;
+		status = "okay";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rtc0: rtc@68 {
+			compatible = "dallas,ds1374";
+			reg = <0x68>;
+		};
+	};
+
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	embedded-controller@1e {
+		reg = <0x1e>;
+		compatible = "google,cros-ec-i2c";
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+		google,has-vbc-nvram;
+
+		wakeup-source;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <0>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom@50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+	};
+};
+
+&gpio0 {
+	ledp {
+		gpio-hog;
+		gpios = <5 GPIO_ACTIVE_HIGH>;
+		output-high;
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 50 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 51 GPIO_ACTIVE_LOW>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
new file mode 100644
index 000000000000..2a5b21549e68
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include "zynq-ni-sulfur-rev3.dts"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev4";
+	compatible = "ettus,zynq-sulfur-rev4", "xlnx,zynq-7000";
+};
+
+&i2c_switch0 {
+	i2c@4 {
+		reg = <4>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		tpm: tpm@29 {
+			compatible = "atmel,at97sc3204t";
+			reg = <0x29>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur.dtsi b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
new file mode 100644
index 000000000000..4bf63f09c81a
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-7000.dtsi"
+
+/ {
+	aliases {
+		ethernet0 = &gem0;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		gpio0 = &gpio0;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c20 = &tun;
+		i2c706 = &usrpio_i2c0;
+		i2c707 = &usrpio_i2c1;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	usb_phy0: phy0 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+	};
+};
+
+&cpu0 {
+	operating-points = <800000 1000000>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
+
+&sdhci0 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+/* we use the ARM global timer */
+&ttc0 {
+	status = "disabled";
+};
+
+/* we use the ARM global timer */
+&ttc1 {
+	status = "disabled";
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	i2c_switch0: i2cswitch@70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		usrpio_i2c0: i2c@6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem2: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+		};
+
+		usrpio_i2c1: i2c@7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem3: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+		};
+
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gem0 {
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethernet_phy0>;
+	status = "okay";
+
+	ethernet_phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
+&usb0 {
+	usb-phy = <&usb_phy0>;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&amba {
+	ocm: sram@fffc0000 {
+		compatible = "mmio-sram";
+		reg = <0xfffc0000 0x10000>;
+	};
+};
-- 
2.14.1

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

Add support for the National Instruments Project Sulfur SDR
motherboards Rev 2,3 and 4.

Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/Makefile                |   3 +
 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
 arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
 5 files changed, 364 insertions(+)
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..9c3317c00aee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -991,6 +991,9 @@ dtb-$(CONFIG_ARCH_VT8500) += \
 dtb-$(CONFIG_ARCH_ZYNQ) += \
 	zynq-microzed.dtb \
 	zynq-parallella.dtb \
+	zynq-ni-sulfur-rev2.dtb \
+	zynq-ni-sulfur-rev3.dtb \
+	zynq-ni-sulfur-rev4.dtb \
 	zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb \
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
new file mode 100644
index 000000000000..8b7c54fe9c59
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
@@ -0,0 +1,84 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev2";
+	compatible = "ettus,zynq-sulfur-rev2", "xlnx,zynq-7000";
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+
+	i2c@4 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+
+		tpm: tpm@20 {
+			compatible = "infineon,slb9645tt";
+			reg = <0x20>;
+
+			interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-parent = <&gpio0>;
+
+			reset-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+
+&spi1 {
+	status = "okay";
+
+	cros_ec: ec@0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		google,cros-ec-spi-msg-delay = <200>;
+		google,cros-ec-spi-pre-delay = <60>;
+		google,has-vbc-nvram;
+		spi-max-frequency = <3000000>;
+
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <1>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+			rtc0: rtc@68 {
+				compatible = "dallas,ds1374";
+				reg = <0x68>;
+			};
+		};
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
new file mode 100644
index 000000000000..fff3a40b507b
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
@@ -0,0 +1,118 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev3";
+	compatible = "ettus,zynq-sulfur-rev3", "xlnx,zynq-7000";
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		power-button {
+			label = "Power Button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+	};
+
+	leds {
+		led0 {
+			label = "sulfur:ledn";
+			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+
+	i2c@3 {
+		reg = <3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio1: gpio@22 {
+			compatible = "ti,tca6424";
+			reg = <0x22>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+	};
+
+	i2c@5 {
+		reg = <5>;
+		status = "okay";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rtc0: rtc@68 {
+			compatible = "dallas,ds1374";
+			reg = <0x68>;
+		};
+	};
+
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	embedded-controller@1e {
+		reg = <0x1e>;
+		compatible = "google,cros-ec-i2c";
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+		google,has-vbc-nvram;
+
+		wakeup-source;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <0>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom@50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+	};
+};
+
+&gpio0 {
+	ledp {
+		gpio-hog;
+		gpios = <5 GPIO_ACTIVE_HIGH>;
+		output-high;
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 50 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 51 GPIO_ACTIVE_LOW>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
new file mode 100644
index 000000000000..2a5b21549e68
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include "zynq-ni-sulfur-rev3.dts"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev4";
+	compatible = "ettus,zynq-sulfur-rev4", "xlnx,zynq-7000";
+};
+
+&i2c_switch0 {
+	i2c@4 {
+		reg = <4>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		tpm: tpm@29 {
+			compatible = "atmel,at97sc3204t";
+			reg = <0x29>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur.dtsi b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
new file mode 100644
index 000000000000..4bf63f09c81a
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-7000.dtsi"
+
+/ {
+	aliases {
+		ethernet0 = &gem0;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		gpio0 = &gpio0;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c20 = &tun;
+		i2c706 = &usrpio_i2c0;
+		i2c707 = &usrpio_i2c1;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	usb_phy0: phy0 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+	};
+};
+
+&cpu0 {
+	operating-points = <800000 1000000>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
+
+&sdhci0 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+/* we use the ARM global timer */
+&ttc0 {
+	status = "disabled";
+};
+
+/* we use the ARM global timer */
+&ttc1 {
+	status = "disabled";
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	i2c_switch0: i2cswitch@70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		usrpio_i2c0: i2c@6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem2: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+		};
+
+		usrpio_i2c1: i2c@7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem3: eeprom@50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+		};
+
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gem0 {
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethernet_phy0>;
+	status = "okay";
+
+	ethernet_phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
+&usb0 {
+	usb-phy = <&usb_phy0>;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&amba {
+	ocm: sram@fffc0000 {
+		compatible = "mmio-sram";
+		reg = <0xfffc0000 0x10000>;
+	};
+};
-- 
2.14.1

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

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

Add support for the National Instruments Project Sulfur SDR
motherboards Rev 2,3 and 4.

Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
 arch/arm/boot/dts/Makefile                |   3 +
 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
 arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
 5 files changed, 364 insertions(+)
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
 create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4b17f35dc9a7..9c3317c00aee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -991,6 +991,9 @@ dtb-$(CONFIG_ARCH_VT8500) += \
 dtb-$(CONFIG_ARCH_ZYNQ) += \
 	zynq-microzed.dtb \
 	zynq-parallella.dtb \
+	zynq-ni-sulfur-rev2.dtb \
+	zynq-ni-sulfur-rev3.dtb \
+	zynq-ni-sulfur-rev4.dtb \
 	zynq-zc702.dtb \
 	zynq-zc706.dtb \
 	zynq-zed.dtb \
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
new file mode 100644
index 000000000000..8b7c54fe9c59
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
@@ -0,0 +1,84 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev2";
+	compatible = "ettus,zynq-sulfur-rev2", "xlnx,zynq-7000";
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+
+	i2c at 4 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+
+		tpm: tpm at 20 {
+			compatible = "infineon,slb9645tt";
+			reg = <0x20>;
+
+			interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-parent = <&gpio0>;
+
+			reset-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
+
+&spi1 {
+	status = "okay";
+
+	cros_ec: ec at 0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		google,cros-ec-spi-msg-delay = <200>;
+		google,cros-ec-spi-pre-delay = <60>;
+		google,has-vbc-nvram;
+		spi-max-frequency = <3000000>;
+
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <1>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom at 50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+			rtc0: rtc at 68 {
+				compatible = "dallas,ds1374";
+				reg = <0x68>;
+			};
+		};
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
new file mode 100644
index 000000000000..fff3a40b507b
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
@@ -0,0 +1,118 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "zynq-ni-sulfur.dtsi"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev3";
+	compatible = "ettus,zynq-sulfur-rev3", "xlnx,zynq-7000";
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		power-button {
+			label = "Power Button";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	gpio-poweroff {
+		compatible = "gpio-poweroff";
+		gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+	};
+
+	leds {
+		led0 {
+			label = "sulfur:ledn";
+			gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&i2c_switch0 {
+	reset-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+
+	i2c at 3 {
+		reg = <3>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		gpio1: gpio at 22 {
+			compatible = "ti,tca6424";
+			reg = <0x22>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+	};
+
+	i2c at 5 {
+		reg = <5>;
+		status = "okay";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rtc0: rtc at 68 {
+			compatible = "dallas,ds1374";
+			reg = <0x68>;
+		};
+	};
+
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	status = "okay";
+
+	embedded-controller at 1e {
+		reg = <0x1e>;
+		compatible = "google,cros-ec-i2c";
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio0>;
+		google,has-vbc-nvram;
+
+		wakeup-source;
+
+		tun: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			google,remote-bus = <0>;
+			clock-frequency = <50000>;
+
+			nvmem0: eeprom at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+	};
+};
+
+&gpio0 {
+	ledp {
+		gpio-hog;
+		gpios = <5 GPIO_ACTIVE_HIGH>;
+		output-high;
+	};
+};
+
+&ethernet_phy0 {
+	reset-gpios = <&gpio0 50 GPIO_ACTIVE_LOW>;
+};
+
+&usb_phy0 {
+	reset-gpios = <&gpio0 51 GPIO_ACTIVE_LOW>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
new file mode 100644
index 000000000000..2a5b21549e68
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+#include "zynq-ni-sulfur-rev3.dts"
+
+/ {
+	model = "NI/Ettus Research Project Sulfur SDR Rev4";
+	compatible = "ettus,zynq-sulfur-rev4", "xlnx,zynq-7000";
+};
+
+&i2c_switch0 {
+	i2c at 4 {
+		reg = <4>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		tpm: tpm at 29 {
+			compatible = "atmel,at97sc3204t";
+			reg = <0x29>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/zynq-ni-sulfur.dtsi b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
new file mode 100644
index 000000000000..4bf63f09c81a
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-ni-sulfur.dtsi
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2016,2017 National Instruments Corp.
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR X11)
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "zynq-7000.dtsi"
+
+/ {
+	aliases {
+		ethernet0 = &gem0;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		gpio0 = &gpio0;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c20 = &tun;
+		i2c706 = &usrpio_i2c0;
+		i2c707 = &usrpio_i2c1;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	usb_phy0: phy0 {
+		compatible = "usb-nop-xceiv";
+		#phy-cells = <0>;
+	};
+};
+
+&cpu0 {
+	operating-points = <800000 1000000>;
+};
+
+&clkc {
+	ps-clk-frequency = <33333333>;
+};
+
+&sdhci0 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+/* we use the ARM global timer */
+&ttc0 {
+	status = "disabled";
+};
+
+/* we use the ARM global timer */
+&ttc1 {
+	status = "disabled";
+};
+
+&i2c0 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	i2c_switch0: i2cswitch at 70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		usrpio_i2c0: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem2: eeprom at 50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+
+		};
+
+		usrpio_i2c1: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+
+			nvmem3: eeprom at 50 {
+				compatible = "atmel,24c256";
+				reg = <0x50>;
+			};
+		};
+
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gem0 {
+	phy-mode = "rgmii-id";
+	phy-handle = <&ethernet_phy0>;
+	status = "okay";
+
+	ethernet_phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
+
+&usb0 {
+	usb-phy = <&usb_phy0>;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&amba {
+	ocm: sram at fffc0000 {
+		compatible = "mmio-sram";
+		reg = <0xfffc0000 0x10000>;
+	};
+};
-- 
2.14.1

[PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files

[Moritz Fischer]

Add contact info for National Instruments Project Sulfur SDR files.

Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a3231bd6541d..aa54be9213bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1609,6 +1609,13 @@ ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
 M:	Michael Petchkovsky <mkpetch@internode.on.net>
 S:	Maintained
 
+ARM/NATIONAL INSTRUMENTS PROJECT SULFUR SDR
+M:	Moritz Fischer <mdf@kernel.org>
+L:	usrp-users@lists.ettus.com (moderated for non-subscribers)
+W:	http://www.ettus.com
+S:	Supported
+F:	arch/arm/boot/dts/zynq-ni-sulfur*
+
 ARM/NOMADIK ARCHITECTURE
 M:	Alessandro Rubini <rubini@unipv.it>
 M:	Linus Walleij <linus.walleij@linaro.org>
-- 
2.14.1

[PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files

[Moritz Fischer]

Add contact info for National Instruments Project Sulfur SDR files.

Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a3231bd6541d..aa54be9213bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1609,6 +1609,13 @@ ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
 M:	Michael Petchkovsky <mkpetch-CkBdp7X+a1oIQCUVoCVjmQ@public.gmane.org>
 S:	Maintained
 
+ARM/NATIONAL INSTRUMENTS PROJECT SULFUR SDR
+M:	Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
+L:	usrp-users-p6fHTpcPDZaz3Dx2OeFgIA@public.gmane.org (moderated for non-subscribers)
+W:	http://www.ettus.com
+S:	Supported
+F:	arch/arm/boot/dts/zynq-ni-sulfur*
+
 ARM/NOMADIK ARCHITECTURE
 M:	Alessandro Rubini <rubini-9wsNiZum9E8@public.gmane.org>
 M:	Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
-- 
2.14.1

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

[PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files

[Moritz Fischer]

Add contact info for National Instruments Project Sulfur SDR files.

Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a3231bd6541d..aa54be9213bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1609,6 +1609,13 @@ ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
 M:	Michael Petchkovsky <mkpetch@internode.on.net>
 S:	Maintained
 
+ARM/NATIONAL INSTRUMENTS PROJECT SULFUR SDR
+M:	Moritz Fischer <mdf@kernel.org>
+L:	usrp-users at lists.ettus.com (moderated for non-subscribers)
+W:	http://www.ettus.com
+S:	Supported
+F:	arch/arm/boot/dts/zynq-ni-sulfur*
+
 ARM/NOMADIK ARCHITECTURE
 M:	Alessandro Rubini <rubini@unipv.it>
 M:	Linus Walleij <linus.walleij@linaro.org>
-- 
2.14.1

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi Moritz

sorry for delay.

On 12.9.2017 01:22, Moritz Fischer wrote:
> Add support for the National Instruments Project Sulfur SDR
> motherboards Rev 2,3 and 4.
> 
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> ---
>  arch/arm/boot/dts/Makefile                |   3 +
>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>  5 files changed, 364 insertions(+)
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

Is this publicly available board?

I am not quite sure we should apply these dts files. There are a lot of
boards with zynq and there must be any strong argument for applying this
to the tree. For arm32 with even flat tree structure.

Arnd: Do you have any policy about it?

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi Moritz

sorry for delay.

On 12.9.2017 01:22, Moritz Fischer wrote:
> Add support for the National Instruments Project Sulfur SDR
> motherboards Rev 2,3 and 4.
> 
> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/Makefile                |   3 +
>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>  5 files changed, 364 insertions(+)
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

Is this publicly available board?

I am not quite sure we should apply these dts files. There are a lot of
boards with zynq and there must be any strong argument for applying this
to the tree. For arm32 with even flat tree structure.

Arnd: Do you have any policy about it?

Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi Moritz

sorry for delay.

On 12.9.2017 01:22, Moritz Fischer wrote:
> Add support for the National Instruments Project Sulfur SDR
> motherboards Rev 2,3 and 4.
> 
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> ---
>  arch/arm/boot/dts/Makefile                |   3 +
>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>  5 files changed, 364 insertions(+)
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

Is this publicly available board?

I am not quite sure we should apply these dts files. There are a lot of
boards with zynq and there must be any strong argument for applying this
to the tree. For arm32 with even flat tree structure.

Arnd: Do you have any policy about it?

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Hi Michal,

On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> Hi Moritz
> 
> sorry for delay.

No problem.

> 
> On 12.9.2017 01:22, Moritz Fischer wrote:
> > Add support for the National Instruments Project Sulfur SDR
> > motherboards Rev 2,3 and 4.
> > 
> > Signed-off-by: Moritz Fischer <mdf@kernel.org>
> > ---
> >  arch/arm/boot/dts/Makefile                |   3 +
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >  5 files changed, 364 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> 
> Is this publicly available board?

Will be in Q1 2018 was announced at GRCon'17 ([1]).
Some of the Rev3s are currently deployed in Norway as part of a radar
system.

> I am not quite sure we should apply these dts files. There are a lot of
> boards with zynq and there must be any strong argument for applying this
> to the tree. For arm32 with even flat tree structure.

What's the issue with merging them, except for having 3 more files? 

> Arnd: Do you have any policy about it?
> 
> Thanks,
> Michal

Thanks,

Moritz

[1] https://drive.google.com/file/d/0B-CV_07uSBIuODc5bmV2QXhnODA/view

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

Hi Michal,

On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> Hi Moritz
> 
> sorry for delay.

No problem.

> 
> On 12.9.2017 01:22, Moritz Fischer wrote:
> > Add support for the National Instruments Project Sulfur SDR
> > motherboards Rev 2,3 and 4.
> > 
> > Signed-off-by: Moritz Fischer <mdf@kernel.org>
> > ---
> >  arch/arm/boot/dts/Makefile                |   3 +
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >  5 files changed, 364 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> 
> Is this publicly available board?

Will be in Q1 2018 was announced at GRCon'17 ([1]).
Some of the Rev3s are currently deployed in Norway as part of a radar
system.

> I am not quite sure we should apply these dts files. There are a lot of
> boards with zynq and there must be any strong argument for applying this
> to the tree. For arm32 with even flat tree structure.

What's the issue with merging them, except for having 3 more files? 

> Arnd: Do you have any policy about it?
> 
> Thanks,
> Michal

Thanks,

Moritz

[1] https://drive.google.com/file/d/0B-CV_07uSBIuODc5bmV2QXhnODA/view
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170925/0827281e/attachment.sig>

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi,

On 25.9.2017 18:11, Moritz Fischer wrote:
> Hi Michal,
> 
> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>> Hi Moritz
>>
>> sorry for delay.
> 
> No problem.
> 
>>
>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>> Add support for the National Instruments Project Sulfur SDR
>>> motherboards Rev 2,3 and 4.
>>>
>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>> ---
>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>  5 files changed, 364 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>
>> Is this publicly available board?
> 
> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> Some of the Rev3s are currently deployed in Norway as part of a radar
> system.
> 
>> I am not quite sure we should apply these dts files. There are a lot of
>> boards with zynq and there must be any strong argument for applying this
>> to the tree. For arm32 with even flat tree structure.
> 
> What's the issue with merging them, except for having 3 more files? 

For me this is not a problem because on Linux side it is not increasing
build time.
I want to see the value for community. All xilinx platforms are
evaluation generic purpose boards which are showing how to connect stuff
together.
On the other hand this is real product.

I would let arm-soc maintainer to decide if this is fine or not. I
definitely don't want to end up in situation that we will have dts for
real products which are not bringing any value for others.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi,

On 25.9.2017 18:11, Moritz Fischer wrote:
> Hi Michal,
> 
> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>> Hi Moritz
>>
>> sorry for delay.
> 
> No problem.
> 
>>
>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>> Add support for the National Instruments Project Sulfur SDR
>>> motherboards Rev 2,3 and 4.
>>>
>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> ---
>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>  5 files changed, 364 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>
>> Is this publicly available board?
> 
> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> Some of the Rev3s are currently deployed in Norway as part of a radar
> system.
> 
>> I am not quite sure we should apply these dts files. There are a lot of
>> boards with zynq and there must be any strong argument for applying this
>> to the tree. For arm32 with even flat tree structure.
> 
> What's the issue with merging them, except for having 3 more files? 

For me this is not a problem because on Linux side it is not increasing
build time.
I want to see the value for community. All xilinx platforms are
evaluation generic purpose boards which are showing how to connect stuff
together.
On the other hand this is real product.

I would let arm-soc maintainer to decide if this is fine or not. I
definitely don't want to end up in situation that we will have dts for
real products which are not bringing any value for others.

Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi,

On 25.9.2017 18:11, Moritz Fischer wrote:
> Hi Michal,
> 
> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>> Hi Moritz
>>
>> sorry for delay.
> 
> No problem.
> 
>>
>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>> Add support for the National Instruments Project Sulfur SDR
>>> motherboards Rev 2,3 and 4.
>>>
>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>> ---
>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>  5 files changed, 364 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>
>> Is this publicly available board?
> 
> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> Some of the Rev3s are currently deployed in Norway as part of a radar
> system.
> 
>> I am not quite sure we should apply these dts files. There are a lot of
>> boards with zynq and there must be any strong argument for applying this
>> to the tree. For arm32 with even flat tree structure.
> 
> What's the issue with merging them, except for having 3 more files? 

For me this is not a problem because on Linux side it is not increasing
build time.
I want to see the value for community. All xilinx platforms are
evaluation generic purpose boards which are showing how to connect stuff
together.
On the other hand this is real product.

I would let arm-soc maintainer to decide if this is fine or not. I
definitely don't want to end up in situation that we will have dts for
real products which are not bringing any value for others.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]

Michal,

On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> Hi,
> 
> On 25.9.2017 18:11, Moritz Fischer wrote:
> > Hi Michal,
> > 
> > On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >> Hi Moritz
> >>
> >> sorry for delay.
> > 
> > No problem.
> > 
> >>
> >> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>> Add support for the National Instruments Project Sulfur SDR
> >>> motherboards Rev 2,3 and 4.
> >>>
> >>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> >>> ---
> >>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>  5 files changed, 364 insertions(+)
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>
> >> Is this publicly available board?
> > 
> > Will be in Q1 2018 was announced at GRCon'17 ([1]).
> > Some of the Rev3s are currently deployed in Norway as part of a radar
> > system.
> > 
> >> I am not quite sure we should apply these dts files. There are a lot of
> >> boards with zynq and there must be any strong argument for applying this
> >> to the tree. For arm32 with even flat tree structure.
> > 
> > What's the issue with merging them, except for having 3 more files? 
> 
> For me this is not a problem because on Linux side it is not increasing
> build time.
> I want to see the value for community. All xilinx platforms are
> evaluation generic purpose boards which are showing how to connect stuff
> together.
> On the other hand this is real product.

Uh.

> I would let arm-soc maintainer to decide if this is fine or not. I
> definitely don't want to end up in situation that we will have dts for
> real products which are not bringing any value for others.

Sure, it's the maintainers call.

I do intend to have my customers run mainline on it eventually, currently
I'm a handful of patches away from making that happen. So yes, running
mainline is a usecase that matters to me.

It is one thing to keep bitching about vendor kernels as a community
continuously, but then if someone goes through the effort and actually
tries to run mainline, you give them crap like that above.

Our products usually come with full schematics [1], firmware, fpga code and all
available, I don't know what makes them less useful to the community as a
platform to experiment and develop on than Xilinx eval boards.

There's several people that I know of both hobbyists and companies that
build systems around these platforms, so I don't know ...

- Moritz

[1] http://files.ettus.com/schematics/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

Michal,

On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> Hi,
> 
> On 25.9.2017 18:11, Moritz Fischer wrote:
> > Hi Michal,
> > 
> > On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >> Hi Moritz
> >>
> >> sorry for delay.
> > 
> > No problem.
> > 
> >>
> >> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>> Add support for the National Instruments Project Sulfur SDR
> >>> motherboards Rev 2,3 and 4.
> >>>
> >>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>> ---
> >>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>  5 files changed, 364 insertions(+)
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>
> >> Is this publicly available board?
> > 
> > Will be in Q1 2018 was announced at GRCon'17 ([1]).
> > Some of the Rev3s are currently deployed in Norway as part of a radar
> > system.
> > 
> >> I am not quite sure we should apply these dts files. There are a lot of
> >> boards with zynq and there must be any strong argument for applying this
> >> to the tree. For arm32 with even flat tree structure.
> > 
> > What's the issue with merging them, except for having 3 more files? 
> 
> For me this is not a problem because on Linux side it is not increasing
> build time.
> I want to see the value for community. All xilinx platforms are
> evaluation generic purpose boards which are showing how to connect stuff
> together.
> On the other hand this is real product.

Uh.

> I would let arm-soc maintainer to decide if this is fine or not. I
> definitely don't want to end up in situation that we will have dts for
> real products which are not bringing any value for others.

Sure, it's the maintainers call.

I do intend to have my customers run mainline on it eventually, currently
I'm a handful of patches away from making that happen. So yes, running
mainline is a usecase that matters to me.

It is one thing to keep bitching about vendor kernels as a community
continuously, but then if someone goes through the effort and actually
tries to run mainline, you give them crap like that above.

Our products usually come with full schematics [1], firmware, fpga code and all
available, I don't know what makes them less useful to the community as a
platform to experiment and develop on than Xilinx eval boards.

There's several people that I know of both hobbyists and companies that
build systems around these platforms, so I don't know ...

- Moritz

[1] http://files.ettus.com/schematics/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

Michal,

On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> Hi,
> 
> On 25.9.2017 18:11, Moritz Fischer wrote:
> > Hi Michal,
> > 
> > On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >> Hi Moritz
> >>
> >> sorry for delay.
> > 
> > No problem.
> > 
> >>
> >> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>> Add support for the National Instruments Project Sulfur SDR
> >>> motherboards Rev 2,3 and 4.
> >>>
> >>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> >>> ---
> >>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>  5 files changed, 364 insertions(+)
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>
> >> Is this publicly available board?
> > 
> > Will be in Q1 2018 was announced at GRCon'17 ([1]).
> > Some of the Rev3s are currently deployed in Norway as part of a radar
> > system.
> > 
> >> I am not quite sure we should apply these dts files. There are a lot of
> >> boards with zynq and there must be any strong argument for applying this
> >> to the tree. For arm32 with even flat tree structure.
> > 
> > What's the issue with merging them, except for having 3 more files? 
> 
> For me this is not a problem because on Linux side it is not increasing
> build time.
> I want to see the value for community. All xilinx platforms are
> evaluation generic purpose boards which are showing how to connect stuff
> together.
> On the other hand this is real product.

Uh.

> I would let arm-soc maintainer to decide if this is fine or not. I
> definitely don't want to end up in situation that we will have dts for
> real products which are not bringing any value for others.

Sure, it's the maintainers call.

I do intend to have my customers run mainline on it eventually, currently
I'm a handful of patches away from making that happen. So yes, running
mainline is a usecase that matters to me.

It is one thing to keep bitching about vendor kernels as a community
continuously, but then if someone goes through the effort and actually
tries to run mainline, you give them crap like that above.

Our products usually come with full schematics [1], firmware, fpga code and all
available, I don't know what makes them less useful to the community as a
platform to experiment and develop on than Xilinx eval boards.

There's several people that I know of both hobbyists and companies that
build systems around these platforms, so I don't know ...

- Moritz

[1] http://files.ettus.com/schematics/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170926/9b76af0d/attachment.sig>

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

[-- Attachment #1.1: Type: text/plain, Size: 3428 bytes --]

On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> Michal,
> 
> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>> Hi,
>>
>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>> Hi Michal,
>>>
>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>> Hi Moritz
>>>>
>>>> sorry for delay.
>>>
>>> No problem.
>>>
>>>>
>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>> motherboards Rev 2,3 and 4.
>>>>>
>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>  5 files changed, 364 insertions(+)
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>
>>>> Is this publicly available board?
>>>
>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>> system.
>>>
>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>> boards with zynq and there must be any strong argument for applying this
>>>> to the tree. For arm32 with even flat tree structure.
>>>
>>> What's the issue with merging them, except for having 3 more files? 
>>
>> For me this is not a problem because on Linux side it is not increasing
>> build time.
>> I want to see the value for community. All xilinx platforms are
>> evaluation generic purpose boards which are showing how to connect stuff
>> together.
>> On the other hand this is real product.
> 
> Uh.
> 
>> I would let arm-soc maintainer to decide if this is fine or not. I
>> definitely don't want to end up in situation that we will have dts for
>> real products which are not bringing any value for others.
> 
> Sure, it's the maintainers call.
> 
> I do intend to have my customers run mainline on it eventually, currently
> I'm a handful of patches away from making that happen. So yes, running
> mainline is a usecase that matters to me.
> 
> It is one thing to keep bitching about vendor kernels as a community
> continuously, but then if someone goes through the effort and actually
> tries to run mainline, you give them crap like that above.
> 
> Our products usually come with full schematics [1], firmware, fpga code and all
> available, I don't know what makes them less useful to the community as a
> platform to experiment and develop on than Xilinx eval boards.
> 
> There's several people that I know of both hobbyists and companies that
> build systems around these platforms, so I don't know ...

I expect this product to be delivered with full source and a mainline
kernel, so lets make it easy for Moritz to do the right thing here. This
makes long term support of this product much easier.

Acked-by: Philip Balister <philip@opensdr.com>

Philip

> 
> - Moritz
> 
> [1] http://files.ettus.com/schematics/
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

[-- Attachment #1.1.1: Type: text/plain, Size: 3428 bytes --]

On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> Michal,
> 
> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>> Hi,
>>
>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>> Hi Michal,
>>>
>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>> Hi Moritz
>>>>
>>>> sorry for delay.
>>>
>>> No problem.
>>>
>>>>
>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>> motherboards Rev 2,3 and 4.
>>>>>
>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>  5 files changed, 364 insertions(+)
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>
>>>> Is this publicly available board?
>>>
>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>> system.
>>>
>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>> boards with zynq and there must be any strong argument for applying this
>>>> to the tree. For arm32 with even flat tree structure.
>>>
>>> What's the issue with merging them, except for having 3 more files? 
>>
>> For me this is not a problem because on Linux side it is not increasing
>> build time.
>> I want to see the value for community. All xilinx platforms are
>> evaluation generic purpose boards which are showing how to connect stuff
>> together.
>> On the other hand this is real product.
> 
> Uh.
> 
>> I would let arm-soc maintainer to decide if this is fine or not. I
>> definitely don't want to end up in situation that we will have dts for
>> real products which are not bringing any value for others.
> 
> Sure, it's the maintainers call.
> 
> I do intend to have my customers run mainline on it eventually, currently
> I'm a handful of patches away from making that happen. So yes, running
> mainline is a usecase that matters to me.
> 
> It is one thing to keep bitching about vendor kernels as a community
> continuously, but then if someone goes through the effort and actually
> tries to run mainline, you give them crap like that above.
> 
> Our products usually come with full schematics [1], firmware, fpga code and all
> available, I don't know what makes them less useful to the community as a
> platform to experiment and develop on than Xilinx eval boards.
> 
> There's several people that I know of both hobbyists and companies that
> build systems around these platforms, so I don't know ...

I expect this product to be delivered with full source and a mainline
kernel, so lets make it easy for Moritz to do the right thing here. This
makes long term support of this product much easier.

Acked-by: Philip Balister <philip@opensdr.com>

Philip

> 
> - Moritz
> 
> [1] http://files.ettus.com/schematics/
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> Michal,
> 
> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>> Hi,
>>
>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>> Hi Michal,
>>>
>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>> Hi Moritz
>>>>
>>>> sorry for delay.
>>>
>>> No problem.
>>>
>>>>
>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>> motherboards Rev 2,3 and 4.
>>>>>
>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>  5 files changed, 364 insertions(+)
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>
>>>> Is this publicly available board?
>>>
>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>> system.
>>>
>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>> boards with zynq and there must be any strong argument for applying this
>>>> to the tree. For arm32 with even flat tree structure.
>>>
>>> What's the issue with merging them, except for having 3 more files? 
>>
>> For me this is not a problem because on Linux side it is not increasing
>> build time.
>> I want to see the value for community. All xilinx platforms are
>> evaluation generic purpose boards which are showing how to connect stuff
>> together.
>> On the other hand this is real product.
> 
> Uh.
> 
>> I would let arm-soc maintainer to decide if this is fine or not. I
>> definitely don't want to end up in situation that we will have dts for
>> real products which are not bringing any value for others.
> 
> Sure, it's the maintainers call.
> 
> I do intend to have my customers run mainline on it eventually, currently
> I'm a handful of patches away from making that happen. So yes, running
> mainline is a usecase that matters to me.
> 
> It is one thing to keep bitching about vendor kernels as a community
> continuously, but then if someone goes through the effort and actually
> tries to run mainline, you give them crap like that above.
> 
> Our products usually come with full schematics [1], firmware, fpga code and all
> available, I don't know what makes them less useful to the community as a
> platform to experiment and develop on than Xilinx eval boards.
> 
> There's several people that I know of both hobbyists and companies that
> build systems around these platforms, so I don't know ...

I expect this product to be delivered with full source and a mainline
kernel, so lets make it easy for Moritz to do the right thing here. This
makes long term support of this product much easier.

Acked-by: Philip Balister <philip@opensdr.com>

Philip

> 
> - Moritz
> 
> [1] http://files.ettus.com/schematics/
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 516 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170926/a7b5fe99/attachment-0001.sig>

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 19:58, Philip Balister wrote:
> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>> Michal,
>>
>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>> Hi,
>>>
>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>> Hi Michal,
>>>>
>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>> Hi Moritz
>>>>>
>>>>> sorry for delay.
>>>>
>>>> No problem.
>>>>
>>>>>
>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>> motherboards Rev 2,3 and 4.
>>>>>>
>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>  5 files changed, 364 insertions(+)
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>
>>>>> Is this publicly available board?
>>>>
>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>> system.
>>>>
>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>> boards with zynq and there must be any strong argument for applying this
>>>>> to the tree. For arm32 with even flat tree structure.
>>>>
>>>> What's the issue with merging them, except for having 3 more files? 
>>>
>>> For me this is not a problem because on Linux side it is not increasing
>>> build time.
>>> I want to see the value for community. All xilinx platforms are
>>> evaluation generic purpose boards which are showing how to connect stuff
>>> together.
>>> On the other hand this is real product.
>>
>> Uh.
>>
>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>> definitely don't want to end up in situation that we will have dts for
>>> real products which are not bringing any value for others.
>>
>> Sure, it's the maintainers call.
>>
>> I do intend to have my customers run mainline on it eventually, currently
>> I'm a handful of patches away from making that happen. So yes, running
>> mainline is a usecase that matters to me.
>>
>> It is one thing to keep bitching about vendor kernels as a community
>> continuously, but then if someone goes through the effort and actually
>> tries to run mainline, you give them crap like that above.
>>
>> Our products usually come with full schematics [1], firmware, fpga code and all
>> available, I don't know what makes them less useful to the community as a
>> platform to experiment and develop on than Xilinx eval boards.
>>
>> There's several people that I know of both hobbyists and companies that
>> build systems around these platforms, so I don't know ...
> 
> I expect this product to be delivered with full source and a mainline
> kernel, so lets make it easy for Moritz to do the right thing here. This
> makes long term support of this product much easier.
> 
> Acked-by: Philip Balister <philip@opensdr.com>

I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
and I will merge this.
I am simply just afraid that if a lot of zynq customers will ask for it
we can will end up with a lot of zynq/zynqmp based dts files in the
kernel and arm-soc guys will stop this that it is simply too much and
won't accept +1 case.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 19:58, Philip Balister wrote:
> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>> Michal,
>>
>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>> Hi,
>>>
>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>> Hi Michal,
>>>>
>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>> Hi Moritz
>>>>>
>>>>> sorry for delay.
>>>>
>>>> No problem.
>>>>
>>>>>
>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>> motherboards Rev 2,3 and 4.
>>>>>>
>>>>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>  5 files changed, 364 insertions(+)
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>
>>>>> Is this publicly available board?
>>>>
>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>> system.
>>>>
>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>> boards with zynq and there must be any strong argument for applying this
>>>>> to the tree. For arm32 with even flat tree structure.
>>>>
>>>> What's the issue with merging them, except for having 3 more files? 
>>>
>>> For me this is not a problem because on Linux side it is not increasing
>>> build time.
>>> I want to see the value for community. All xilinx platforms are
>>> evaluation generic purpose boards which are showing how to connect stuff
>>> together.
>>> On the other hand this is real product.
>>
>> Uh.
>>
>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>> definitely don't want to end up in situation that we will have dts for
>>> real products which are not bringing any value for others.
>>
>> Sure, it's the maintainers call.
>>
>> I do intend to have my customers run mainline on it eventually, currently
>> I'm a handful of patches away from making that happen. So yes, running
>> mainline is a usecase that matters to me.
>>
>> It is one thing to keep bitching about vendor kernels as a community
>> continuously, but then if someone goes through the effort and actually
>> tries to run mainline, you give them crap like that above.
>>
>> Our products usually come with full schematics [1], firmware, fpga code and all
>> available, I don't know what makes them less useful to the community as a
>> platform to experiment and develop on than Xilinx eval boards.
>>
>> There's several people that I know of both hobbyists and companies that
>> build systems around these platforms, so I don't know ...
> 
> I expect this product to be delivered with full source and a mainline
> kernel, so lets make it easy for Moritz to do the right thing here. This
> makes long term support of this product much easier.
> 
> Acked-by: Philip Balister <philip-7I+KllWURj5BDgjK7y7TUQ@public.gmane.org>

I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
and I will merge this.
I am simply just afraid that if a lot of zynq customers will ask for it
we can will end up with a lot of zynq/zynqmp based dts files in the
kernel and arm-soc guys will stop this that it is simply too much and
won't accept +1 case.

Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 19:58, Philip Balister wrote:
> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>> Michal,
>>
>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>> Hi,
>>>
>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>> Hi Michal,
>>>>
>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>> Hi Moritz
>>>>>
>>>>> sorry for delay.
>>>>
>>>> No problem.
>>>>
>>>>>
>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>> motherboards Rev 2,3 and 4.
>>>>>>
>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>  5 files changed, 364 insertions(+)
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>
>>>>> Is this publicly available board?
>>>>
>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>> system.
>>>>
>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>> boards with zynq and there must be any strong argument for applying this
>>>>> to the tree. For arm32 with even flat tree structure.
>>>>
>>>> What's the issue with merging them, except for having 3 more files? 
>>>
>>> For me this is not a problem because on Linux side it is not increasing
>>> build time.
>>> I want to see the value for community. All xilinx platforms are
>>> evaluation generic purpose boards which are showing how to connect stuff
>>> together.
>>> On the other hand this is real product.
>>
>> Uh.
>>
>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>> definitely don't want to end up in situation that we will have dts for
>>> real products which are not bringing any value for others.
>>
>> Sure, it's the maintainers call.
>>
>> I do intend to have my customers run mainline on it eventually, currently
>> I'm a handful of patches away from making that happen. So yes, running
>> mainline is a usecase that matters to me.
>>
>> It is one thing to keep bitching about vendor kernels as a community
>> continuously, but then if someone goes through the effort and actually
>> tries to run mainline, you give them crap like that above.
>>
>> Our products usually come with full schematics [1], firmware, fpga code and all
>> available, I don't know what makes them less useful to the community as a
>> platform to experiment and develop on than Xilinx eval boards.
>>
>> There's several people that I know of both hobbyists and companies that
>> build systems around these platforms, so I don't know ...
> 
> I expect this product to be delivered with full source and a mainline
> kernel, so lets make it easy for Moritz to do the right thing here. This
> makes long term support of this product much easier.
> 
> Acked-by: Philip Balister <philip@opensdr.com>

I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
and I will merge this.
I am simply just afraid that if a lot of zynq customers will ask for it
we can will end up with a lot of zynq/zynqmp based dts files in the
kernel and arm-soc guys will stop this that it is simply too much and
won't accept +1 case.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 09/26/2017 02:06 PM, Michal Simek wrote:
> On 26.9.2017 19:58, Philip Balister wrote:
>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>> Michal,
>>>
>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>> Hi Moritz
>>>>>>
>>>>>> sorry for delay.
>>>>>
>>>>> No problem.
>>>>>
>>>>>>
>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>
>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>
>>>>>> Is this publicly available board?
>>>>>
>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>> system.
>>>>>
>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>
>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>
>>>> For me this is not a problem because on Linux side it is not increasing
>>>> build time.
>>>> I want to see the value for community. All xilinx platforms are
>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>> together.
>>>> On the other hand this is real product.
>>>
>>> Uh.
>>>
>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>> definitely don't want to end up in situation that we will have dts for
>>>> real products which are not bringing any value for others.
>>>
>>> Sure, it's the maintainers call.
>>>
>>> I do intend to have my customers run mainline on it eventually, currently
>>> I'm a handful of patches away from making that happen. So yes, running
>>> mainline is a usecase that matters to me.
>>>
>>> It is one thing to keep bitching about vendor kernels as a community
>>> continuously, but then if someone goes through the effort and actually
>>> tries to run mainline, you give them crap like that above.
>>>
>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>> available, I don't know what makes them less useful to the community as a
>>> platform to experiment and develop on than Xilinx eval boards.
>>>
>>> There's several people that I know of both hobbyists and companies that
>>> build systems around these platforms, so I don't know ...
>>
>> I expect this product to be delivered with full source and a mainline
>> kernel, so lets make it easy for Moritz to do the right thing here. This
>> makes long term support of this product much easier.
>>
>> Acked-by: Philip Balister <philip@opensdr.com>
> 
> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> and I will merge this.
> I am simply just afraid that if a lot of zynq customers will ask for it
> we can will end up with a lot of zynq/zynqmp based dts files in the
> kernel and arm-soc guys will stop this that it is simply too much and
> won't accept +1 case.

I share the same concerns. Unfortunately, there doesn't seem like any
other structured way to manage dts files.

As an OpenEmbedded guy, I know I can carry them with BSP's, but not
everyone uses OpenEmbedded. I'd love to see a long term scalable
solution for tracking dts files, but that is outside the scope of
Moritz's request.

Philip

> 
> Thanks,
> Michal
> 

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 09/26/2017 02:06 PM, Michal Simek wrote:
> On 26.9.2017 19:58, Philip Balister wrote:
>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>> Michal,
>>>
>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>> Hi Moritz
>>>>>>
>>>>>> sorry for delay.
>>>>>
>>>>> No problem.
>>>>>
>>>>>>
>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>
>>>>>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>
>>>>>> Is this publicly available board?
>>>>>
>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>> system.
>>>>>
>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>
>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>
>>>> For me this is not a problem because on Linux side it is not increasing
>>>> build time.
>>>> I want to see the value for community. All xilinx platforms are
>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>> together.
>>>> On the other hand this is real product.
>>>
>>> Uh.
>>>
>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>> definitely don't want to end up in situation that we will have dts for
>>>> real products which are not bringing any value for others.
>>>
>>> Sure, it's the maintainers call.
>>>
>>> I do intend to have my customers run mainline on it eventually, currently
>>> I'm a handful of patches away from making that happen. So yes, running
>>> mainline is a usecase that matters to me.
>>>
>>> It is one thing to keep bitching about vendor kernels as a community
>>> continuously, but then if someone goes through the effort and actually
>>> tries to run mainline, you give them crap like that above.
>>>
>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>> available, I don't know what makes them less useful to the community as a
>>> platform to experiment and develop on than Xilinx eval boards.
>>>
>>> There's several people that I know of both hobbyists and companies that
>>> build systems around these platforms, so I don't know ...
>>
>> I expect this product to be delivered with full source and a mainline
>> kernel, so lets make it easy for Moritz to do the right thing here. This
>> makes long term support of this product much easier.
>>
>> Acked-by: Philip Balister <philip-7I+KllWURj5BDgjK7y7TUQ@public.gmane.org>
> 
> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> and I will merge this.
> I am simply just afraid that if a lot of zynq customers will ask for it
> we can will end up with a lot of zynq/zynqmp based dts files in the
> kernel and arm-soc guys will stop this that it is simply too much and
> won't accept +1 case.

I share the same concerns. Unfortunately, there doesn't seem like any
other structured way to manage dts files.

As an OpenEmbedded guy, I know I can carry them with BSP's, but not
everyone uses OpenEmbedded. I'd love to see a long term scalable
solution for tracking dts files, but that is outside the scope of
Moritz's request.

Philip

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

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 09/26/2017 02:06 PM, Michal Simek wrote:
> On 26.9.2017 19:58, Philip Balister wrote:
>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>> Michal,
>>>
>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>> Hi,
>>>>
>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>> Hi Moritz
>>>>>>
>>>>>> sorry for delay.
>>>>>
>>>>> No problem.
>>>>>
>>>>>>
>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>
>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>
>>>>>> Is this publicly available board?
>>>>>
>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>> system.
>>>>>
>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>
>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>
>>>> For me this is not a problem because on Linux side it is not increasing
>>>> build time.
>>>> I want to see the value for community. All xilinx platforms are
>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>> together.
>>>> On the other hand this is real product.
>>>
>>> Uh.
>>>
>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>> definitely don't want to end up in situation that we will have dts for
>>>> real products which are not bringing any value for others.
>>>
>>> Sure, it's the maintainers call.
>>>
>>> I do intend to have my customers run mainline on it eventually, currently
>>> I'm a handful of patches away from making that happen. So yes, running
>>> mainline is a usecase that matters to me.
>>>
>>> It is one thing to keep bitching about vendor kernels as a community
>>> continuously, but then if someone goes through the effort and actually
>>> tries to run mainline, you give them crap like that above.
>>>
>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>> available, I don't know what makes them less useful to the community as a
>>> platform to experiment and develop on than Xilinx eval boards.
>>>
>>> There's several people that I know of both hobbyists and companies that
>>> build systems around these platforms, so I don't know ...
>>
>> I expect this product to be delivered with full source and a mainline
>> kernel, so lets make it easy for Moritz to do the right thing here. This
>> makes long term support of this product much easier.
>>
>> Acked-by: Philip Balister <philip@opensdr.com>
> 
> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> and I will merge this.
> I am simply just afraid that if a lot of zynq customers will ask for it
> we can will end up with a lot of zynq/zynqmp based dts files in the
> kernel and arm-soc guys will stop this that it is simply too much and
> won't accept +1 case.

I share the same concerns. Unfortunately, there doesn't seem like any
other structured way to manage dts files.

As an OpenEmbedded guy, I know I can carry them with BSP's, but not
everyone uses OpenEmbedded. I'd love to see a long term scalable
solution for tracking dts files, but that is outside the scope of
Moritz's request.

Philip

> 
> Thanks,
> Michal
> 

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 20:15, Philip Balister wrote:
> On 09/26/2017 02:06 PM, Michal Simek wrote:
>> On 26.9.2017 19:58, Philip Balister wrote:
>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>> Michal,
>>>>
>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>> Hi Michal,
>>>>>>
>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>> Hi Moritz
>>>>>>>
>>>>>>> sorry for delay.
>>>>>>
>>>>>> No problem.
>>>>>>
>>>>>>>
>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>
>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>> ---
>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>
>>>>>>> Is this publicly available board?
>>>>>>
>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>> system.
>>>>>>
>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>
>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>
>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>> build time.
>>>>> I want to see the value for community. All xilinx platforms are
>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>> together.
>>>>> On the other hand this is real product.
>>>>
>>>> Uh.
>>>>
>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>> definitely don't want to end up in situation that we will have dts for
>>>>> real products which are not bringing any value for others.
>>>>
>>>> Sure, it's the maintainers call.
>>>>
>>>> I do intend to have my customers run mainline on it eventually, currently
>>>> I'm a handful of patches away from making that happen. So yes, running
>>>> mainline is a usecase that matters to me.
>>>>
>>>> It is one thing to keep bitching about vendor kernels as a community
>>>> continuously, but then if someone goes through the effort and actually
>>>> tries to run mainline, you give them crap like that above.
>>>>
>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>> available, I don't know what makes them less useful to the community as a
>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>
>>>> There's several people that I know of both hobbyists and companies that
>>>> build systems around these platforms, so I don't know ...
>>>
>>> I expect this product to be delivered with full source and a mainline
>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>> makes long term support of this product much easier.
>>>
>>> Acked-by: Philip Balister <philip@opensdr.com>
>>
>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>> and I will merge this.
>> I am simply just afraid that if a lot of zynq customers will ask for it
>> we can will end up with a lot of zynq/zynqmp based dts files in the
>> kernel and arm-soc guys will stop this that it is simply too much and
>> won't accept +1 case.
> 
> I share the same concerns. Unfortunately, there doesn't seem like any
> other structured way to manage dts files.
> 
> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> everyone uses OpenEmbedded. I'd love to see a long term scalable
> solution for tracking dts files, but that is outside the scope of
> Moritz's request.

Are you guys coming to ELCE? There will be Devicetree Workshop which
will be good place to talk about this.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 20:15, Philip Balister wrote:
> On 09/26/2017 02:06 PM, Michal Simek wrote:
>> On 26.9.2017 19:58, Philip Balister wrote:
>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>> Michal,
>>>>
>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>> Hi Michal,
>>>>>>
>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>> Hi Moritz
>>>>>>>
>>>>>>> sorry for delay.
>>>>>>
>>>>>> No problem.
>>>>>>
>>>>>>>
>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>
>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>> ---
>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>
>>>>>>> Is this publicly available board?
>>>>>>
>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>> system.
>>>>>>
>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>
>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>
>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>> build time.
>>>>> I want to see the value for community. All xilinx platforms are
>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>> together.
>>>>> On the other hand this is real product.
>>>>
>>>> Uh.
>>>>
>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>> definitely don't want to end up in situation that we will have dts for
>>>>> real products which are not bringing any value for others.
>>>>
>>>> Sure, it's the maintainers call.
>>>>
>>>> I do intend to have my customers run mainline on it eventually, currently
>>>> I'm a handful of patches away from making that happen. So yes, running
>>>> mainline is a usecase that matters to me.
>>>>
>>>> It is one thing to keep bitching about vendor kernels as a community
>>>> continuously, but then if someone goes through the effort and actually
>>>> tries to run mainline, you give them crap like that above.
>>>>
>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>> available, I don't know what makes them less useful to the community as a
>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>
>>>> There's several people that I know of both hobbyists and companies that
>>>> build systems around these platforms, so I don't know ...
>>>
>>> I expect this product to be delivered with full source and a mainline
>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>> makes long term support of this product much easier.
>>>
>>> Acked-by: Philip Balister <philip@opensdr.com>
>>
>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>> and I will merge this.
>> I am simply just afraid that if a lot of zynq customers will ask for it
>> we can will end up with a lot of zynq/zynqmp based dts files in the
>> kernel and arm-soc guys will stop this that it is simply too much and
>> won't accept +1 case.
> 
> I share the same concerns. Unfortunately, there doesn't seem like any
> other structured way to manage dts files.
> 
> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> everyone uses OpenEmbedded. I'd love to see a long term scalable
> solution for tracking dts files, but that is outside the scope of
> Moritz's request.

Are you guys coming to ELCE? There will be Devicetree Workshop which
will be good place to talk about this.

Thanks,
Michal

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 26.9.2017 20:15, Philip Balister wrote:
> On 09/26/2017 02:06 PM, Michal Simek wrote:
>> On 26.9.2017 19:58, Philip Balister wrote:
>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>> Michal,
>>>>
>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>> Hi Michal,
>>>>>>
>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>> Hi Moritz
>>>>>>>
>>>>>>> sorry for delay.
>>>>>>
>>>>>> No problem.
>>>>>>
>>>>>>>
>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>
>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>> ---
>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>
>>>>>>> Is this publicly available board?
>>>>>>
>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>> system.
>>>>>>
>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>
>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>
>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>> build time.
>>>>> I want to see the value for community. All xilinx platforms are
>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>> together.
>>>>> On the other hand this is real product.
>>>>
>>>> Uh.
>>>>
>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>> definitely don't want to end up in situation that we will have dts for
>>>>> real products which are not bringing any value for others.
>>>>
>>>> Sure, it's the maintainers call.
>>>>
>>>> I do intend to have my customers run mainline on it eventually, currently
>>>> I'm a handful of patches away from making that happen. So yes, running
>>>> mainline is a usecase that matters to me.
>>>>
>>>> It is one thing to keep bitching about vendor kernels as a community
>>>> continuously, but then if someone goes through the effort and actually
>>>> tries to run mainline, you give them crap like that above.
>>>>
>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>> available, I don't know what makes them less useful to the community as a
>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>
>>>> There's several people that I know of both hobbyists and companies that
>>>> build systems around these platforms, so I don't know ...
>>>
>>> I expect this product to be delivered with full source and a mainline
>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>> makes long term support of this product much easier.
>>>
>>> Acked-by: Philip Balister <philip@opensdr.com>
>>
>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>> and I will merge this.
>> I am simply just afraid that if a lot of zynq customers will ask for it
>> we can will end up with a lot of zynq/zynqmp based dts files in the
>> kernel and arm-soc guys will stop this that it is simply too much and
>> won't accept +1 case.
> 
> I share the same concerns. Unfortunately, there doesn't seem like any
> other structured way to manage dts files.
> 
> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> everyone uses OpenEmbedded. I'd love to see a long term scalable
> solution for tracking dts files, but that is outside the scope of
> Moritz's request.

Are you guys coming to ELCE? There will be Devicetree Workshop which
will be good place to talk about this.

Thanks,
Michal

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 10/06/2017 04:49 AM, Michal Simek wrote:
> On 26.9.2017 20:15, Philip Balister wrote:
>> On 09/26/2017 02:06 PM, Michal Simek wrote:
>>> On 26.9.2017 19:58, Philip Balister wrote:
>>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>>> Michal,
>>>>>
>>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>>> Hi Moritz
>>>>>>>>
>>>>>>>> sorry for delay.
>>>>>>>
>>>>>>> No problem.
>>>>>>>
>>>>>>>>
>>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>> ---
>>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>>
>>>>>>>> Is this publicly available board?
>>>>>>>
>>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>>> system.
>>>>>>>
>>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>>
>>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>>
>>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>>> build time.
>>>>>> I want to see the value for community. All xilinx platforms are
>>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>>> together.
>>>>>> On the other hand this is real product.
>>>>>
>>>>> Uh.
>>>>>
>>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>>> definitely don't want to end up in situation that we will have dts for
>>>>>> real products which are not bringing any value for others.
>>>>>
>>>>> Sure, it's the maintainers call.
>>>>>
>>>>> I do intend to have my customers run mainline on it eventually, currently
>>>>> I'm a handful of patches away from making that happen. So yes, running
>>>>> mainline is a usecase that matters to me.
>>>>>
>>>>> It is one thing to keep bitching about vendor kernels as a community
>>>>> continuously, but then if someone goes through the effort and actually
>>>>> tries to run mainline, you give them crap like that above.
>>>>>
>>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>>> available, I don't know what makes them less useful to the community as a
>>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>>
>>>>> There's several people that I know of both hobbyists and companies that
>>>>> build systems around these platforms, so I don't know ...
>>>>
>>>> I expect this product to be delivered with full source and a mainline
>>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>>> makes long term support of this product much easier.
>>>>
>>>> Acked-by: Philip Balister <philip@opensdr.com>
>>>
>>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>>> and I will merge this.
>>> I am simply just afraid that if a lot of zynq customers will ask for it
>>> we can will end up with a lot of zynq/zynqmp based dts files in the
>>> kernel and arm-soc guys will stop this that it is simply too much and
>>> won't accept +1 case.
>>
>> I share the same concerns. Unfortunately, there doesn't seem like any
>> other structured way to manage dts files.
>>
>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
>> everyone uses OpenEmbedded. I'd love to see a long term scalable
>> solution for tracking dts files, but that is outside the scope of
>> Moritz's request.
> 
> Are you guys coming to ELCE? There will be Devicetree Workshop which
> will be good place to talk about this.

Yes. When is the workshop?

Philip

> 
> Thanks,
> Michal
> 

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Philip Balister]

On 10/06/2017 04:49 AM, Michal Simek wrote:
> On 26.9.2017 20:15, Philip Balister wrote:
>> On 09/26/2017 02:06 PM, Michal Simek wrote:
>>> On 26.9.2017 19:58, Philip Balister wrote:
>>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>>> Michal,
>>>>>
>>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>>> Hi Moritz
>>>>>>>>
>>>>>>>> sorry for delay.
>>>>>>>
>>>>>>> No problem.
>>>>>>>
>>>>>>>>
>>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>> ---
>>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>>
>>>>>>>> Is this publicly available board?
>>>>>>>
>>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>>> system.
>>>>>>>
>>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>>
>>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>>
>>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>>> build time.
>>>>>> I want to see the value for community. All xilinx platforms are
>>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>>> together.
>>>>>> On the other hand this is real product.
>>>>>
>>>>> Uh.
>>>>>
>>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>>> definitely don't want to end up in situation that we will have dts for
>>>>>> real products which are not bringing any value for others.
>>>>>
>>>>> Sure, it's the maintainers call.
>>>>>
>>>>> I do intend to have my customers run mainline on it eventually, currently
>>>>> I'm a handful of patches away from making that happen. So yes, running
>>>>> mainline is a usecase that matters to me.
>>>>>
>>>>> It is one thing to keep bitching about vendor kernels as a community
>>>>> continuously, but then if someone goes through the effort and actually
>>>>> tries to run mainline, you give them crap like that above.
>>>>>
>>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>>> available, I don't know what makes them less useful to the community as a
>>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>>
>>>>> There's several people that I know of both hobbyists and companies that
>>>>> build systems around these platforms, so I don't know ...
>>>>
>>>> I expect this product to be delivered with full source and a mainline
>>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>>> makes long term support of this product much easier.
>>>>
>>>> Acked-by: Philip Balister <philip@opensdr.com>
>>>
>>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>>> and I will merge this.
>>> I am simply just afraid that if a lot of zynq customers will ask for it
>>> we can will end up with a lot of zynq/zynqmp based dts files in the
>>> kernel and arm-soc guys will stop this that it is simply too much and
>>> won't accept +1 case.
>>
>> I share the same concerns. Unfortunately, there doesn't seem like any
>> other structured way to manage dts files.
>>
>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
>> everyone uses OpenEmbedded. I'd love to see a long term scalable
>> solution for tracking dts files, but that is outside the scope of
>> Moritz's request.
> 
> Are you guys coming to ELCE? There will be Devicetree Workshop which
> will be good place to talk about this.

Yes. When is the workshop?

Philip

> 
> Thanks,
> Michal
> 

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

[-- Attachment #1: Type: text/plain, Size: 4861 bytes --]

On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
> On 26.9.2017 20:15, Philip Balister wrote:
> > On 09/26/2017 02:06 PM, Michal Simek wrote:
> >> On 26.9.2017 19:58, Philip Balister wrote:
> >>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> >>>> Michal,
> >>>>
> >>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
> >>>>>> Hi Michal,
> >>>>>>
> >>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >>>>>>> Hi Moritz
> >>>>>>>
> >>>>>>> sorry for delay.
> >>>>>>
> >>>>>> No problem.
> >>>>>>
> >>>>>>>
> >>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>>>>>>> Add support for the National Instruments Project Sulfur SDR
> >>>>>>>> motherboards Rev 2,3 and 4.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> >>>>>>>> ---
> >>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>>>>>>  5 files changed, 364 insertions(+)
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>>>>>>
> >>>>>>> Is this publicly available board?
> >>>>>>
> >>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> >>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
> >>>>>> system.
> >>>>>>
> >>>>>>> I am not quite sure we should apply these dts files. There are a lot of
> >>>>>>> boards with zynq and there must be any strong argument for applying this
> >>>>>>> to the tree. For arm32 with even flat tree structure.
> >>>>>>
> >>>>>> What's the issue with merging them, except for having 3 more files? 
> >>>>>
> >>>>> For me this is not a problem because on Linux side it is not increasing
> >>>>> build time.
> >>>>> I want to see the value for community. All xilinx platforms are
> >>>>> evaluation generic purpose boards which are showing how to connect stuff
> >>>>> together.
> >>>>> On the other hand this is real product.
> >>>>
> >>>> Uh.
> >>>>
> >>>>> I would let arm-soc maintainer to decide if this is fine or not. I
> >>>>> definitely don't want to end up in situation that we will have dts for
> >>>>> real products which are not bringing any value for others.
> >>>>
> >>>> Sure, it's the maintainers call.
> >>>>
> >>>> I do intend to have my customers run mainline on it eventually, currently
> >>>> I'm a handful of patches away from making that happen. So yes, running
> >>>> mainline is a usecase that matters to me.
> >>>>
> >>>> It is one thing to keep bitching about vendor kernels as a community
> >>>> continuously, but then if someone goes through the effort and actually
> >>>> tries to run mainline, you give them crap like that above.
> >>>>
> >>>> Our products usually come with full schematics [1], firmware, fpga code and all
> >>>> available, I don't know what makes them less useful to the community as a
> >>>> platform to experiment and develop on than Xilinx eval boards.
> >>>>
> >>>> There's several people that I know of both hobbyists and companies that
> >>>> build systems around these platforms, so I don't know ...
> >>>
> >>> I expect this product to be delivered with full source and a mainline
> >>> kernel, so lets make it easy for Moritz to do the right thing here. This
> >>> makes long term support of this product much easier.
> >>>
> >>> Acked-by: Philip Balister <philip@opensdr.com>
> >>
> >> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> >> and I will merge this.
> >> I am simply just afraid that if a lot of zynq customers will ask for it
> >> we can will end up with a lot of zynq/zynqmp based dts files in the
> >> kernel and arm-soc guys will stop this that it is simply too much and
> >> won't accept +1 case.
> > 
> > I share the same concerns. Unfortunately, there doesn't seem like any
> > other structured way to manage dts files.
> > 
> > As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> > everyone uses OpenEmbedded. I'd love to see a long term scalable
> > solution for tracking dts files, but that is outside the scope of
> > Moritz's request.
> 
> Are you guys coming to ELCE? There will be Devicetree Workshop which
> will be good place to talk about this.

Yeah, it's on Thursday, right?

- Moritz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

[-- Attachment #1: Type: text/plain, Size: 4918 bytes --]

On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
> On 26.9.2017 20:15, Philip Balister wrote:
> > On 09/26/2017 02:06 PM, Michal Simek wrote:
> >> On 26.9.2017 19:58, Philip Balister wrote:
> >>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> >>>> Michal,
> >>>>
> >>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
> >>>>>> Hi Michal,
> >>>>>>
> >>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >>>>>>> Hi Moritz
> >>>>>>>
> >>>>>>> sorry for delay.
> >>>>>>
> >>>>>> No problem.
> >>>>>>
> >>>>>>>
> >>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>>>>>>> Add support for the National Instruments Project Sulfur SDR
> >>>>>>>> motherboards Rev 2,3 and 4.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>>>>> ---
> >>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>>>>>>  5 files changed, 364 insertions(+)
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>>>>>>
> >>>>>>> Is this publicly available board?
> >>>>>>
> >>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> >>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
> >>>>>> system.
> >>>>>>
> >>>>>>> I am not quite sure we should apply these dts files. There are a lot of
> >>>>>>> boards with zynq and there must be any strong argument for applying this
> >>>>>>> to the tree. For arm32 with even flat tree structure.
> >>>>>>
> >>>>>> What's the issue with merging them, except for having 3 more files? 
> >>>>>
> >>>>> For me this is not a problem because on Linux side it is not increasing
> >>>>> build time.
> >>>>> I want to see the value for community. All xilinx platforms are
> >>>>> evaluation generic purpose boards which are showing how to connect stuff
> >>>>> together.
> >>>>> On the other hand this is real product.
> >>>>
> >>>> Uh.
> >>>>
> >>>>> I would let arm-soc maintainer to decide if this is fine or not. I
> >>>>> definitely don't want to end up in situation that we will have dts for
> >>>>> real products which are not bringing any value for others.
> >>>>
> >>>> Sure, it's the maintainers call.
> >>>>
> >>>> I do intend to have my customers run mainline on it eventually, currently
> >>>> I'm a handful of patches away from making that happen. So yes, running
> >>>> mainline is a usecase that matters to me.
> >>>>
> >>>> It is one thing to keep bitching about vendor kernels as a community
> >>>> continuously, but then if someone goes through the effort and actually
> >>>> tries to run mainline, you give them crap like that above.
> >>>>
> >>>> Our products usually come with full schematics [1], firmware, fpga code and all
> >>>> available, I don't know what makes them less useful to the community as a
> >>>> platform to experiment and develop on than Xilinx eval boards.
> >>>>
> >>>> There's several people that I know of both hobbyists and companies that
> >>>> build systems around these platforms, so I don't know ...
> >>>
> >>> I expect this product to be delivered with full source and a mainline
> >>> kernel, so lets make it easy for Moritz to do the right thing here. This
> >>> makes long term support of this product much easier.
> >>>
> >>> Acked-by: Philip Balister <philip-7I+KllWURj5BDgjK7y7TUQ@public.gmane.org>
> >>
> >> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> >> and I will merge this.
> >> I am simply just afraid that if a lot of zynq customers will ask for it
> >> we can will end up with a lot of zynq/zynqmp based dts files in the
> >> kernel and arm-soc guys will stop this that it is simply too much and
> >> won't accept +1 case.
> > 
> > I share the same concerns. Unfortunately, there doesn't seem like any
> > other structured way to manage dts files.
> > 
> > As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> > everyone uses OpenEmbedded. I'd love to see a long term scalable
> > solution for tracking dts files, but that is outside the scope of
> > Moritz's request.
> 
> Are you guys coming to ELCE? There will be Devicetree Workshop which
> will be good place to talk about this.

Yeah, it's on Thursday, right?

- Moritz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Moritz Fischer]

On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
> On 26.9.2017 20:15, Philip Balister wrote:
> > On 09/26/2017 02:06 PM, Michal Simek wrote:
> >> On 26.9.2017 19:58, Philip Balister wrote:
> >>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
> >>>> Michal,
> >>>>
> >>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
> >>>>>> Hi Michal,
> >>>>>>
> >>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
> >>>>>>> Hi Moritz
> >>>>>>>
> >>>>>>> sorry for delay.
> >>>>>>
> >>>>>> No problem.
> >>>>>>
> >>>>>>>
> >>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
> >>>>>>>> Add support for the National Instruments Project Sulfur SDR
> >>>>>>>> motherboards Rev 2,3 and 4.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> >>>>>>>> ---
> >>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
> >>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
> >>>>>>>>  5 files changed, 364 insertions(+)
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
> >>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
> >>>>>>>
> >>>>>>> Is this publicly available board?
> >>>>>>
> >>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
> >>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
> >>>>>> system.
> >>>>>>
> >>>>>>> I am not quite sure we should apply these dts files. There are a lot of
> >>>>>>> boards with zynq and there must be any strong argument for applying this
> >>>>>>> to the tree. For arm32 with even flat tree structure.
> >>>>>>
> >>>>>> What's the issue with merging them, except for having 3 more files? 
> >>>>>
> >>>>> For me this is not a problem because on Linux side it is not increasing
> >>>>> build time.
> >>>>> I want to see the value for community. All xilinx platforms are
> >>>>> evaluation generic purpose boards which are showing how to connect stuff
> >>>>> together.
> >>>>> On the other hand this is real product.
> >>>>
> >>>> Uh.
> >>>>
> >>>>> I would let arm-soc maintainer to decide if this is fine or not. I
> >>>>> definitely don't want to end up in situation that we will have dts for
> >>>>> real products which are not bringing any value for others.
> >>>>
> >>>> Sure, it's the maintainers call.
> >>>>
> >>>> I do intend to have my customers run mainline on it eventually, currently
> >>>> I'm a handful of patches away from making that happen. So yes, running
> >>>> mainline is a usecase that matters to me.
> >>>>
> >>>> It is one thing to keep bitching about vendor kernels as a community
> >>>> continuously, but then if someone goes through the effort and actually
> >>>> tries to run mainline, you give them crap like that above.
> >>>>
> >>>> Our products usually come with full schematics [1], firmware, fpga code and all
> >>>> available, I don't know what makes them less useful to the community as a
> >>>> platform to experiment and develop on than Xilinx eval boards.
> >>>>
> >>>> There's several people that I know of both hobbyists and companies that
> >>>> build systems around these platforms, so I don't know ...
> >>>
> >>> I expect this product to be delivered with full source and a mainline
> >>> kernel, so lets make it easy for Moritz to do the right thing here. This
> >>> makes long term support of this product much easier.
> >>>
> >>> Acked-by: Philip Balister <philip@opensdr.com>
> >>
> >> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
> >> and I will merge this.
> >> I am simply just afraid that if a lot of zynq customers will ask for it
> >> we can will end up with a lot of zynq/zynqmp based dts files in the
> >> kernel and arm-soc guys will stop this that it is simply too much and
> >> won't accept +1 case.
> > 
> > I share the same concerns. Unfortunately, there doesn't seem like any
> > other structured way to manage dts files.
> > 
> > As an OpenEmbedded guy, I know I can carry them with BSP's, but not
> > everyone uses OpenEmbedded. I'd love to see a long term scalable
> > solution for tracking dts files, but that is outside the scope of
> > Moritz's request.
> 
> Are you guys coming to ELCE? There will be Devicetree Workshop which
> will be good place to talk about this.

Yeah, it's on Thursday, right?

- Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171006/78e4bc92/attachment.sig>

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 6.10.2017 18:18, Moritz Fischer wrote:
> On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
>> On 26.9.2017 20:15, Philip Balister wrote:
>>> On 09/26/2017 02:06 PM, Michal Simek wrote:
>>>> On 26.9.2017 19:58, Philip Balister wrote:
>>>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>>>> Michal,
>>>>>>
>>>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>>>> Hi Michal,
>>>>>>>>
>>>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>>>> Hi Moritz
>>>>>>>>>
>>>>>>>>> sorry for delay.
>>>>>>>>
>>>>>>>> No problem.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>>>
>>>>>>>>> Is this publicly available board?
>>>>>>>>
>>>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>>>> system.
>>>>>>>>
>>>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>>>
>>>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>>>
>>>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>>>> build time.
>>>>>>> I want to see the value for community. All xilinx platforms are
>>>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>>>> together.
>>>>>>> On the other hand this is real product.
>>>>>>
>>>>>> Uh.
>>>>>>
>>>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>>>> definitely don't want to end up in situation that we will have dts for
>>>>>>> real products which are not bringing any value for others.
>>>>>>
>>>>>> Sure, it's the maintainers call.
>>>>>>
>>>>>> I do intend to have my customers run mainline on it eventually, currently
>>>>>> I'm a handful of patches away from making that happen. So yes, running
>>>>>> mainline is a usecase that matters to me.
>>>>>>
>>>>>> It is one thing to keep bitching about vendor kernels as a community
>>>>>> continuously, but then if someone goes through the effort and actually
>>>>>> tries to run mainline, you give them crap like that above.
>>>>>>
>>>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>>>> available, I don't know what makes them less useful to the community as a
>>>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>>>
>>>>>> There's several people that I know of both hobbyists and companies that
>>>>>> build systems around these platforms, so I don't know ...
>>>>>
>>>>> I expect this product to be delivered with full source and a mainline
>>>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>>>> makes long term support of this product much easier.
>>>>>
>>>>> Acked-by: Philip Balister <philip@opensdr.com>
>>>>
>>>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>>>> and I will merge this.
>>>> I am simply just afraid that if a lot of zynq customers will ask for it
>>>> we can will end up with a lot of zynq/zynqmp based dts files in the
>>>> kernel and arm-soc guys will stop this that it is simply too much and
>>>> won't accept +1 case.
>>>
>>> I share the same concerns. Unfortunately, there doesn't seem like any
>>> other structured way to manage dts files.
>>>
>>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
>>> everyone uses OpenEmbedded. I'd love to see a long term scalable
>>> solution for tracking dts files, but that is outside the scope of
>>> Moritz's request.
>>
>> Are you guys coming to ELCE? There will be Devicetree Workshop which
>> will be good place to talk about this.
> 
> Yeah, it's on Thursday, right?

Yep Thursday but no exact time yet.

M

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 6.10.2017 18:18, Moritz Fischer wrote:
> On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
>> On 26.9.2017 20:15, Philip Balister wrote:
>>> On 09/26/2017 02:06 PM, Michal Simek wrote:
>>>> On 26.9.2017 19:58, Philip Balister wrote:
>>>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>>>> Michal,
>>>>>>
>>>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>>>> Hi Michal,
>>>>>>>>
>>>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>>>> Hi Moritz
>>>>>>>>>
>>>>>>>>> sorry for delay.
>>>>>>>>
>>>>>>>> No problem.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>>>
>>>>>>>>> Is this publicly available board?
>>>>>>>>
>>>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>>>> system.
>>>>>>>>
>>>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>>>
>>>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>>>
>>>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>>>> build time.
>>>>>>> I want to see the value for community. All xilinx platforms are
>>>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>>>> together.
>>>>>>> On the other hand this is real product.
>>>>>>
>>>>>> Uh.
>>>>>>
>>>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>>>> definitely don't want to end up in situation that we will have dts for
>>>>>>> real products which are not bringing any value for others.
>>>>>>
>>>>>> Sure, it's the maintainers call.
>>>>>>
>>>>>> I do intend to have my customers run mainline on it eventually, currently
>>>>>> I'm a handful of patches away from making that happen. So yes, running
>>>>>> mainline is a usecase that matters to me.
>>>>>>
>>>>>> It is one thing to keep bitching about vendor kernels as a community
>>>>>> continuously, but then if someone goes through the effort and actually
>>>>>> tries to run mainline, you give them crap like that above.
>>>>>>
>>>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>>>> available, I don't know what makes them less useful to the community as a
>>>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>>>
>>>>>> There's several people that I know of both hobbyists and companies that
>>>>>> build systems around these platforms, so I don't know ...
>>>>>
>>>>> I expect this product to be delivered with full source and a mainline
>>>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>>>> makes long term support of this product much easier.
>>>>>
>>>>> Acked-by: Philip Balister <philip@opensdr.com>
>>>>
>>>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>>>> and I will merge this.
>>>> I am simply just afraid that if a lot of zynq customers will ask for it
>>>> we can will end up with a lot of zynq/zynqmp based dts files in the
>>>> kernel and arm-soc guys will stop this that it is simply too much and
>>>> won't accept +1 case.
>>>
>>> I share the same concerns. Unfortunately, there doesn't seem like any
>>> other structured way to manage dts files.
>>>
>>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
>>> everyone uses OpenEmbedded. I'd love to see a long term scalable
>>> solution for tracking dts files, but that is outside the scope of
>>> Moritz's request.
>>
>> Are you guys coming to ELCE? There will be Devicetree Workshop which
>> will be good place to talk about this.
> 
> Yeah, it's on Thursday, right?

Yep Thursday but no exact time yet.

M

[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

On 6.10.2017 18:18, Moritz Fischer wrote:
> On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote:
>> On 26.9.2017 20:15, Philip Balister wrote:
>>> On 09/26/2017 02:06 PM, Michal Simek wrote:
>>>> On 26.9.2017 19:58, Philip Balister wrote:
>>>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote:
>>>>>> Michal,
>>>>>>
>>>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 25.9.2017 18:11, Moritz Fischer wrote:
>>>>>>>> Hi Michal,
>>>>>>>>
>>>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote:
>>>>>>>>> Hi Moritz
>>>>>>>>>
>>>>>>>>> sorry for delay.
>>>>>>>>
>>>>>>>> No problem.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote:
>>>>>>>>>> Add support for the National Instruments Project Sulfur SDR
>>>>>>>>>> motherboards Rev 2,3 and 4.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/boot/dts/Makefile                |   3 +
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++++++++++++++++++++++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++++++
>>>>>>>>>>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi     | 133 ++++++++++++++++++++++++++++++
>>>>>>>>>>  5 files changed, 364 insertions(+)
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>>>>>>>>>>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi
>>>>>>>>>
>>>>>>>>> Is this publicly available board?
>>>>>>>>
>>>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]).
>>>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar
>>>>>>>> system.
>>>>>>>>
>>>>>>>>> I am not quite sure we should apply these dts files. There are a lot of
>>>>>>>>> boards with zynq and there must be any strong argument for applying this
>>>>>>>>> to the tree. For arm32 with even flat tree structure.
>>>>>>>>
>>>>>>>> What's the issue with merging them, except for having 3 more files? 
>>>>>>>
>>>>>>> For me this is not a problem because on Linux side it is not increasing
>>>>>>> build time.
>>>>>>> I want to see the value for community. All xilinx platforms are
>>>>>>> evaluation generic purpose boards which are showing how to connect stuff
>>>>>>> together.
>>>>>>> On the other hand this is real product.
>>>>>>
>>>>>> Uh.
>>>>>>
>>>>>>> I would let arm-soc maintainer to decide if this is fine or not. I
>>>>>>> definitely don't want to end up in situation that we will have dts for
>>>>>>> real products which are not bringing any value for others.
>>>>>>
>>>>>> Sure, it's the maintainers call.
>>>>>>
>>>>>> I do intend to have my customers run mainline on it eventually, currently
>>>>>> I'm a handful of patches away from making that happen. So yes, running
>>>>>> mainline is a usecase that matters to me.
>>>>>>
>>>>>> It is one thing to keep bitching about vendor kernels as a community
>>>>>> continuously, but then if someone goes through the effort and actually
>>>>>> tries to run mainline, you give them crap like that above.
>>>>>>
>>>>>> Our products usually come with full schematics [1], firmware, fpga code and all
>>>>>> available, I don't know what makes them less useful to the community as a
>>>>>> platform to experiment and develop on than Xilinx eval boards.
>>>>>>
>>>>>> There's several people that I know of both hobbyists and companies that
>>>>>> build systems around these platforms, so I don't know ...
>>>>>
>>>>> I expect this product to be delivered with full source and a mainline
>>>>> kernel, so lets make it easy for Moritz to do the right thing here. This
>>>>> makes long term support of this product much easier.
>>>>>
>>>>> Acked-by: Philip Balister <philip@opensdr.com>
>>>>
>>>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin
>>>> and I will merge this.
>>>> I am simply just afraid that if a lot of zynq customers will ask for it
>>>> we can will end up with a lot of zynq/zynqmp based dts files in the
>>>> kernel and arm-soc guys will stop this that it is simply too much and
>>>> won't accept +1 case.
>>>
>>> I share the same concerns. Unfortunately, there doesn't seem like any
>>> other structured way to manage dts files.
>>>
>>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not
>>> everyone uses OpenEmbedded. I'd love to see a long term scalable
>>> solution for tracking dts files, but that is outside the scope of
>>> Moritz's request.
>>
>> Are you guys coming to ELCE? There will be Devicetree Workshop which
>> will be good place to talk about this.
> 
> Yeah, it's on Thursday, right?

Yep Thursday but no exact time yet.

M