All of lore.kernel.org
 help / color / mirror / Atom feed
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
-------------------------------

  reply	other threads:[~2008-12-13 12:58 UTC|newest]

Thread overview: 13+ 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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.