This just appeared on linux-embedded list. Very relevant to us. If anyone has any comments about how it should work from balloon's POV then now is the time to say. ----- Forwarded message from Florian Fainelli ----- From: Florian Fainelli Date: Sat, 13 Dec 2008 13:58:01 +0100 To: Hugo Villeneuve Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org Subject: Re: FPGA programming driver architecture List-ID: X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3, No (CC'ing linux-embedded) Salut Hugo, Le Friday 12 December 2008 21:03:14 Hugo Villeneuve, vous avez écrit : > Hi, > I have written some code to program a FPGA in Linux, for two different > types of boards: one uses a serial interface (SPI) and the second a > parallel interface. I have been able to sucessfully program both boards. > I'm now trying to clean my code and make it more generic, as well as better > in line with the Linux driver model. I would also like to include it in the > mainline kernel if there is interest. Is it a platform-driver ? What do you provide in platform_data ? > > Here is a description of the current architecture (refer to diagrams > below): The fpgaload module controls one output GPIOs (PROG), and two input > GPIOs (INIT and DONE). These GPIOs are specified in board setup code. Both > fpgaload_ser and fpgaload_par modules export a single function to write a > byte. The fpgaload driver is a char device to which we can write > (/dev/fpgaload) to program a bitstream (FPGA firmware) inside the FPGA. You should probably consider using request_firmware to load the bitstream from the userspace and possibly add a /sys interface to export some attributes like : - GPIOs being used between the host and the FPGA - status (i.e : programmed, not programmed ...) - FPGA vendor, type ... > The > fpgaload driver will toggle the GPIOs to initiate programming and the then > call the corresponding write_byte function based on the interface type > specified in board setup code (serial or parallel, or any future interface > desired). > The problem with that approach is that when loading the fpgaload module > with modprobe, it will automatically try to load the fpgaload_ser and > fpgaload_par modules, even if only serial interface was specified in board > setup code for example. This is not good when building a kernel for similar > but different boards. What about something like that : - fpgaload-core which contains all the code that can be shared between the drivers like requesting firmware, providing sysfs attributes, - fpgaload-spi would handle the low-level SPI connection - fpgaload-par would handle the low-level parallel connection fpgaload-ser and par would register with fpgaload-core and they could register a fpga loading callback which is low-level specific for instance. Platform code would instantiate the core driver. That way, adding support for other loading protocols like slave serial or master serial can be done easily. > > Probably a better approach would be for the fpgaload_Ser and fpgaload_par > modules to register themselves with the fpgaload module. Then, should the > fpgaload module be built using a BUS driver structure? Or anyone having any > suggestions on how it should be implemented? -- Best regards, Florian Fainelli Email : florian@openwrt.org http://openwrt.org ------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ----- End forwarded message ----- Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/