On Fri, 2013-10-04 at 19:44 +0200, Michal Simek wrote: > On 10/04/2013 06:46 PM, H. Peter Anvin wrote: > > On 10/04/2013 07:28 AM, Michal Simek wrote: > >> On 10/04/2013 04:21 PM, H. Peter Anvin wrote: > >>> Yes; I never got too corner Greg ;) > >>> > >>> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >>>> On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote: > >>>>> But anyway what was resolution from that meeting? > >>>> > >>>> It never happened, we got distracted by lunch :) > >> > >> Then why not to have it here? > >> > > > > The essential question is if the firmware interface really is > > appropriate for FPGAs. It definitely has a feel of a "square peg in a > > round hole", especially when you consider the myriad ways FPGAs can be > > configured (some persistent, some not, some which takes effect now, > > some which come later, some which involve bytecode interpreters...) > > and considering reconfiguration and partial reconfiguration. > > If you look at it in general I believe that there is wide range > of applications which just contain one bitstream per fpga and the bitstream is replaced > by newer version in upgrade. For them firmware interface should be pretty useful. > Just setup firmware name with bitstream and it will be automatically loaded in > startup phase. > > Then there is another set of applications especially in connection to partial reconfiguration > where this can be done statically by pregenerated partial bitstreams > or automatically generated on target cpu. For doing everything on the target > firmware interface is not the best because everything can be handled by user application > and it is easier just to push this bitstream to do device and not to save it > to the fs. > > I think the question here is if this subsystem could have several interfaces. > For example Alan is asking for adding char support. > Does it even make sense to have more interfaces with the same backend driver? Just for clarification, I'm asking for just one way to write the fpga image data, not two or three. I like being able to directly write the fpga image buffer from userspace; that will support the superset of use cases. v2 accepts the binary image data from a sysfs attribute (cat image.bin > /sys/class/fpga_manager/fpga0/fpga_config_data). My original fpga manager framework allowed writing the image data to the device node (cat image.bin > /dev/fpga0) rather than sysfs. My point is that it that if you are writing data, that goes to the file ops, not to sysfs attributes. sysfs is for text communication (Documentation/sysfs.txt: "Attributes should be ASCII text files...") > When this is answered then we can talk which one make sense to have. > In v2 is sysfs and firmware one. Adding char is also easy to do. Please, not three ways to do the same thing. If you change from having the fpga_config_data attribute to having a file_operations' write, that would be what I think is more standard for char drivers in the kernel, if I'm not mistaken. > > Thanks, > Michal > -- 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
