diff mbox

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

Message ID 20170911232223.91894-1-mdf@kernel.org (mailing list archive)
State New, archived
Headers show

Commit Message

Moritz Fischer Sept. 11, 2017, 11:22 p.m. UTC
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

Comments

Michal Simek Sept. 25, 2017, 8:19 a.m. UTC | #1
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
Moritz Fischer Sept. 25, 2017, 4:11 p.m. UTC | #2
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
Michal Simek Sept. 26, 2017, 12:54 p.m. UTC | #3
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
Moritz Fischer Sept. 26, 2017, 5:50 p.m. UTC | #4
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/
Philip Balister Sept. 26, 2017, 5:58 p.m. UTC | #5
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/
>
Michal Simek Sept. 26, 2017, 6:06 p.m. UTC | #6
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
Philip Balister Sept. 26, 2017, 6:15 p.m. UTC | #7
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
>
Michal Simek Oct. 6, 2017, 11:49 a.m. UTC | #8
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
Philip Balister Oct. 6, 2017, 2:58 p.m. UTC | #9
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
>
Moritz Fischer Oct. 6, 2017, 4:18 p.m. UTC | #10
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
Michal Simek Oct. 9, 2017, 5:42 a.m. UTC | #11
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
diff mbox

Patch

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>;
+	};
+};