Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1730581 > unrolled thread

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

Started byMoritz Fischer <mdf@kernel.org>
First post2017-09-12 01:30 +0200
Last post2017-09-26 20:20 +0200
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs Moritz Fischer <mdf@kernel.org> - 2017-09-12 01:30 +0200
    Re: [PATCH 1/2] arm: dts: Add support for National Instruments  Project Sulfur SDRs Moritz Fischer <mdf@kernel.org> - 2017-09-25 18:20 +0200
      Re: [PATCH 1/2] arm: dts: Add support for National Instruments  Project Sulfur SDRs Moritz Fischer <mdf@kernel.org> - 2017-09-26 19:50 +0200
        Re: [PATCH 1/2] arm: dts: Add support for National Instruments  Project Sulfur SDRs Philip Balister <philip@balister.org> - 2017-09-26 20:10 +0200
          Re: [PATCH 1/2] arm: dts: Add support for National Instruments  Project Sulfur SDRs Philip Balister <philip@balister.org> - 2017-09-26 20:20 +0200

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

FromMoritz Fischer <mdf@kernel.org>
Date2017-09-12 01:30 +0200
Subject[PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
Message-ID<uoGjo-1Cf-15@gated-at.bofh.it>
Add support for the National Instruments Project Sulfur SDR
motherboards Rev 2,3 and 4.

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

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

[toc] | [next] | [standalone]

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

FromMoritz Fischer <mdf@kernel.org>
Date2017-09-25 18:20 +0200
SubjectRe: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
Message-ID<utEgW-iV-11@gated-at.bofh.it>
In reply to#1730581

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

FromMoritz Fischer <mdf@kernel.org>
Date2017-09-26 19:50 +0200
SubjectRe: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
Message-ID<uu29z-7Oa-5@gated-at.bofh.it>
In reply to#1739147

[Multipart message — attachments visible in raw view] — view raw

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/

[toc] | [prev] | [next] | [standalone]

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

FromPhilip Balister <philip@balister.org>
Date2017-09-26 20:10 +0200
SubjectRe: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
Message-ID<uu2sX-8cl-51@gated-at.bofh.it>
In reply to#1740061

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

FromPhilip Balister <philip@balister.org>
Date2017-09-26 20:20 +0200
SubjectRe: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
Message-ID<uu2CC-8fI-13@gated-at.bofh.it>
In reply to#1740086
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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web