Re: FPGA programming driver architecture

["Hans J. Koch" <hjk@linutronix.de>]

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