On Fri, Jan 09, 2009 at 10:07:25AM -0500, Hugo Villeneuve wrote: > > I think that for the moment, I will focus on implementing the core > module and the parallel/SPI interfaces only. Later we may want to add > more fonctionality (vendors, JTAG, etc). That's a good plan, but you'll have to make sure different FPGA programming drivers can be added easily to some fpga-core no matter which interface they use. > > But for now, my main problem is that I need to have some insight on how > I actually implement the different modules: > > Bus driver? > class driver? > platform driver? Those are not mutually exclusive. If you register an spi driver, it'll appear on that bus. It would be a good idea to also create a class "fpga". And an FPGA will likely be a platform device unless you create a complete subsystem that offers something like register_fpga_device(). The latter would be a nice thing to have, I had to write FPGA programming drivers and had to implement them as some char device in drivers/misc because there was no place where they could go... IMHO, the ideal solution would be to have an FPGA programming subsystem. Somewhere in my board support I'd setup some struct fpga_device that contains an element "bus_type" which can be set to FPGA_BUS_PARALLEL or FPGA_BUS_SPI or whatever. A "name" element declares which driver I'd like to use for my chip. A call to some fpga_register_device() with a pointer to that struct would make the fpga subsystem remember that device and look for an apropriate driver. Drivers register themselves by a call to some register_fpga_driver() function. The fpga core would then make sure the drivers probe function is called with pointers to the struct fpga_device of the registered devices. That's how other subsystems work. Such a subsystem would solve any FPGA programming problems (and your "main problem" mentioned above) once and for all. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
