On Tue, Oct 08, 2013 at 12:00:14PM -0500, Alan Tull wrote: > On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote: > > 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. > > Hi Greg, > > We are discussing a char device that has very few interfaces: > - a way of writing the image to fpga > - a way of getting fpga manager status > - a way of setting fpga manager state > > This all looks like standard char driver interface to me. Writing the > image could be writing to the devnode (cat image.bin > /dev/fpga0). The > status stuff would be sysfs attributes. All normal stuff any char > driver in the kernel would do. Why not just go with that? Because we really hate to add new ioctls to the kernel if at all possible. Using sysfs (and it's one-value-per-file rule), makes userspace tools easier, and managing the different devices in the system easier (you know _exactly_ which device you are talking to, you don't have to guess based on minor number). 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
