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:

quoted

On Wed, 28 Oct 2015, Moritz Fischer wrote:

quoted

On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright [off-list ref] wrote:

quoted

On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:

quoted

On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright [off-list ref] wrote:

quoted

On Tue, Oct 27, 2015 at 05:09:12PM -0500, atull@opensource.altera.com wrote:

quoted

From: Alan Tull <redacted>

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