* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: devicetree Cc: linux-arm-kernel, robh+dt, mark.rutland, linux, michal.simek, gregkh, davem, linux-kernel, 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>; + }; + }; + }; +}; + +ðernet_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; + }; +}; + +ðernet_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 = <ðernet_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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: linux-arm-kernel 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>; + }; + }; + }; +}; + +ðernet_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; + }; +}; + +ðernet_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 = <ðernet_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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, michal.simek-gjFFaj9aHVfQT0dZR+AlfA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, 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>; + }; + }; + }; +}; + +ðernet_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; + }; +}; + +ðernet_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 = <ðernet_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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: devicetree Cc: linux-arm-kernel, robh+dt, mark.rutland, linux, michal.simek, gregkh, davem, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files @ 2017-09-11 23:22 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-11 23:22 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, michal.simek-gjFFaj9aHVfQT0dZR+AlfA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-25 8:19 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-25 8:19 UTC (permalink / raw) To: Moritz Fischer, devicetree Cc: linux-arm-kernel, robh+dt, mark.rutland, linux, michal.simek, gregkh, davem, linux-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-25 8:19 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-25 8:19 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-25 8:19 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-25 8:19 UTC (permalink / raw) To: Moritz Fischer, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, michal.simek-gjFFaj9aHVfQT0dZR+AlfA, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs 2017-09-25 8:19 ` Michal Simek @ 2017-09-25 16:11 ` Moritz Fischer -1 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-25 16:11 UTC (permalink / raw) To: Michal Simek Cc: Moritz Fischer, devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-25 16:11 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-25 16:11 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 12:54 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 12:54 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 12:54 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 12:54 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 12:54 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 12:54 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 17:50 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-26 17:50 UTC (permalink / raw) To: Michal Simek Cc: Moritz Fischer, devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann, philip [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 17:50 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-26 17:50 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 17:50 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-09-26 17:50 UTC (permalink / raw) To: Michal Simek Cc: Moritz Fischer, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, philip-6RQC9ztksjxg9hUCZPvPmw [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs 2017-09-26 17:50 ` Moritz Fischer (?) @ 2017-09-26 17:58 ` Philip Balister -1 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 17:58 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 17:58 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 17:58 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 17:58 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 17:58 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: mark.rutland, devicetree, Arnd Bergmann, gregkh, linux, linux-kernel, robh+dt, davem, linux-arm-kernel [-- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:06 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 18:06 UTC (permalink / raw) To: Philip Balister, Moritz Fischer, Michal Simek Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:06 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 18:06 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:06 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-09-26 18:06 UTC (permalink / raw) To: Philip Balister, Moritz Fischer, Michal Simek Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:15 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 18:15 UTC (permalink / raw) To: Michal Simek, Moritz Fischer Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:15 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 18:15 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-09-26 18:15 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-09-26 18:15 UTC (permalink / raw) To: Michal Simek, Moritz Fischer Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs 2017-09-26 18:15 ` Philip Balister (?) @ 2017-10-06 11:49 ` Michal Simek -1 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-06 11:49 UTC (permalink / raw) To: Philip Balister, Michal Simek, Moritz Fischer Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 11:49 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-06 11:49 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 11:49 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-06 11:49 UTC (permalink / raw) To: Philip Balister, Michal Simek, Moritz Fischer Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs 2017-10-06 11:49 ` Michal Simek @ 2017-10-06 14:58 ` Philip Balister -1 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-10-06 14:58 UTC (permalink / raw) To: Michal Simek, Moritz Fischer Cc: devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 14:58 ` Philip Balister 0 siblings, 0 replies; 37+ messages in thread From: Philip Balister @ 2017-10-06 14:58 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 16:18 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-10-06 16:18 UTC (permalink / raw) To: Michal Simek Cc: Philip Balister, Moritz Fischer, devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 16:18 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-10-06 16:18 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-06 16:18 ` Moritz Fischer 0 siblings, 0 replies; 37+ messages in thread From: Moritz Fischer @ 2017-10-06 16:18 UTC (permalink / raw) To: Michal Simek Cc: Philip Balister, Moritz Fischer, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann [-- 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 --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs 2017-10-06 16:18 ` Moritz Fischer (?) @ 2017-10-09 5:42 ` Michal Simek -1 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-09 5:42 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: Philip Balister, devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-09 5:42 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-09 5:42 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs @ 2017-10-09 5:42 ` Michal Simek 0 siblings, 0 replies; 37+ messages in thread From: Michal Simek @ 2017-10-09 5:42 UTC (permalink / raw) To: Moritz Fischer, Michal Simek Cc: Philip Balister, devicetree, linux-arm-kernel, robh+dt, mark.rutland, linux, gregkh, davem, linux-kernel, Arnd Bergmann 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2017-10-09 5:43 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-11 23:22 [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs Moritz Fischer 2017-09-11 23:22 ` Moritz Fischer 2017-09-11 23:22 ` Moritz Fischer 2017-09-11 23:22 ` [PATCH 2/2] MAINTAINERS: Add info for NI Project Sulfur DT files Moritz Fischer 2017-09-11 23:22 ` Moritz Fischer 2017-09-11 23:22 ` Moritz Fischer 2017-09-25 8:19 ` [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs Michal Simek 2017-09-25 8:19 ` Michal Simek 2017-09-25 8:19 ` Michal Simek 2017-09-25 16:11 ` Moritz Fischer 2017-09-25 16:11 ` Moritz Fischer 2017-09-26 12:54 ` Michal Simek 2017-09-26 12:54 ` Michal Simek 2017-09-26 12:54 ` Michal Simek 2017-09-26 17:50 ` Moritz Fischer 2017-09-26 17:50 ` Moritz Fischer 2017-09-26 17:50 ` Moritz Fischer 2017-09-26 17:58 ` Philip Balister 2017-09-26 17:58 ` Philip Balister 2017-09-26 17:58 ` Philip Balister 2017-09-26 18:06 ` Michal Simek 2017-09-26 18:06 ` Michal Simek 2017-09-26 18:06 ` Michal Simek 2017-09-26 18:15 ` Philip Balister 2017-09-26 18:15 ` Philip Balister 2017-09-26 18:15 ` Philip Balister 2017-10-06 11:49 ` Michal Simek 2017-10-06 11:49 ` Michal Simek 2017-10-06 11:49 ` Michal Simek 2017-10-06 14:58 ` Philip Balister 2017-10-06 14:58 ` Philip Balister 2017-10-06 16:18 ` Moritz Fischer 2017-10-06 16:18 ` Moritz Fischer 2017-10-06 16:18 ` Moritz Fischer 2017-10-09 5:42 ` Michal Simek 2017-10-09 5:42 ` Michal Simek 2017-10-09 5:42 ` Michal Simek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.