> > > > For the Zynq based product I am working on, we encourage the end user to > > create their own bitstreams to customize their application. So we need > > an easy way for the user to load a bitstream. cat foo.bin > /dev/xdevcfg > > works well for us. > > You probably don't care if this will be > cat foo.bin > /sys/fpga/fpga0/<whatever> > (for zynq case you can also run) > cat foo.bit > /sys/fpga/fpga0/<whatever> > > FYI: Current driver in xilinx repo supports bit format too. >
Michal, So your low level driver has a back door to avoid having to use the firmware class? I thought the point of this exercise was to have a framework with a unified interface. My original framework supported the interface you mention here. If we are going to have a framework, we should spec in in such a way that vendors won't be required to add back doors to their drivers in order to support the use cases they are interested in. If the firmware interface isn't going to work all the fpga use cases, then why upstream this patch? In that case we should go back to the original implementation and have a unified interface that supports cat'ing the bitstreams to /sys instead. My current opinion about the firmware class is that we can use it (and it is best to use existing interfaces), but it is not really suited for all the fpga use cases. The other thing the original fpga framework had was a transport layer. The intent was to eventually support the same driver (such as a bitbang driver) no matter what type of gpio lines it was attached to. It wasn't really necessary for the fpga manager that is bolted onto a soc, but it will be needed if you have an fpga that gets programmed from another fpga that is connected to a soc. Otherwise you have to write separate drivers depending on how the fpga is connected. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
