From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756054AbbJ1SDJ (ORCPT ); Wed, 28 Oct 2015 14:03:09 -0400 Received: from skprod2.natinst.com ([130.164.80.23]:41108 "EHLO ni.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755652AbbJ1SDH (ORCPT ); Wed, 28 Oct 2015 14:03:07 -0400 Date: Wed, 28 Oct 2015 13:02:50 -0500 From: Josh Cartwright To: atull Cc: Moritz Fischer , Greg KH , Michal Simek , Michal Simek , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Jonathan Corbet , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Pantelis Antoniou , Alan Tull , "dinguyen@opensource.altera.com" Subject: Re: [PATCH v12 3/6] fpga: add simple-fpga-bus Message-ID: <20151028180250.GA14948@jcartwri.amer.corp.natinst.com> References: <1445983755-24007-1-git-send-email-atull@opensource.altera.com> <1445983755-24007-4-git-send-email-atull@opensource.altera.com> <20151028100714.GB7779@jcartwri.amer.corp.natinst.com> <20151028161859.GJ8245@jcartwri.amer.corp.natinst.com> <20151028175916.GK8245@jcartwri.amer.corp.natinst.com> MIME-Version: 1.0 In-Reply-To: <20151028175916.GK8245@jcartwri.amer.corp.natinst.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 10/28/2015 01:02:50 PM, Serialize by Router on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 10/28/2015 01:02:50 PM, Serialize complete at 10/28/2015 01:02:50 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-10-28_13:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 28, 2015 at 12:59:16PM -0500, Josh Cartwright wrote: > On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote: > > On Wed, 28 Oct 2015, Moritz Fischer wrote: > > > > > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright wrote: > > > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote: > > > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright wrote: > > > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote: > > > >> >> From: Alan Tull > > > >> >> > > > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the > > > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic > > > >> >> interface for reprogramming FPGAs that is Device Tree > > > >> >> Overlays-based. > > > >> > > > > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well? The > > > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at > > > >> > all, from what I can tell. > > > >> > > > >> For Zynq the zynq-fpga driver takes care of the level shifters on full > > > >> reconfiguration, > > > >> and doesn't for partial reconfiguration. Now depending on which parts > > > >> of the fabric > > > >> are partial reconfigured (say AXI masters), one might run into issues > > > >> with a setup like that. > > > >> > > > >> My first plan was to counter that by using zynq-reset to hold the > > > >> reset high during > > > >> reconfiguration of that part of the FPGA. > > > >> > > > >> I'm happy to rethink that part and maybe redo the level shifters and > > > >> resets together in a bridge > > > >> driver under devicetree control gives finer grained control. > > > > > > > > There is already a framework which is used to describe and manipulate > > > > level shifting/other IO properties, and that is pinctrl, and if we > > > > wanted to use an appropriate abstraction, I think pinctrl would be the > > > > best bet. > > > > > > Alright, I'll investigate that. Again, for the non-partial reconfig > > > case I'm happy > > > with the behavior as implemented, for the partial reconfig I just > > > haven't run into > > > issues with not dealing with the level shifters. > > > > Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework? > > I'm suggesting that for the set of operations/configuration states that > need to be managed _for the Zynq[1]_ during reprogramming, I think > pinctrl might be a good fit. > > But the pinctrl state activation would happen in the context of the zynq > fpga_mgr_ops write *grr*... in the context of the zynq's write_init(), and write_complete() callbacks. Josh