On Fri, Feb 05, 2016 at 04:44:46PM -0600, Josh Cartwright wrote: > Hey Alan- > > First off, thanks for all of your (and others') work on this. > > On Fri, Feb 05, 2016 at 03:29:58PM -0600, atull@xxxxxxxxxxxxxxxxxxxxx wrote: > > From: Alan Tull <atull@xxxxxxxxxxxxxxxxxxxxx> > > > > New bindings document for FPGA Region to support programming > > FPGA's under Device Tree control > > > > Signed-off-by: Alan Tull <atull@xxxxxxxxxxxxxxxxxxxxx> > > Signed-off-by: Moritz Fischer <moritz.fischer@xxxxxxxxx> > [..] > > --- > > .../devicetree/bindings/fpga/fpga-region.txt | 348 ++++++++++++++++++++ > > 1 file changed, 348 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt > > > > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt > > new file mode 100644 > > index 0000000..ccd7127 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > [..] > > +FPGA Manager & FPGA Manager Framework > > + * An FPGA Manager is a hardware block that programs an FPGA under the control > > + of a host processor. > > + * The FPGA Manager Framework provides drivers and functions to program an > > + FPGA. > > + > > +FPGA Bridge Framework > > + * Provides drivers and functions to control bridges that enable/disable > > + data to the FPGA. > > + * FPGA Bridges should be disabled while the FPGA is being programmed to > > + prevent spurious data on the bus. > > + * FPGA Bridges may not be needed in implementations where the FPGA Manager > > + handles this. > > It still seems strange for me architecturally for the FPGA Bridge to be > a first-class top-level concept in your architecture, as they are a > reflection of the SoC FPGA manager design. That is, I would expect the > bridges not to be associated with the FPGA Region, but with the FPGA > manager. > > Although, I will concede that you you've made it possible to not use > FPGA Bridges (like on Zynq where they aren't necessary), so maybe it > doesn't matter, just smells strangely. In general, DT models buses in the node hierarchy. To go from one bus to another, you need a bridge. Going from an onchip bus to an FPGA bus has to have some sort of bridge logic in between for isolation minimally. Zynq has to have something similar. Perhaps the bridge control is not part of the bridges themselves? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
