Hi! > > * this causes the fpga to get programmed > > * appropriate bridges get enabled > > * appropriate drivers get probed > > For the case of a fixed function device it's sort of equivalent to a > firmware load (in fact it *is* just a firmware load). The fixed function > cases don't actually even need a 'firmware manager' or an FPGA class. In > fact they shouldn't IMHO have one because the fact version A of the > device requires firmware bitstream X, and bitstream X is an altera FPGA > bitstream is an implementation detail. Revision B could be a > microcontroller or something else and you still just shove a bitstream > down it. No FPGA class is needed or appropriate. FPGA loader helpers > yes. Well, you'd still like to use the FGPA class to talk to the FPGA loader, because that makes transition to different FPGA vendor easier, right? > 1. Fixed function firmware - in which case the driver already handles it > and we don't care if its FPGA bitstreams or microcode or CPU code or > whatever > > 2. Dynamic use cases where we need a resource we own, which means > enumerate/open/close/read/write interfaces including firmware. > > For use case #1 I don't believe we need magic classes for FPGA and in > fact they are actually a mistake, Why? Bitstream upload code is fairly complex, and it seems the high level steps are similar between vendors. Having FPGA class people can work with helps, and it will help in future more dynamic cases, too... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
