arm: dts: Add support for National Instruments Project Sulfur SDRs
Subsystems (3)
PATCH 1/2 arm: dts: Add support for National Instruments Project Sulfur SDRs
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
--- 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
arch/arm/boot/dts/Makefile +3 -0
@@ -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 \
arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts new file +84 -0
84 lines not on this page · raw message
arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts new file +118 -0
118 lines not on this page · raw message
arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts new file +26 -0
@@ -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>; + }; + }; +};
arch/arm/boot/dts/zynq-ni-sulfur.dtsi new file +133 -0
133 lines not on this page · raw message
Signature · 1 line
2.14.1
PATCH 2/2 MAINTAINERS: Add info for NI Project Sulfur DT files
Add contact info for National Instruments Project Sulfur SDR files.
--- MAINTAINERS | 7 +++++++ 1 file changed, 7 insertions(+)
MAINTAINERS +7 -0
@@ -1609,6 +1609,13 @@ ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT M: Michael Petchkovsky <[email protected]> S: Maintained +ARM/NATIONAL INSTRUMENTS PROJECT SULFUR SDR +M: Moritz Fischer <[email protected]> +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 <[email protected]> M: Linus Walleij <[email protected]>
Signature · 1 line
2.14.1
Hi Moritz
sorry for delay.
Quoted 4 lines · Moritz Fischer
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>
Quoted 11 lines
--- 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
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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
Quoted 1 line
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.
Quoted 3 lines
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?
Quoted 4 lines
Arnd: Do you have any policy about it?
Thanks,
Michal
Thanks,
Moritz
[1] https://drive.google.com/file/d/0B-CV_07uSBIuODc5bmV2QXhnODA/view
Hi,
Quoted 33 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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
Philip Balister
Acked-byQuoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Philip
Quoted 5 lines
- Moritz
-------------- 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>
Quoted 73 lines · Philip Balister
Quoted 72 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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 <[email protected]>
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
Quoted 81 lines · Michal Simek
Quoted 80 lines · Philip Balister
Quoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 1 line
Acked-by Philip Balister <[email protected]>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
Quoted 4 lines
Thanks,
Michal
Quoted 91 lines · Philip Balister
Quoted 81 lines · Michal Simek
Quoted 80 lines · Philip Balister
Quoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 1 line
Acked-by Philip Balister <[email protected]>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.
Quoted 7 lines
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
Quoted 95 lines · Michal Simek
Quoted 94 lines · Philip Balister
Quoted 81 lines · Michal Simek
Quoted 80 lines · Philip Balister
Quoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 1 line
Acked-by Philip Balister <[email protected]>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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 4 lines
Thanks,
Michal
Quoted 95 lines · Michal Simek
Quoted 94 lines · Philip Balister
Quoted 81 lines · Michal Simek
Quoted 80 lines · Philip Balister
Quoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 1 line
Acked-by Philip Balister <[email protected]>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.
Quoted 7 lines
Quoted 4 lines
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>
Quoted 101 lines · Moritz Fischer
Quoted 100 lines · Michal Simek
Quoted 98 lines · Philip Balister
Quoted 81 lines · Michal Simek
Quoted 80 lines · Philip Balister
Quoted 68 lines · Moritz Fischer
Michal,
Quoted 40 lines · Michal Simek
Hi,
Quoted 37 lines · Moritz Fischer
Hi Michal,
Quoted 3 lines · Michal Simek
Hi Moritz
sorry for delay.
No problem.
Quoted 18 lines · Moritz Fischer
Quoted 4 lines
Add support for the National Instruments Project Sulfur SDR motherboards Rev 2,3 and 4.
Signed-off-by Moritz Fischer <[email protected]>Quoted 11 lines
--- 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.dtsiQuoted 1 line
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.Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 1 line
Acked-by Philip Balister <[email protected]>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.
Quoted 4 lines
Quoted 2 lines
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