From mboxrd@z Thu Jan 1 00:00:00 1970 From: atull Subject: Re: [PATCH v16 0/6] Device Tree support for FPGA programming Date: Thu, 11 Feb 2016 16:17:13 -0600 Message-ID: References: <1454707803-27947-1-git-send-email-atull@opensource.altera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: Pantelis Antoniou , Moritz Fischer , Josh Cartwright , Greg Kroah-Hartman , Michal Simek , Michal Simek , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Jonathan Corbet , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , delicious.quinoa@gmail.com, Dinh Nguyen List-Id: devicetree@vger.kernel.org On Thu, 11 Feb 2016, atull wrote: > On Thu, 11 Feb 2016, Rob Herring wrote: > > > On Thu, Feb 11, 2016 at 2:49 PM, atull wrote: > > > On Fri, 5 Feb 2016, atull@opensource.altera.com wrote: > > > > > >> From: Alan Tull > > >> > > >> v16 Refactors the FPGA Area and FPGA Bus into single thing called an > > >> FPGA Region and eliminates using simple-bus. I'm using the word > > >> "region" as it's a term is used in the literature of both the major > > >> FPGA manufacturors. > > >> > > >> Changes for v16: > > >> * Refactor the FPGA Area and FPGA Bus into a FPGA Region. > > >> * Don't use simple-bus. > > >> * FPGA Managers and FPGA Bridges are now specified by phandle using the > > >> "fpga-mgr" and "fpga-bridges" properties. fpga-bridges can specify > > >> more than one bridge. > > >> * Device Tree overlays should be targeted to a FPGA Region. > > >> * The overlays need only contain firmware-name and the child nodes. > > >> * To model a system containing >1 partial reconfiguration region, > > >> an overlay could add FPGA Regions to the base FPGA Regions. > > >> * Child FPGA Regions inherit the parent FGPA Manager, but specify > > >> their own set of bridges if needes as partial reconfig regions > > >> will likely need their own bridges. > > >> * All this is discussed in bindings/fpga/fpga-region.txt > > >> > > >> One other highlight: > > >> The little engine that runs this thing is a reconfig notifier > > >> in fpga-region.c. This notifier that will program an FPGA if a > > >> "firmware-name" property gets added to a fpga-region. Then > > >> it will call of_platform_populate(). The current behavior in Linux > > >> when a DT overlay is applied is that the reconfig notifications > > >> go out in heirarchical order: first notifications are for the > > >> properties, then notifications for the child nodes. So an overlay > > >> that adds a 'firmware-name' property and some child nodes to a > > >> fpga-region will cause FPGA programming and child node > > >> populating in the right order. > > > > > > I figured out how to get rid of the reconfig notifier. > > > > > >> > > >> One issue with the dynamic DT stuff: > > >> I've tried returning and error from the notifier if FPGA programming > > >> fails; the error is noted on the console, but the child nodes > > >> get probed anyway. > > > > > > I looked into it further and now I've got a solution for this issue > > > that I can post soon. I can stop using the DT overlay configfs > > > interface and add a sysfs file for applying an overlay to an FPGA > > > region. The FPGA region implementation will see the overlay before it > > > becomes part of the live tree. Then it can do the FPGA programming > > > and see that succeed before the child nodes become part of the live > > > tree. If FPGA programming fails, the overlay will be rejected before > > > it becomes part of the live tree. By the time 'firmware-name' and the > > > child nodes show up in the live tree, they will be post-configuration > > > information. > > > > Um, no. We don't need 2 interfaces for loading overlays from > > userspace. I could see this being a common problem and it needs to be > > solved. But given the configfs interface is not upstream yet, perhaps > > you should worry about that after the current series is in. > > > > Perhaps we need a pre-add notifier and the core will only load the > > overlay if nothing handles it. Really, a solution without notifiers > > would be preferred. Maybe register handlers with the DT core for > > certain paths. > > > > Rob > > > > Yes. If any handler returns error, the overlay doesn't go into the > main tree. Handler type to be registed could be: > > int pre_add_handler(struct device_node *overlay, > struct device_node *target) And a third parameter of some flags to indicate whether the overlay is being added or removed. > > That gives us the overlay after it's been unflattened and phandles > resolved and the node that it was targeted to. I was going to > need find_target_node() to be exported, but this avoids that. > > Registration could by compatible string, of match, or path. Path > would be too rigid in my case, I'd want to register for compatible > "fpga-region" > > Alan > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751219AbcBKWfU (ORCPT ); Thu, 11 Feb 2016 17:35:20 -0500 Received: from mail-bn1bon0079.outbound.protection.outlook.com ([157.56.111.79]:49712 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751140AbcBKWfN (ORCPT ); Thu, 11 Feb 2016 17:35:13 -0500 Authentication-Results: spf=fail (sender IP is 66.35.236.236) smtp.mailfrom=opensource.altera.com; codeaurora.org; dkim=pass (signature was verified) header.d=altera.onmicrosoft.com;codeaurora.org; dmarc=none action=none header.from=opensource.altera.com; Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=opensource.altera.com; Date: Thu, 11 Feb 2016 16:17:13 -0600 From: atull X-X-Sender: atull@linuxheads99 To: Rob Herring CC: Pantelis Antoniou , Moritz Fischer , Josh Cartwright , "Greg Kroah-Hartman" , Michal Simek , Michal Simek , Pawel Moll , "Mark Rutland" , Ian Campbell , Kumar Gala , Jonathan Corbet , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" , , Dinh Nguyen Subject: Re: [PATCH v16 0/6] Device Tree support for FPGA programming In-Reply-To: Message-ID: References: <1454707803-27947-1-git-send-email-atull@opensource.altera.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [64.129.157.38] X-ClientProxiedBy: SN1PR12CA0005.namprd12.prod.outlook.com (25.162.96.143) To BLUPR03MB1506.namprd03.prod.outlook.com (25.163.81.24) X-MS-Office365-Filtering-Correlation-Id: 67f8f7d3-b5d2-4582-0e18-08d333315b6a X-Microsoft-Exchange-Diagnostics-untrusted: 1;BLUPR03MB1506;2:bWiVsLgOfcu6UAu8eJAsBZKS/X9GOxwb5b5f2n/RcIkexFXLLJGLZ0ebi6GFLiycSlf1Qxr4pL/7edvZQ8MFHlK71l7FV8OVLTxA4mv4z56uKwLPVafkshoTi6cc8sGsTr23uy/zpA2N6tl35MhRCsk8N0W4rE36yyx5U5+4b9VEqCgx4gs1vp/Eg8vRHZrc;3:0LM6War7xCOaCGr0M4L+OYebJatQYujsPu76VItaI18HB/O42C0BvoBc7qYkv6rpBMz4aWOK1WyLFBHEamO3bbMlRSiMUeEI2iNT+W+iPRrfd5g+EsFBJ6k47bKf1/Qx;25:1xiqsbrmiJRYNqiR3KxoYy5CZr4MlG0xDshn3rEm8GlcgedVEQygATKTthPnCc2mBAyYBWNa6rWk6CFRNqE/QPcz/PtDTiCz7+BU94GFMvgtMlHKxXzhluSYF1JqRCgNQFywg+++oIc9gpkWTeEMYDxOZcbsaVPvcVbB+WYuVKprddRvxHlubQrWPkAUQPc9Xn+mYlzBIjhI/lc+9UneMZHwFt16+8yXnoXn5ADcezYYzLOCCnluKVvrf6rr2KdJMrDDIpiap1LhPqgu7eAUXx2UWxtTCoi6U3c+GNIGMGtmxUwH6wJbGegYVINcPZue;20:1vVdLhXmdAxu/mnZx40g8hgDAqBRKdY//MTKylNc+QElat+HjoZR78PXsiWClKpfmIU+Tufak6rUOJ+yKFWqEoCw1xg0ohKkQh2erq1bDNBuqLfwgogzKB26HugHmAde+BRy84mjRLnugyEoeMbrb8c48y9v9dluVQ/Y3hwEvDw= X-Microsoft-Antispam-Untrusted: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1506; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(80048183373757);UriScan:(80048183373757); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:BLUPR03MB1506;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1506;BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(13015025)(13018025)(13017025)(13024025)(8121501046)(13023025)(10201501046)(3002001);SRVR:CY1PR0301MB2025;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB2025; X-Microsoft-Exchange-Diagnostics-untrusted: 1;BLUPR03MB1506;4:+xrUN1U8Kb2dlcHV/zN3Chjy7RY2ey+b8sDafVx6n/17Mq5W/MYQnZ01NvzJ7mHJa81JBeaJce+ZkqmmTAUz19urK5sA074VOWUCzJiK5EOHvEbGb1NlkII4zF2yK8Ua/GqM79wYWdgXs8pAYctnaLuftKTEvdmk2r1rLSYNOn7QL3uVEi7LWSUGr+aeO/cyWDx4obaFb62HUFz4IQ/GMrLGJJkHGrvt56q7Lqb4+3ness8hIaj7mlPYnbYpcOQJYDk94MdVkX9tr6/XdP0AbL2joHJtxOEmSiKEjh8yDdiq0przTJiBTBC1GspM2TbvD0EmP+i7f6JBjxhB8JgQ03Z+3Q7hwXlISBVSrw4AUJzWm9D20eQCHfhOtOUyCRN8QM/0dGDlMJaLtjM3hcrDhN8ZxHGzcClzR+umQTHa1JM= X-Forefront-PRVS: 08497C3D99 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(6009001)(377454003)(24454002)(87976001)(5001960100002)(3846002)(6116002)(110136002)(46406003)(2950100001)(50466002)(107886002)(4001350100001)(122386002)(53416004)(42186005)(586003)(40100003)(4001430100002)(189998001)(19580405001)(93886004)(76176999)(50986999)(54356999)(83506001)(86152002)(66066001)(1096002)(4326007)(5008740100001)(23726003)(19580395003)(47776003)(86362001)(92566002)(5004730100002)(2906002)(33716001)(77096005)(5005980100003)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:BLUPR03MB1506;H:linuxheads99.altera.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics-untrusted: =?us-ascii?Q?1;BLUPR03MB1506;23:lECy0bDFGvLqWh7u681s5sRI7JEYqJYTS3X8764FP?= =?us-ascii?Q?P+76YJU+D3FTVlmTZQ8o5aSBkH53XvEFdToQNgnU9xpGSrXTfyIVix01YJW6?= =?us-ascii?Q?paroQkup0Cz/uh/HKLrW5/rN3l8QAxyteRwqAwC1cAyCla+NmpUF6CTcKC58?= =?us-ascii?Q?IZcIRpAn6iwwmNfBhrck88uMnr+tQF5xt9GP3UW8WKyRX33KWcfHacfQ2Jma?= =?us-ascii?Q?RVLaDjOpKIA7omTCPq+tSM9hXlYSdo2i/K7pj4Yf1CzSLZPqgMFxsxP+Afng?= =?us-ascii?Q?Nn3/f+1tLfLslwpCxjW0DzUw4bi9J3X36l6gTOs9k5kMbcAGheH66qUz+wNY?= =?us-ascii?Q?XlD3S0busUxYTBqT8DHXygOYxFijBbSxtoEFa3JYQjPF4kA/+lnyeNmIBvHd?= =?us-ascii?Q?tg6HLi8Njso/OckrLLIjVVje7cX29LhNzuXIsKGuRMEmSbjeRV+0MyNJs6NA?= =?us-ascii?Q?hRDGCBleIvCo/U/eI3Xpk0LeI6iAbNV2geNZ5WQzuUSG8RaC1xmQyeH23TQE?= =?us-ascii?Q?hoMsZBaBC+nEpPfguumKFI4cen2qt4E7C/Y6IaH1G69IOWlBSNeiPPRq4qNw?= =?us-ascii?Q?E2F/BCVnh3DDOqO3r9xVyNZMFVYw9+OEbJ5bDrjl9/1A4s0R/PBDaFAQxLSD?= =?us-ascii?Q?cGK8C4z1U2rI9Qps+xsosA+C4ivDNyrAIzK8R8VZXwZBgjDoCKs5OYnmSJFO?= =?us-ascii?Q?KbcMD0AjN21vDNDd/lkCjpulTDrYqg1mBhOHBI7Dg2qDa8qKWyeDUV4Qd0Nm?= =?us-ascii?Q?ujNyaGNFsnqJNfILCNDB9QB2mk8guMLvszvOFSNez1bd6dD1F7+NE3JbGgq3?= =?us-ascii?Q?InYHu7nQwnXx0Z3kn+WBUwbprz4ei36K86zKEnIuMDGDIJiJ3ZcOKxO3d8bC?= =?us-ascii?Q?4tPgHyoFTIB7iDVK/I1kJIzYBfY+WO0Oc8xv/WZcPCKx7bz1VZuznlomlua+?= =?us-ascii?Q?EZyK3i9Of9WKIlrzFwE1W5CCAf2ZF67F9XqKY9oRPcZNQ59WJWDH/j0g8Atu?= =?us-ascii?Q?7DSawQHrKaHg3uWTjBU4D19fxnGHrOk/YZ0RcwKkSZ1o3A5aMkcGi7hfGBY3?= =?us-ascii?Q?G/cJOpbSJyxkdjbmttunHfutgIG0lGNX7T+hGqxjDkafEu3HCcmGtRZIt8Xc?= =?us-ascii?Q?2+h7RBMwZj1w5MW7F2XjIJMye7exDrM?= X-Microsoft-Exchange-Diagnostics-untrusted: 1;BLUPR03MB1506;5:mNCLpoRqLmtXpy8AxucHzh8J7RCEJpzfErwJfUWl06SZoM7z9vRE/LwIDrqnIVOc/U555gvpzISub/TcH6u81kmAbd6OzwwvZ8toHBqcDKU5atIKVvrCIWRUnriAh+wjduaURAB24BrJyyClyqfJjA==;24:3gKnaNCDLIBNJkJ17WS7fddas22sIb3O4W4ejSbKXG1d6mv5l9qhZpWozawZUP5/9AC1XShHlcRxqWzLuvjynrvrvxrtwQNIIVTbWoVgb0w=;20:Hy63JpWWiADe5HGunuu3cDpkq/hKagFWMlEro8ny8HOe6FFN+iuQPNK/gk0JgaC+jHspcHJ1y8Eb8iYenbvgALGg9d6123TH5EfJRUZR5M2bUeZgTKMjn1tjp9U26ObqKLZYJydeb1c2LCzAJIfkJy4c/UHaS1cvPJZp1x8cBiM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1506 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: BN1BFFO11FD028.protection.gbl X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD028;1:FTkOa0BTE68t5Q8lJiDXw+TsbUFu2mTXGtQfvQbBz+B+7VnyU5OJmkfTmDYeMPCLjm9zNV+XN28FuwwrFuDblZrOJpYXbGoFns8bb7/aebppWkxxyBhhK504OtGRpIK26zfYEPn+JxZxE4EGKa7UIb7F1BghcLDMPcZ2QmRGdARa5yFCU5RMPpM2FSMPFsDdPq7toep5TXecH2rYerfFZvnMiDnqY+GzLR/FYiZjKSC/l0RAX3gH+C9pyswocf+XTY/abbl/G7DU2eS8FJxf/lXV5PCIX96v1YA2SQCfLBKD46tu4zhqATH4JR5Zx2gVV3L67gZuTxjwof5cHCDBUlUbkC+uDzV3D9Cll6+n54C3/u6m74WDsIhjTdUrgvtbP3zmOjQtIg1HgypbdxKUzyNtIxrMRS+RBPaSD0X3GJL4LRiw/fBCw8q8XGNhzm+619A1yiPiov8AoxKzQHZXXQ== X-Forefront-Antispam-Report: CIP:66.35.236.236;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(1109001)(1110001)(339900001)(377454003)(199003)(24454002)(189002)(4326007)(47776003)(93886004)(106466001)(33716001)(2950100001)(46406003)(6806005)(956001)(87936001)(5008740100001)(40100003)(66066001)(5004730100002)(122386002)(53416004)(11100500001)(21840400001)(105606002)(19580395003)(2906002)(77096005)(1220700001)(16796002)(86152002)(83506001)(4001430100002)(92566002)(4001350100001)(5001960100002)(3846002)(85426001)(23726003)(3720700001)(107886002)(76176999)(86362001)(54356999)(189998001)(1096002)(19580405001)(50466002)(586003)(50986999)(110136002)(6116002)(7099028)(5005980100003)(7059030);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR0301MB2025;H:sj-itexedge04.altera.priv.altera.com;FPR:;SPF:Fail;MLV:sfv;A:0;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0301MB2025;2:JmbnCr/katggvHSMqhDj3ZK6vG0N/XiZ2VohDAOzcJJeQLsG+LqeXIMPpE+THwKiWVAL2LgkC6o07mNVSgd+mxM80b5NLk9h8hJf+Ll0gCI/CSNC40TlgCi0/C2pXCPW00NRYJ1ScJ3yZCZqME0R4CAt7zBCDtnMJ2eR/MK4s3943NIZvSLhYTTlvDQqzP72;3:H07+kQmSi4d+Va3gML1VbU9Q7DYqWIqkqZV7A1vxOD1sremPo3Jn3IMsYEiaNGnJ+yM7Bfl2Alq+KYkJIe1JdBZ8tZYL4ScC1Uii33OouzLL7q9btvSHvhJeCKzwBIfr1fmL3geWGNqHdqqp7TnOnCuiOB5ipjWjzYEUhkimRVVKa0J1GK4jVN1Wb2xLeLkFMLOW8sObb1liAuyzRQICEKsJu5QJpWVwDX9lJ27tB3vBDpxVLiwph13pdSTge3zN;25:GySyvguBU4F8Drox50S83HyVy1+WBoFMBHxgwOQnUY9mAcGy/YO7Ubv1hVQOimomlgMkCRA/g1q5IC4L6bXAq27FH+WoRclZqX/Q1BmUX6v+52DG96s8iz2KG8z6rI9ebhAdxb4aYGcHVn2vFv/gsexwxwcVAondMuHtddQOmk11OJLvp3TwjoH2yvPTWrV80uTMEyfrSkoJ0K62kDMeBFJZNyUwxt6RJ/ZGmH8Jt1ZKhfdSk4LCj+uXIuIhR9bvJjLaQGDB8kp/wYM99z1EeBOsTw7XB/TrKb6frxUVBTJW2CgVRTzGqtv/GoSHqxB/;20:AKK67YONhB3kexzTEVOAngNPzLp1KrPN/EalkKM1uah5qZpbMp5ie1z3XeEvDsmPI1NJIki6UPIcy1ur5wFxM6C265nfIsUiBkkwldzm7ACtWANxJEn3XcaJ2DVuFcDaMU2hd9B4xopnZCw7yQew9qiwJt+JdFzeVHD+zs2dKyQ= X-DkimResult-Test: Passed X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(3001016);SRVR:CY1PR0301MB2025; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0301MB2025;4:8HntR3GYeVZBHis4hW+WialcJk8JAvYAKWo+7BcoU52pYTfwSeH7bZynj1Af6nHidM3mq5nFdzWiRdfQUVUkarz8A001BIWcV+SqQmJjrhnfytqHQrcgE+YJIqek3Ryn/N8aWIVCBn6AaUoA/Bqj9fPODdOAVzporOq/FOY2TgtP1q1dbprZe20G6jZgx+0B646Etgovd8Fx5QIxNxtiCWU+QQ70f8RADZeLIXxR6c7VeOR/MS/KXpCkqhw7NngorKfeAsA//UELl4lF2+xaD3Yk0xCf/qFDYf1VEaiHHhiu4LrcEAuZN26DWF2hIs+Ld+YwvZZc2H9R0griqFsKdQSlKhsiOOYcFk/TqBBZEl2ILRO42x4rDhAT0tvUoLpfaOzg5vepWwez+xTNBgdlUmftgNqH3XIm+mRU0uD5DzCrLDaHweL4CezJ/iU26F1KiZMbhmeJQglhwlZ6MYidXuhVal/vRIYJcmNVEbzNpt37L+RkBIFNxXqDDheb59Y4 X-Forefront-PRVS: 08497C3D99 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR0301MB2025;23:fecpEAwAT6V+ptRE1ATHEzXLeZ6oob10Ydwbs5m?= =?us-ascii?Q?4JhtbaHuaV8LX9t7arWPdVNOa177Dq7fE0kl4tWhbQrRR3gmNsqyBIkOpI3K?= =?us-ascii?Q?bJ1gNPIx+WxREi6knqDjtP3skbIF62Adrn+KIF8yyJJc1uX4DJDm2kdtFJxL?= =?us-ascii?Q?uJP8QSQKVAruvPN23j7lgWlFo0WlesR/ZNKBdgEh+yko/NrMhzpanLoB9m02?= =?us-ascii?Q?QdJ7oJ/dm9/zF8n6wWfY/9FWjiGMp6KJregoYQCksHNIYbubLHxgoBEX8UC6?= =?us-ascii?Q?/Rg0bmwUXUeKmKn79MnvAIsg9509DAN3/rZv4WmhBTJU12g0lDePJjf9SnjP?= =?us-ascii?Q?djuWpGWLDA/B0DFk/GoiwW6lnal3u16DOI7cDi8k2/djshYLy5AIAA6S7eq7?= =?us-ascii?Q?0rBxwM3YUg0YfN9JlBKr74Om+rsrZlSLosvnGQ4xapglMcl1A+XQIr2re4Aa?= =?us-ascii?Q?SUnFjcYamE5xL8CpBzUMUiT+iO4WHvmVEL9xIcCyKtqGXnuoxYg/MBQR6sa/?= =?us-ascii?Q?/OMigd+DdizYpigzFtWHNbTVr0Tg+ugmOkA1Y2RjYl4b6ino2zPWbAl+RkN1?= =?us-ascii?Q?SHSh2yP92v3uSWr8axWre9RA3SSxiBpRBGrkBsCLW8LV3F2d0St2IfNZjGxL?= =?us-ascii?Q?KCyVnH75ecaYJhRRtqA0dEqrDHh4iuUO70EbVdI2sOIr244ycCwmK8bHX2Ca?= =?us-ascii?Q?7vE5/kBV0MkkE5k9tCSv6YiTJUDgNfwoN/URZzj44CDhfH+eRRYQ/ZfcWr/M?= =?us-ascii?Q?vX46MnrroNuEbwI6c84d6PgYPgO6N+L9pnw11pG3JAP50u0hwI6HkvwykPox?= =?us-ascii?Q?73RLgzu2j5CA4x7riPfwCkvsALy+sOCI6qJoyDnT+un7xxIyAMCQFj/hlt23?= =?us-ascii?Q?6ABYPeCGWT5rb5nPGqrYx38uLiXXNQ//t6vcBYCVoCw03sUBn7MePYE6YSyz?= =?us-ascii?Q?ca/6Hvmeow9gOkOypnPzUTv6KjVecaN923d6q4qcuBthrZw9JyZUUER97+fT?= =?us-ascii?Q?YDLZSvsDF/IOs+U3kkjg7GEbs1f2PiinySTVRRJYekI00wP3bG0rqrOL3J7h?= =?us-ascii?Q?hdHErtRpxNkEQRLmGHtJWQDmEr9I/VGJ+/4Agb685FRA6zzMlCNKJcnqQ2zp?= =?us-ascii?Q?R0bB46B0K4ukstd94zKddUmSdRFfmmwJ0C/4HSqXJTBGVfV4WXXw8qGH3pXf?= =?us-ascii?Q?QR0+z96nwEcAuM0vwHEwVByh3TOJai2H/y3LXSC73VDf/wIefLs7fs8ZOtZu?= =?us-ascii?Q?eRucuN8VPCaMeLQi22qYoI/Q/NA0qpMA9md5u4yOjHBW6ujRVSyqj7zwNT8Y?= =?us-ascii?Q?NZ1HQHS2vRlvx6L0gd9lCJowNvywl3WF0QdssZnv3hEzZtTTs4dKuBq1J7A3?= =?us-ascii?Q?Px9NO/GiyPj0j5cbsmrCsGELyNRiBUIzbmwjYGsiEY23rSJctgeGpJur4JSF?= =?us-ascii?Q?8H4eXsUl03gV6hnMotKo9kCOfmiurJFEG8HyfVfqBzAR73kYPuJZo?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR0301MB2025;5:LfCRx0S08tFAb795KWaBHzcf4bPz5w9/BDNSizT/gUFPOF599BlJFk23CTTmj7hdouasg5MPnYD3DWB4udKPdWNLlo/9q/LX1gYXfTNifng5NWh+5lAyRvUOT4wQcq/AJbGAXWDm0Z6MGiMLy2bmdw==;24:QQLeoFpMCpqBokwIbEA+XLHd1JVaQ4vpidw04R0D4L4D+CtVDUI5SKl+w6sTtc3uFWr5j5zKYk0OH4wgdQKBYTAFwlOY9OAOUkBlULyrqBE=;20:56yEetpOdPUXR6HnScEDwke+FXWE63LxlzUn8iGqOEq5jeB4F6WJWJ5/TL0zY5hNhX1hQ4rQXY7+9j7HeKgfvhz2BEw0j4EQ/3aM3BpsIX+spxjBeZ2DduV+wvfqbEigPELE/weuBTj0oELJzZVcy5l9yy4bYQtnBSKBpzzyumw= X-OriginatorOrg: opensource.altera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2016 22:19:06.5095 (UTC) X-MS-Exchange-CrossTenant-Id: fbd72e03-d4a5-4110-adce-614d51f2077a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fbd72e03-d4a5-4110-adce-614d51f2077a;Ip=[66.35.236.236];Helo=[sj-itexedge04.altera.priv.altera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2025 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 11 Feb 2016, atull wrote: > On Thu, 11 Feb 2016, Rob Herring wrote: > > > On Thu, Feb 11, 2016 at 2:49 PM, atull wrote: > > > On Fri, 5 Feb 2016, atull@opensource.altera.com wrote: > > > > > >> From: Alan Tull > > >> > > >> v16 Refactors the FPGA Area and FPGA Bus into single thing called an > > >> FPGA Region and eliminates using simple-bus. I'm using the word > > >> "region" as it's a term is used in the literature of both the major > > >> FPGA manufacturors. > > >> > > >> Changes for v16: > > >> * Refactor the FPGA Area and FPGA Bus into a FPGA Region. > > >> * Don't use simple-bus. > > >> * FPGA Managers and FPGA Bridges are now specified by phandle using the > > >> "fpga-mgr" and "fpga-bridges" properties. fpga-bridges can specify > > >> more than one bridge. > > >> * Device Tree overlays should be targeted to a FPGA Region. > > >> * The overlays need only contain firmware-name and the child nodes. > > >> * To model a system containing >1 partial reconfiguration region, > > >> an overlay could add FPGA Regions to the base FPGA Regions. > > >> * Child FPGA Regions inherit the parent FGPA Manager, but specify > > >> their own set of bridges if needes as partial reconfig regions > > >> will likely need their own bridges. > > >> * All this is discussed in bindings/fpga/fpga-region.txt > > >> > > >> One other highlight: > > >> The little engine that runs this thing is a reconfig notifier > > >> in fpga-region.c. This notifier that will program an FPGA if a > > >> "firmware-name" property gets added to a fpga-region. Then > > >> it will call of_platform_populate(). The current behavior in Linux > > >> when a DT overlay is applied is that the reconfig notifications > > >> go out in heirarchical order: first notifications are for the > > >> properties, then notifications for the child nodes. So an overlay > > >> that adds a 'firmware-name' property and some child nodes to a > > >> fpga-region will cause FPGA programming and child node > > >> populating in the right order. > > > > > > I figured out how to get rid of the reconfig notifier. > > > > > >> > > >> One issue with the dynamic DT stuff: > > >> I've tried returning and error from the notifier if FPGA programming > > >> fails; the error is noted on the console, but the child nodes > > >> get probed anyway. > > > > > > I looked into it further and now I've got a solution for this issue > > > that I can post soon. I can stop using the DT overlay configfs > > > interface and add a sysfs file for applying an overlay to an FPGA > > > region. The FPGA region implementation will see the overlay before it > > > becomes part of the live tree. Then it can do the FPGA programming > > > and see that succeed before the child nodes become part of the live > > > tree. If FPGA programming fails, the overlay will be rejected before > > > it becomes part of the live tree. By the time 'firmware-name' and the > > > child nodes show up in the live tree, they will be post-configuration > > > information. > > > > Um, no. We don't need 2 interfaces for loading overlays from > > userspace. I could see this being a common problem and it needs to be > > solved. But given the configfs interface is not upstream yet, perhaps > > you should worry about that after the current series is in. > > > > Perhaps we need a pre-add notifier and the core will only load the > > overlay if nothing handles it. Really, a solution without notifiers > > would be preferred. Maybe register handlers with the DT core for > > certain paths. > > > > Rob > > > > Yes. If any handler returns error, the overlay doesn't go into the > main tree. Handler type to be registed could be: > > int pre_add_handler(struct device_node *overlay, > struct device_node *target) And a third parameter of some flags to indicate whether the overlay is being added or removed. > > That gives us the overlay after it's been unflattened and phandles > resolved and the node that it was targeted to. I was going to > need find_target_node() to be exported, but this avoids that. > > Registration could by compatible string, of match, or path. Path > would be too rigid in my case, I'd want to register for compatible > "fpga-region" > > Alan >