On Wed, Oct 28, 2015 at 11:18 AM, Josh Cartwright <joshc@xxxxxx> 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 <joshc@xxxxxx> wrote: >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@xxxxxxxxxxxxxxxxxxxxx wrote: >> >> From: Alan Tull <atull@xxxxxxxxxxxxxxxxxxxxx> >> >> >> >> 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. I'm not all that familiar with FPGAs, but using pinctrl seems like overkill to me. We're talking about isolating things while doing reconfiguration, right? That seems more similar to power domain controls than I/O pin control to me. > Implementing the FPGA Bridge interface in the Zynq driver because it's > what the core expects is just backwards. It's an abstraction inversion. +1 Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
