On Thu, 23 Jul 2015, Jason Gunthorpe wrote: > On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote: > > Hi Alan, > > > > I saw that your socfpga driver doesn't support the partial reconfig > > use case (not a big deal). > > What I currently do for Zynq is if I'm doing a non-partial reconfig is > > that I disable input > > level shifters and assert *all* resets while reprogramming in my FPGA > > manager .write_init() and .write_complete(). > > I do this as well, but it is a bit more complex.. FPGA specific code > has to run around and ensure all DMA is shut off, then we need to make > sure no CPU issued AXI transactions can happen, then we can tear down > the FPGA side. > > If the FPGA is torn down while an AXI op is inprogress things go > sideways, we have to work to prevent that :) > > This happens almost for free, I use DT and the device model to > disconnect the drivers. The drivers are careful to synchronously fence > off in-progress DMA. Then drop the DT nodes associated with the > FPGA, finally the actual FPGA cells can be reset. Yes, the kernel gives us this almost for free. That's what I like about using DT overlays to control FPGA programming. > > > In a partial reconfiguration situation, would I have separate > > simple-fpga buses for each of the parts that I swap out, each with > > it's own reset and bitfile attached? > > I'd think of partial reconfiguration as another nested FPGA. The > resets and so forth could be attached to soft controllers in the > unswappable part of the FPGA. > > DT nodes have to surround it in some way... > > Jason > Yes, in this way each PR chunk will need its own reset so it won't wiggle busses and affect the rest of the system during PR. I noticed that currently simple-fpga-bus.c holds an exclusive ref of the fpga manager. This would keep a 2nd pr from being able to access the same fpga manager, so I'll have to change it so that simple-fpga-bus.c will put the ref before exiting probe. Alan -- 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
