From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbdJFLt6 (ORCPT ); Fri, 6 Oct 2017 07:49:58 -0400 Received: from mail-dm3nam03on0045.outbound.protection.outlook.com ([104.47.41.45]:3760 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751882AbdJFLtz (ORCPT ); Fri, 6 Oct 2017 07:49:55 -0400 Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; balister.org; dkim=none (message not signed) header.d=none;balister.org; dmarc=bestguesspass action=none header.from=xilinx.com; Subject: Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs To: Philip Balister , Michal Simek , Moritz Fischer CC: , , , , , , , , Arnd Bergmann References: <20170911232223.91894-1-mdf@kernel.org> <314acb1f-1f0f-7893-70a8-9379c01112ac@xilinx.com> <20170925161136.GA12943@tyrael.ni.corp.natinst.com> <6b87e902-3201-6710-4921-d465dea19dcd@xilinx.com> <20170926175018.GA14962@tyrael.ni.corp.natinst.com> <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> From: Michal Simek Message-ID: <58fe4e6c-8765-bd9a-0698-8f8326f95e40@xilinx.com> Date: Fri, 6 Oct 2017 13:49:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.1.0.1062-23374.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:149.199.60.100;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(376002)(39860400002)(346002)(2980300002)(438002)(377454003)(24454002)(189002)(199003)(356003)(50466002)(305945005)(47776003)(65806001)(65956001)(81166006)(106002)(36756003)(4326008)(230700001)(31696002)(81156014)(189998001)(316002)(86362001)(53546010)(31686004)(63266004)(77096006)(9786002)(93886005)(36386004)(54906003)(5660300001)(65826007)(33646002)(478600001)(2906002)(2950100002)(6666003)(7416002)(58126008)(6246003)(64126003)(8676002)(83506001)(8936002)(229853002)(110136005)(54356999)(23746002)(76176999)(50986999)(106466001)(107986001)(5001870100001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR02MB1344;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;PTR:unknown-60-100.xilinx.com,xapps1.xilinx.com;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2NAM02FT054;1:h6YkJVUQMVbRkWBcivl8hwg0wU3xQ/UvlH9p8I6SOEILqk+1hSupb50ZErecPQ3xruiRdV/eCMUVYOTyi7ksHc/j3GbnKduc6fE1AVu6ddLcH3lchT0gYj1CgL1n8G3Z X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 01429500-a9be-4f2a-c240-08d50cb05a8e X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(8251501002)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:SN1PR02MB1344; X-Microsoft-Exchange-Diagnostics: 1;SN1PR02MB1344;3:wDustbwGVmyNwZVbjCFkdECvz6wkf0qqr3YF8K5LGeNkXSk2lIzZGzknTEqN2dcUKe1YWLpUpVgksW9HUYPxtgYFBYrGxWiJaKn4FTMNsccZ8KCMDdtCp1Q/37b58eaVsR4a4NyN3u1ILT9yC6r8uw36NIKfDcvbp9vZZyzCkk67GXsA4iZ6AADB1osRytDsSJOKnrGAmSarhWUICchty96Y6GAmNg/1Vf2Q0OC2An81TXvS75PylFOmHtV9oZKEv+TaalM37Aq55CIQO4g0c1OA01FyTes4mev6fihh9CqEsrprxZz47MOV+wM9H8hHOR9w8jz7JT5GUhLPC+21FPyIi7zbtq/j5R4BKvjyNMw=;25:dYDAjsSvtrBOnL+PMWSrhnTBw5mxygMIOeXvHKZlj8DvTDg/gaxjPzdJBpGtatb19FtZBFm/iSbiH5p3S1CNGlSmIwDvXWh1u+YDouJtx45+mhVO8C3WdESgYz0afyfUru3F1cF/YkDrwxXW4P9XdQZRA2en8YVBOzaH7+/4iW/flnZuC8M9Kz6REtbt39z9Uy6JkIGevEJbRnlM5PETDbN5ZOIgbLSTeMIHu5Cf8LkwGMvmDDjNT3vjJOnW7hAaxf+7RXCPE0K99f7PUL15cMZLTRuK7mivRiRHrhcqiztBCmvfmGHt4fpI8bxkmeB86jNI7lMrXCPF1poHcMT8nw== X-MS-TrafficTypeDiagnostic: SN1PR02MB1344: X-Microsoft-Exchange-Diagnostics: 1;SN1PR02MB1344;31:Hz1OdWkZw/8NYco0PalUc+P9wuLOzypJHHJQGmLuCpb4Ey6JtNQOkLNqZ5mnf/wZCDbGgERsHQQSTbNDJ/uD6ErAQ3XaCvVXmXOSITptlUzUsMJZFMMuA4MjtSixWOIKo1pMKbfIIkqbTVEKHF/HqLyS4KVRspBiiDNhDpHc+417DSakk61/V0V3paYBAN8xpePFpX/RbnpTPyYmVsWw7/yiv3ZLcwwKkHSC4oaKnUM=;20:T220MZt3Czm5dmchrXJhSV6mQ9UpEI8WEgT7B3RqQT7Etbu9FAPLJG67yL1WhcATZi7v+C1Z3F1JHRcaWZZxFdnNsYgcMqW0pXLMvVTKVsbLAjuX13HKxyqeg0UTHcop2OjZ+dZV9UT1bW5Udx5i3FFm3jXahvuV/sidZUqCIdQTV/ch05xPSBap7hhM/Awhvumlqo3SXV5BxWJn8C5k8+tJ6QvULvYmde2x7qhwIbs2Xjsh2gQ4Qi7rx5i/JPywE3C8G7bxFhgMQ9uXVy0QMV4gbxnvlIla3wBu4VNHJO38hBE3ooi2+912w9Bwn7IHBYWNpzciw7lbBvt43rXgIn0c1SsJc/ZuOfa8THUeeMwE8F83QyfePSnuM5MMULr7FE0fFfD3FmZ6J2xRgLEkO7Fck/rYS0UgdB6tBno6tkF3pA3yp9AYkhHou/qC+gviTj8wNV+9aJWuhjNlpo/lBy2AgPReR4HL1FALCQVZGXxM3ki4YSezX2Gpry/fgBYI X-Exchange-Antispam-Report-Test: UriScan:(21532816269658); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93004095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SN1PR02MB1344;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN1PR02MB1344; X-Microsoft-Exchange-Diagnostics: 1;SN1PR02MB1344;4:l841tU4VRkbw0udcHYHE16VhTbv48+6cTzNuvdk6p9uucXVuPq7qM4O8F72rdjfUcuTaoRzBDebfqODWbsJqUe3Wrz8KqE3UFUeE/sI8lCWlxaCqoUACU5gJsHeNosGYzvFJcRb+HBDske1ye4yZMVtftbbmsjZFTIigyCVGLFqYxKhI+ewQ3H2e0fTSEkMlWmTcSCuhH1WPqV24bSMRP2aqIxD68IGXn/8MujfkCH5mMCzwaYYvED8s597eqNfqECDTbhMC6VEHuzAoNd+jmnF8BrUNM529kxmRIBud1xY= X-Forefront-PRVS: 0452022BE1 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;SN1PR02MB1344;23:ss9YMMqfYenbw/yXb8qEJgfQE89YURa12IHN1?= =?Windows-1252?Q?PsuDTI+8VBjlq1IEO6UlR4IdVkjyhqtXQ+ZcX5v1Wy1OWmy7G7hMX1nN?= =?Windows-1252?Q?hXWwaRvNaS8NnJm0IvOb8ga6Iqx21K+WI4fz62DreXLddWjbH+RBDNFB?= =?Windows-1252?Q?BGbAYDCvO1YNDN8qL0aAud+W5qdz8gIwOBCdBL/+a+ZKSt5gdGJ8MH++?= =?Windows-1252?Q?o5IpcYdPMqYuCmalxVuxNnlfy/+N4/D+AZXie7zbTtQ8njPkiolKqJ7q?= =?Windows-1252?Q?rqqwIVkwOrowErev1QRaiDHDthyCrWpqG1j+6LfsjuBA9vCJLbZLgRwV?= =?Windows-1252?Q?IUbTqymzKtysTTHPmqErJNLOT2jU0sPBrOv/FXEzf9Kf3Y2WGjXSqvBN?= =?Windows-1252?Q?puifyRXOWFnuFUgomxC+T0CHM/256ln/fdDKnTYMqBwmFS6F+wyHUAMC?= =?Windows-1252?Q?uZgZRlXlJAeZSB+5ZoAq/Vv3HXCDtywoIx2PiM4mm3y4gDddWMZrNQxq?= =?Windows-1252?Q?S803lvZIy10WmmRRQyhKA7BO4RlN9dtiwxHVs/wbAsW6ptb5tw+1WhDy?= =?Windows-1252?Q?7dr30vl96R5dzzCokUFifq4VSsTUmw2H9AEHGIUJ/qO8vOlrJogvzIH5?= =?Windows-1252?Q?WfLDpCyHt6rs4h/rf0OJLskb71a584gXwCqbjMI+DjIUycbVsBi00IgH?= =?Windows-1252?Q?jc3+W1kTAVGy8ulN9ZXW3enMx3LxWCxipkF4WL+xsfxLCmSnQR7j+eNJ?= =?Windows-1252?Q?Q1exN5ew/yE9c4DoLJVhMopeMWwJkflw4gZSbpEK2vX0OltcmqIHLPqM?= =?Windows-1252?Q?7iYvoA5DKWkW4RckSRS8zgoEMc1a7lPjlzZYl/2aSzvVOf8ElMjp1umm?= =?Windows-1252?Q?uORoAoreih04li2c2Oz+r4ZH2SafHHB7XTIaAgO8+fV3yYrZdzCbNhtj?= =?Windows-1252?Q?Xw3P48a5o/AepMCurPMxWNelmlWbQ+5bJCxS6pIEsV3E/AtfEyB85LCP?= =?Windows-1252?Q?OFGhw6NNOVhvTUo8AzfvdczFRqxGhU5SA0vPwKmBfdj2MRdZFATsDTlN?= =?Windows-1252?Q?Iqj9wOhAAUJpH6vaLkep4IBEyDZkDnBvAHJGc9kOSIvgzN1Mb9fnFAoM?= =?Windows-1252?Q?xZ8VolHynudkQM7BFc89m4G3cz8/jSgM22P0w4B6ii6nilLWO2NBa8HJ?= =?Windows-1252?Q?0KOc7VoWz00H7n7D4MEbBj3kEpl1kxUkWs9bl4hvmOrEpLUahMYfKR9U?= =?Windows-1252?Q?Q89MR8jrSl5p1EcCytHOeo2Ka+YFuArWm9yxex00aruxRWbSS0ZQTjbb?= =?Windows-1252?Q?ofnH4f74JzjQAia0vNRIkJ2iURmLZZlonB9O311tRrFNh+vvi3DEdNAD?= =?Windows-1252?Q?l0zapsit52yKkGGLpBUYS0v/mUx3rUztIviVHzfUEMPHGuOEamDJT7T5?= =?Windows-1252?Q?sV0r+oB+P9b6lJvsHMQ?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR02MB1344;6:5BnE44ohQm6fBP0RIIOfoQ1Jdce4IsL4BzswQOdncMQ1bNGaQu9ZYfezPqkL+PtxpopOj0zbHougEla4BB9KO9ijhZKQ+2vKcTTmWPQtER0IMHDus2d0rky9OxDGtYKwY2TXf+SfdqEACw73UQdaLoye7bkA6fKRH06thjbWK6+So/Mqhf3ystxk5cvVf8n1hznA9ndNHkJnnkxOGGUVRKYd00iFvisGmZ38VlFzUFPkKkQYQOTmQyO1YRcV/+tqqQJSLzVXvtcY5rghQkAs5VcbIa5+ymniC8VZqHujGc7BT+hc52qhvKxuwo96FTyEKCBNI/O2ByMTogNq7r3ioQ==;5:84IcFAx2LPkbAnCS4qI2x7X4k9FGv7AuE86eGt1R1x4mXVLB6KwRFzZgzw4n9tXnY9KB3wBbStKrOwjcN1Kr9todvQ833n4iv/SYl8ruIaDTGxXpI68t4lWcAV2iWp1nK+TfYUDLueXFQnxCJste+g==;24:bwWBM5XsrU68Y1WRwoVGtDMr67uUdxI2IiEnxdP93eXH5RohzcOQfzAf2qTOeTwUql49MuHjdEoUii1XJdNGi81prXpBQ329j2MQqRFZrPI=;7:Bck80pdBKu3M8fMLrUQDdCo3t1fZs8VwywMmOJQYPl3YUqpBNziUlMboErDgfJbaRM4ry9oyewbQVZOIwimuLuDmnyW9k/RU0Cjy07mrDEYgtb4Cjv5eavfpkRCfEZTV5INk0rvCIynOITjxkrpHxSVsJILeVvxMIckN0hmWsV8nt1/PEo1cLsG20MP3FrMz2miRSitPPLLxsf0A8fT1P2z8YqFPODQNabevrNz8B+o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2017 11:49:51.3532 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB1344 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>>>>> --- >>>>>>>> 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 >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Subject: Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs Date: Fri, 6 Oct 2017 13:49:44 +0200 Message-ID: <58fe4e6c-8765-bd9a-0698-8f8326f95e40@xilinx.com> References: <20170911232223.91894-1-mdf@kernel.org> <314acb1f-1f0f-7893-70a8-9379c01112ac@xilinx.com> <20170925161136.GA12943@tyrael.ni.corp.natinst.com> <6b87e902-3201-6710-4921-d465dea19dcd@xilinx.com> <20170926175018.GA14962@tyrael.ni.corp.natinst.com> <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Philip Balister , Michal Simek , Moritz Fischer Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org, mark.rutland@arm.com, linux@armlinux.org.uk, gregkh@linuxfoundation.org, davem@davemloft.net, linux-kernel@vger.kernel.org, Arnd Bergmann List-Id: devicetree@vger.kernel.org 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 >>>>>>>> --- >>>>>>>> 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 >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: michal.simek@xilinx.com (Michal Simek) Date: Fri, 6 Oct 2017 13:49:44 +0200 Subject: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs In-Reply-To: <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> References: <20170911232223.91894-1-mdf@kernel.org> <314acb1f-1f0f-7893-70a8-9379c01112ac@xilinx.com> <20170925161136.GA12943@tyrael.ni.corp.natinst.com> <6b87e902-3201-6710-4921-d465dea19dcd@xilinx.com> <20170926175018.GA14962@tyrael.ni.corp.natinst.com> <3b41cfc0-08b7-853d-3439-7f9848d04d3c@balister.org> Message-ID: <58fe4e6c-8765-bd9a-0698-8f8326f95e40@xilinx.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >>>>>>>> --- >>>>>>>> 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 >> >> 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