From mboxrd@z Thu Jan 1 00:00:00 1970 From: michal.simek@xilinx.com (Michal Simek) Date: Thu, 30 Jul 2015 16:37:30 +0200 Subject: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings. In-Reply-To: <20150729173802.GO2650@xsjsorenbubuntu> References: <1437783682-13632-1-git-send-email-moritz.fischer@ettus.com> <1437783682-13632-2-git-send-email-moritz.fischer@ettus.com> <20150728025833.GQ2650@xsjsorenbubuntu> <20150728225337.GF2650@xsjsorenbubuntu> <20150729173802.GO2650@xsjsorenbubuntu> Message-ID: <55BA36AA.2030601@xilinx.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 07/29/2015 07:38 PM, S?ren Brinkmann wrote: > On Tue, 2015-07-28 at 11:14PM -0700, Moritz Fischer wrote: >> Hi S?ren, >> >> On Tue, Jul 28, 2015 at 3:53 PM, S?ren Brinkmann >> wrote: >>> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote: >>>> Hi S?ren, >>>> >>>> thanks for your feedback. >>>> >>>> On Mon, Jul 27, 2015 at 7:58 PM, S?ren Brinkmann >>>> wrote: >>>>> Hi Moritz, >>>>> >>>>> On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote: >>>>>> Signed-off-by: Moritz Fischer >>>>>> --- >>>>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> new file mode 100644 >>>>>> index 0000000..ac4499e >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> @@ -0,0 +1,13 @@ >>>>>> +Xilinx Zynq PL Reset Manager >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible: "xlnx,zynq-reset-pl" >>>>>> +- syscon <&slcr>; >>>>>> +- #reset-cells: 1 >>>>>> + >>>>>> +Example: >>>>>> + rstc: rstc at 240 { >>>>>> + #reset-cells = <1>; >>>>>> + compatible = "xlnx,zynq-reset-pl"; >>>>>> + syscon = <&slcr>; >>>>>> + }; >>>>> >>>>> I think you also have to add the outputs and make them part of the >>>>> binding. Otherwise you'd have to read the implementation to find >>>>> out what device should be hooked up to which output of the reset-controller. >>>> >>>> Is something like this what you had in mind? I had that prepared for >>>> the next round of patches: >>>> >>>> Reset outputs: >>>> 0 : soft reset >>>> 32 : ddr reset >>>> 64 : topsw reset >>>> 96 : dmac reset >>>> 128: usb0 reset >>>> 129: usb1 reset >>>> 160: gem0 reset >>>> 161: gem1 reset >>>> 164: gem0 rx reset >>>> 165: gem1 rx reset >>>> 166: gem0 ref reset >>>> 167: gem1 ref reset >>>> 192: sdio0 reset >>>> 193: sdio1 reset >>>> 196: sdio0 ref reset >>>> 197: sdio1 ref reset >>>> 224: spi0 reset >>>> 225: spi1 reset >>>> 226: spi0 ref reset >>>> 227: spi1 ref reset >>>> 256: can0 reset >>>> 257: can1 reset >>>> 258: can0 ref reset >>>> 259: can1 ref reset >>>> 288: i2c0 reset >>>> 289: i2c1 reset >>>> 320: uart0 reset >>>> 321: uart1 reset >>>> 322: uart0 ref reset >>>> 323: uart1 ref reset >>>> 352: gpio reset >>>> 384: lqspi reset >>>> 385: qspi ref reset >>>> 416: smc reset >>>> 417: smc ref reset >>>> 448: ocm reset >>>> 512: fpga0 out reset >>>> 513: fpga1 out reset >>>> 514: fpga2 out reset >>>> 515: fpga3 out reset >>>> 544: a9 reset 0 >>>> 545: a9 reset 1 >>>> 552: peri reset >>> >>> Basically, yes. I guess the gaps are due to directly mapping this number >>> to bank and bit instead of doing some more complex mapping in between? >>> I'm not sure whether I like this :) I guess if a number is off the >>> driver would still toggle the addressed bit? >> >> My assumption was that people would use a #include >> in their dts. Assuming I got the >> numbers in there right this makes it hard to misuse by accident. >> I'm not saying it's perfect ... > > Michal always turned down the #include patches with the argument of > re-using the dts files outside of the Linux sources where those includes > etc may not be available in this form. yes. All these includes end up in more work when you want to generate them or move to any other project. I don't think that make sense to caused another problem just because of that. Simple add these values to reset binding doc and then you <&rstc number> in nodes. Because we agreed that it has to be done on driver basis this is just copy that macros from one file to another. Thanks, Michal From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Subject: Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings. Date: Thu, 30 Jul 2015 16:37:30 +0200 Message-ID: <55BA36AA.2030601@xilinx.com> References: <1437783682-13632-1-git-send-email-moritz.fischer@ettus.com> <1437783682-13632-2-git-send-email-moritz.fischer@ettus.com> <20150728025833.GQ2650@xsjsorenbubuntu> <20150728225337.GF2650@xsjsorenbubuntu> <20150729173802.GO2650@xsjsorenbubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150729173802.GO2650@xsjsorenbubuntu> Sender: linux-kernel-owner@vger.kernel.org To: =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , Moritz Fischer Cc: Philipp Zabel , robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, Kumar Gala , Michal Simek , linux@arm.linux.org.uk, devicetree@vger.kernel.org, linux-arm-kernel , linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On 07/29/2015 07:38 PM, S=C3=B6ren Brinkmann wrote: > On Tue, 2015-07-28 at 11:14PM -0700, Moritz Fischer wrote: >> Hi S=C3=B6ren, >> >> On Tue, Jul 28, 2015 at 3:53 PM, S=C3=B6ren Brinkmann >> wrote: >>> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote: >>>> Hi S=C3=B6ren, >>>> >>>> thanks for your feedback. >>>> >>>> On Mon, Jul 27, 2015 at 7:58 PM, S=C3=B6ren Brinkmann >>>> wrote: >>>>> Hi Moritz, >>>>> >>>>> On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote: >>>>>> Signed-off-by: Moritz Fischer >>>>>> --- >>>>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 = +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> create mode 100644 Documentation/devicetree/bindings/reset/zynq= -reset-pl.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-= pl.txt b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> new file mode 100644 >>>>>> index 0000000..ac4499e >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> @@ -0,0 +1,13 @@ >>>>>> +Xilinx Zynq PL Reset Manager >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible: "xlnx,zynq-reset-pl" >>>>>> +- syscon <&slcr>; >>>>>> +- #reset-cells: 1 >>>>>> + >>>>>> +Example: >>>>>> + rstc: rstc@240 { >>>>>> + #reset-cells =3D <1>; >>>>>> + compatible =3D "xlnx,zynq-reset-pl"; >>>>>> + syscon =3D <&slcr>; >>>>>> + }; >>>>> >>>>> I think you also have to add the outputs and make them part of th= e >>>>> binding. Otherwise you'd have to read the implementation to find >>>>> out what device should be hooked up to which output of the reset-= controller. >>>> >>>> Is something like this what you had in mind? I had that prepared f= or >>>> the next round of patches: >>>> >>>> Reset outputs: >>>> 0 : soft reset >>>> 32 : ddr reset >>>> 64 : topsw reset >>>> 96 : dmac reset >>>> 128: usb0 reset >>>> 129: usb1 reset >>>> 160: gem0 reset >>>> 161: gem1 reset >>>> 164: gem0 rx reset >>>> 165: gem1 rx reset >>>> 166: gem0 ref reset >>>> 167: gem1 ref reset >>>> 192: sdio0 reset >>>> 193: sdio1 reset >>>> 196: sdio0 ref reset >>>> 197: sdio1 ref reset >>>> 224: spi0 reset >>>> 225: spi1 reset >>>> 226: spi0 ref reset >>>> 227: spi1 ref reset >>>> 256: can0 reset >>>> 257: can1 reset >>>> 258: can0 ref reset >>>> 259: can1 ref reset >>>> 288: i2c0 reset >>>> 289: i2c1 reset >>>> 320: uart0 reset >>>> 321: uart1 reset >>>> 322: uart0 ref reset >>>> 323: uart1 ref reset >>>> 352: gpio reset >>>> 384: lqspi reset >>>> 385: qspi ref reset >>>> 416: smc reset >>>> 417: smc ref reset >>>> 448: ocm reset >>>> 512: fpga0 out reset >>>> 513: fpga1 out reset >>>> 514: fpga2 out reset >>>> 515: fpga3 out reset >>>> 544: a9 reset 0 >>>> 545: a9 reset 1 >>>> 552: peri reset >>> >>> Basically, yes. I guess the gaps are due to directly mapping this n= umber >>> to bank and bit instead of doing some more complex mapping in betwe= en? >>> I'm not sure whether I like this :) I guess if a number is off the >>> driver would still toggle the addressed bit? >> >> My assumption was that people would use a #include >> in their dts. Assuming I got the >> numbers in there right this makes it hard to misuse by accident. >> I'm not saying it's perfect ... >=20 > Michal always turned down the #include patches with the argument of > re-using the dts files outside of the Linux sources where those inclu= des > etc may not be available in this form. yes. All these includes end up in more work when you want to generate them or move to any other project. I don't think that make sense to caused another problem just because of that. Simple add these values to reset binding doc and then you <&rstc number> in nodes. Because we agreed that it has to be done on driver basis this is just copy that macros from one file to another. Thanks, Michal From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754200AbbG3Ohx (ORCPT ); Thu, 30 Jul 2015 10:37:53 -0400 Received: from mail-by2on0057.outbound.protection.outlook.com ([207.46.100.57]:37893 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752574AbbG3Ohv (ORCPT ); Thu, 30 Jul 2015 10:37:51 -0400 Authentication-Results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=xilinx.com; ettus.com; dkim=none (message not signed) header.d=none; Subject: Re: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings. To: =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , "Moritz Fischer" References: <1437783682-13632-1-git-send-email-moritz.fischer@ettus.com> <1437783682-13632-2-git-send-email-moritz.fischer@ettus.com> <20150728025833.GQ2650@xsjsorenbubuntu> <20150728225337.GF2650@xsjsorenbubuntu> <20150729173802.GO2650@xsjsorenbubuntu> CC: Philipp Zabel , , , , , Kumar Gala , "Michal Simek" , , , linux-arm-kernel , From: Michal Simek Message-ID: <55BA36AA.2030601@xilinx.com> Date: Thu, 30 Jul 2015 16:37:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150729173802.GO2650@xsjsorenbubuntu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-21712.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11OLC004;1:ZK6uodoXDQ7gOvF6RHOiz2HnCPGt7qSV+V14kcww1RsMvUxaVYzZtf47rbiCOUof3OXV62Pc8YhMs1lk7z5B4CF1wMIMl/h/3xpcwTtCbcOYrnZTuvKSG1xu4t7+zby6VeIem5z4zVbTtfqE63CG9DW20Ej3uCgOHaml+oFhsX2TQ95T+jsGUM026GQYoqpndhZqYxUQJgGD4zzkqjKYYDOKU5dmjMMxsTo94WAHBQ1Kdj7ObOwfwj1XruBnjOKaVUVBHU9/FJ5VP7gzYZh5MlCqu2NiBn9qEkhqUlrjGClFtlaQcS+6wMee4+bLOLH8 X-Forefront-Antispam-Report: CIP:149.199.60.83;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(479174004)(377454003)(24454002)(189002)(377424004)(199003)(164054003)(65956001)(62966003)(63266004)(76176999)(77096005)(80316001)(50986999)(47776003)(19580405001)(33656002)(6806004)(65806001)(83506001)(36756003)(23676002)(50466002)(86362001)(5001960100002)(46102003)(93886004)(106466001)(5001770100001)(87936001)(36386004)(77156002)(19580395003)(54356999)(2950100001)(189998001)(4001350100001)(92566002)(107986001);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2FFO11HUB042;H:xsj-pvapsmtpgw01;FPR:;SPF:Pass;MLV:sfv;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11HUB042;2:RJ3Oxb8quTKI6uqgcOoNI1VmZXEzoXXSRNvKWC2WXP/Xm0Z39utZsimBSl84pwzr+pBrpwljs6EfatomvIeikU7RFzoVovVgKbf1PyxVLmGk0yZA5z6JucPHT+tcfOxKO7hvYtWSN8JccptiL37ZTsCteJigAU+vwQIls8/AJZM=;3:Ks/EqHoCgegDyQTLXnnJW/5tHf2oNLu79eRwbMyWZQMEWLQ8OMCqZGu75CLMxkDnT9EDTQakfss5DRUs1TLL+XweP8m9ieqUD3TXkObePeQB8bM+s5hDF+4lTZZbNTrbWIFWUeHC0MRPKFebqlxC2+SCWdQ2aM07CVBE/xAmlxPpVeFxXnuetfxq8E1MMwty5bBPztxFCsaRliVVt+YyOGQrROJYijd1+wVaZbf8PRs=;25:6RLwtbkFhPUrzUliu0oQrL2rDUrz4vGhWQkNNTDOOp/gNrwu44jqXSRo7517OxK0IlZudhMfYJqoZ2+Hw5UXHr6c/Wj5fuGmg2nAGxNroV4uuUiPK2Nboua1OYJVJa6J7VxULKO+ep+bCRctPk5NYTFycgV+8Cwq/mX7U+BXR8R07MtRgtpv+GC1Uo0f5nnyIdwjyXI+HKVqaCsQ7H4CI32Wts/Mk5DnDPrFF4Ay4LMZCXCQc3CQUllUS67S8/h+3+DOt5Yp+wC60q4R/T5M+g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB042; X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11HUB042;20:tUloBzjkH3CzEi7luknzfUpvsF21BtfNuLB8Oot4dCQLql48mXtVpjFq43oAWpdenjn4T4rXfDCu3RbPJDqf1MCPI0yqyvA/DCN83C3RceHEDv4Z5W8jxc/pd810ZHnbqRYlHN3nd1tegZA8yCR2C7uzW05vYs6sOIcWJHr/vmdGd4zRfUGj/LzrtfLfCO9zFmq1jdVJBicCcKA/INxmbzxq5Z6SjBs1OlYOfZMOokp1GoT3h7ODkKM1wwbycnEQa3/QiCPlUi0y5cW3qB63DOmBW3yAg63pXxoQx17+kCr7wLSd3BixN3jtQ/3EVeIVP1P8iHjF+H1IWLGJap/F5V7vTbYikhCV+6vhilIqHbDotNPYS5EavxG3EwDQEBeWXtcDBZLvznnNF9pdb69XlXk2/gkQc9yJDNsfhP/lKZo9QRwweXUqHKkEN+dN6hOskHITYaBMtR9ZmrI1w4aC0x+J8KSBPLbefTCzGdlqokKw3EiRFMKo6qVG8nUeljgT;4:2G/Koo/1WnY8V6a00Pf8dVHpENhKSyGCyfLxF/cMchTmKbKeKzY05vqP/Ef7sA3/RjtBr61YaLwqaaOxebf7GsQp+fVV41i18mdWT1tHjTIrPe6JH1/BclzUzCn+CJvhNaiJy/uJetr/CUi754iqxIOETAJaAjfG0ou+Sq0l0oP1bS1vLZcX/5YtPAnsK0Bo1oRXY0ind+n3BaL02gtTPOxaqFVKn/ST3649tDSQVqsdh+mH75GmNLMzrxW+f44TXzE0YUFuOKr3heaT6c/gFxXHJo1exdvWUUm8kZ3zSFc= BL2FFO11HUB042: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BL2FFO11HUB042;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB042; X-Forefront-PRVS: 06530126A4 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTDJGRk8xMUhVQjA0MjsyMzpnV3RqaXZDZHVINU1QQm1wWEVQTlBNZk5j?= =?utf-8?B?dEdLYkR0T1N6ZWozdEpyYkJuemdFTjdVSDdVZ2NUa2FGUEkrVmoyZGpkeG9z?= =?utf-8?B?VENUaEY1Z21aZ0YrVGR3T0dVMFdUMVBaWHJQblM5UzlNb3NqaGpTYW5TMGJm?= =?utf-8?B?K2ttbEtOcTNlNmd1L0dYOWJqL2dKdGFqN0xqYXhFa1VDWVJNQlVtdEtHbS9s?= =?utf-8?B?eHlaYzdWSjk0OHZJME1obFNEWmwwNVpwNXlTS2YwclM4RkdxTWFoQnZad1gv?= =?utf-8?B?V0YxSmdLcnJBYThpVWNnZElQcTJGYlNWTHlHR1dJWVJBSVBqZVBZTm0vTkVN?= =?utf-8?B?cTlMRGVIMjFCN1BhRTIzNzY4bGhpREN2djlXMGk2dUNyMUZwK1dmUmtTUFlu?= =?utf-8?B?WHBNUGU1NUlORytrdWMyeHpUZGVNMFBid0RxS3YzTDQ0ZTRXTGdON3p2Wm1o?= =?utf-8?B?cXVFTjhKYkM0WnN5M3YzLzRsM2ExbTVKZS9NNWo5czRGbUhUYWRuR2JUbjA0?= =?utf-8?B?b3dLVjR2YjQ3ZFNlNkhHZzRQeTgva3lOV3U3Y2VCbytOZUNETDhoZWN3VjEr?= =?utf-8?B?MFhSWHBsNVFpRmRXQWh3WEpCMDArazFzMnBDYUhzTlp2d2hpb28yNGFCdCs2?= =?utf-8?B?SFlPK2lUQmZUOEFaMXhhelZ1WUZPUXd3bjBoMDBCZjdtUmsxaWtzL2JpbDJW?= =?utf-8?B?bXpFMjdLOCtBYmxJdjdqR0pxcEdBUFNVNjVQMzJaU3Fiem95amRUZzhNLzdq?= =?utf-8?B?d3Q0NGhVRlBwVGRzZWtqSlNWK0lQdzVNayt1d3lZNllyemZzanJvTVRCZ25t?= =?utf-8?B?YUFJNi8vTW9mNDQxeEF1cWJFMWhEcit6UXg5cVZjRFdkcWhpbERFZDM1aEo0?= =?utf-8?B?VlBlUnhwWVA2ejRGZEVDUW9PcnJDWVlPV1RxUWlSTVYyQUtCeXNPaWFMVGkx?= =?utf-8?B?NFdBMC9DYWJlNWJISjBNaEpsYUJhNklNYk03SFZBTU1ycGNMcmRoc2ptV2hG?= =?utf-8?B?Yng1dTI5dzI4MWx2S1BwaHpKWWZ4WGJROTRkcnJ4SldoVWRIQXpZMUU1TnE1?= =?utf-8?B?SmtRU1p5RHBGVzduUTRMRiszbDBhZFRPM2h1MEhma1V4Ti84U1kvRUJFUGxw?= =?utf-8?B?S0lGUTNFa1h2UWdWRnJ4bUxMZk9tOTNPOEUvakVEWXJhKzhKYTdLbkRvQXRK?= =?utf-8?B?MEFpQ1JKQ25JRzhxelA4ekdxRjRBb1Z5QkdxWmJsUWM0Y09SbUxTVE5IeVJm?= =?utf-8?B?WkhoVUJXM2tsbWIyUE5XMUpMSVI0M2RuMHcyZzhtdFlKbEY3aElFbXkrQ3lU?= =?utf-8?B?RTNqUEd1aXY0T1UzczFWWkEveDhkdTc1UjZqM0dOa3lkOXVyMUZpS0poZlA2?= =?utf-8?B?eUoveWk3YjFOcWxOa1VYRHJ2c2FjNUZGK0dMQVdRTWNxNWFWZzFndWp0Szdi?= =?utf-8?B?aFBFdUF5VHpsSWFEeEFCdkQzNk9YYjJ2RUl2WEE0RXh3TlhkRUxVcHd3UW1h?= =?utf-8?Q?UycmNUECDMpC36oHKUuhOMKHfA=3D?= X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11HUB042;5:SH8KdUywQI+2rURZUhPTlLsSvCrLr4dJXm3KuXzdsIpBY0hptnJawtoONVbjiGTRUYAQhHQtfaQHHpUqmfS8DbFVjGYBRBhonL4SAESbeOCMf4FPAJVYspJd+F9SZiIWTk3XC7FX0i1RI6aCRysD8Q==;24:fhkpJDeKaVFu9inm/MZzvfOHpQn02xyypKkUcjOJmuwKa/1NUCL0nHjg99ZHMpKB2I1c5RqYhERVgYqtynJGGbub+302qTXot0x6jk6xNC0= X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2015 14:37:38.7650 (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.83];Helo=[xsj-pvapsmtpgw01] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB042 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/29/2015 07:38 PM, Sören Brinkmann wrote: > On Tue, 2015-07-28 at 11:14PM -0700, Moritz Fischer wrote: >> Hi Sören, >> >> On Tue, Jul 28, 2015 at 3:53 PM, Sören Brinkmann >> wrote: >>> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote: >>>> Hi Sören, >>>> >>>> thanks for your feedback. >>>> >>>> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann >>>> wrote: >>>>> Hi Moritz, >>>>> >>>>> On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote: >>>>>> Signed-off-by: Moritz Fischer >>>>>> --- >>>>>> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> new file mode 100644 >>>>>> index 0000000..ac4499e >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt >>>>>> @@ -0,0 +1,13 @@ >>>>>> +Xilinx Zynq PL Reset Manager >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible: "xlnx,zynq-reset-pl" >>>>>> +- syscon <&slcr>; >>>>>> +- #reset-cells: 1 >>>>>> + >>>>>> +Example: >>>>>> + rstc: rstc@240 { >>>>>> + #reset-cells = <1>; >>>>>> + compatible = "xlnx,zynq-reset-pl"; >>>>>> + syscon = <&slcr>; >>>>>> + }; >>>>> >>>>> I think you also have to add the outputs and make them part of the >>>>> binding. Otherwise you'd have to read the implementation to find >>>>> out what device should be hooked up to which output of the reset-controller. >>>> >>>> Is something like this what you had in mind? I had that prepared for >>>> the next round of patches: >>>> >>>> Reset outputs: >>>> 0 : soft reset >>>> 32 : ddr reset >>>> 64 : topsw reset >>>> 96 : dmac reset >>>> 128: usb0 reset >>>> 129: usb1 reset >>>> 160: gem0 reset >>>> 161: gem1 reset >>>> 164: gem0 rx reset >>>> 165: gem1 rx reset >>>> 166: gem0 ref reset >>>> 167: gem1 ref reset >>>> 192: sdio0 reset >>>> 193: sdio1 reset >>>> 196: sdio0 ref reset >>>> 197: sdio1 ref reset >>>> 224: spi0 reset >>>> 225: spi1 reset >>>> 226: spi0 ref reset >>>> 227: spi1 ref reset >>>> 256: can0 reset >>>> 257: can1 reset >>>> 258: can0 ref reset >>>> 259: can1 ref reset >>>> 288: i2c0 reset >>>> 289: i2c1 reset >>>> 320: uart0 reset >>>> 321: uart1 reset >>>> 322: uart0 ref reset >>>> 323: uart1 ref reset >>>> 352: gpio reset >>>> 384: lqspi reset >>>> 385: qspi ref reset >>>> 416: smc reset >>>> 417: smc ref reset >>>> 448: ocm reset >>>> 512: fpga0 out reset >>>> 513: fpga1 out reset >>>> 514: fpga2 out reset >>>> 515: fpga3 out reset >>>> 544: a9 reset 0 >>>> 545: a9 reset 1 >>>> 552: peri reset >>> >>> Basically, yes. I guess the gaps are due to directly mapping this number >>> to bank and bit instead of doing some more complex mapping in between? >>> I'm not sure whether I like this :) I guess if a number is off the >>> driver would still toggle the addressed bit? >> >> My assumption was that people would use a #include >> in their dts. Assuming I got the >> numbers in there right this makes it hard to misuse by accident. >> I'm not saying it's perfect ... > > Michal always turned down the #include patches with the argument of > re-using the dts files outside of the Linux sources where those includes > etc may not be available in this form. yes. All these includes end up in more work when you want to generate them or move to any other project. I don't think that make sense to caused another problem just because of that. Simple add these values to reset binding doc and then you <&rstc number> in nodes. Because we agreed that it has to be done on driver basis this is just copy that macros from one file to another. Thanks, Michal