On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote: > On 10/04/2013 10:44 AM, Michal Simek wrote: > > > > 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? 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. > > > > Greg, what do you think? > > I agree that the firmware interface makes sense when the use of the > FPGA is an implementation detail in a fixed hardware configuration, > but that is a fairly restricted use case all things considered. Ideally I thought this would be just like "firmware", you dump the file to the FPGA, it validates it and away you go with a new image running in the chip. But, it sounds like this is much more complicated, so much so that configfs might be the correct interface for it, as you can do lots of things there, and it is very flexible (some say too flexible...) A char device, with a zillion different custom ioctls is also a way to do it, but one that I really want to avoid as that gets messy really quickly. thanks, greg k-h -- 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
