From: Florian Fainelli <florian@openwrt.org>
To: Hugo Villeneuve <hugo@hugovil.com>
Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org
Subject: Re: FPGA programming driver architecture
Date: Sat, 13 Dec 2008 13:58:01 +0100 [thread overview]
Message-ID: <200812131358.03010.florian@openwrt.org> (raw)
In-Reply-To: <20081212150314.6ea24996.hugo@hugovil.com>
(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
-------------------------------
next prev parent reply other threads:[~2008-12-13 13:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 20:03 FPGA programming driver architecture Hugo Villeneuve
2008-12-13 12:58 ` Florian Fainelli [this message]
2008-12-15 18:16 ` Hugo Villeneuve
2009-01-08 20:18 ` Hugo Villeneuve
2009-01-08 22:14 ` Thiago Galesi
2009-01-08 22:47 ` Leon Woestenberg
2009-01-08 22:57 ` Florian Fainelli
2009-01-08 23:07 ` Leon Woestenberg
2009-01-09 3:14 ` Duane Ellis
2009-01-09 12:24 ` Alexander Clouter
2009-01-09 15:07 ` Hugo Villeneuve
2009-01-09 23:40 ` Hans J. Koch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812131358.03010.florian@openwrt.org \
--to=florian@openwrt.org \
--cc=hugo@hugovil.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox