Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Michal Simek <monstr@monstr.eu>]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

Hi,

On 09/25/2013 12:54 AM, H. Peter Anvin wrote:
> On 09/19/2013 03:08 AM, Pavel Machek wrote:
>>
>>> The firmware approach is interesting.  It might be less flexible
>>> compared with my original code (see link to git below) that this is
>>
>> On the other hand... that's the interface world wants, right? To most
>> users, fpga bitstream is just a firmware.
>>
> 
> No, not really.
> 
> The typical assumption with the firmware interface is that there is
> exactly one possible firmware for each device (possibly modulated by
> driver version, but still.)  This is blatantly not true for an FPGA in
> the most extreme way possible -- there are an almost infinite number of
> ways one can load an FPGA.

That's truth but on the other hand on target hw you probably have
well known bitstream which you want to load to the device and your
drivers exactly know based on board revision what firmware you want to load.

> However, I have to question the whole idea of an "FPGA subsystem" --
> there is an almost infinite number of ways to program an FPGA or FPGA
> programming device (which may even be a commodity flash with a
> microcontroller or CPLD, and may be shared with other devices), and it
> really doesn't make any inherent sense to lump them together.

That's exactly discussion what I would like to have about this concept
in general.
I can agree that there are number of ways how to program fpga/cpld and others.
I wouldn't say infinite number just because of users can choose really
custom options.
I would say there are some standard ways how to load bitstream to fpga/cpld.
The most of customers just use them and they can be described.

Currently I do more care about zynq devcfg driver for loading bitstream
to zynq PL and partially icap driver just because it is in the mainline.
But there are others way though gpio, etc. Altera has also their drivers
for doing this type of work.
If you look at current state in connection to the kernel then for example
hwicap just create char driver. zynq devcfg driver which we have in xilinx tree
just create another char driver. Altera (please guys correct me if I am wrong)
has one driver drivers/misc/altera-stapl in the kernel which is used by any pci
card which is working with firmware interface.
Then they have any fpga-bridge in their tree which create any new class
+ origin fpga-mgr which is I think for their socfpga programming.

In general all these drivers can just create whatever user interface
they like and just start to pushing these drivers to the mainline
to char or misc folders.
But IMHO all of them just do the same program fpga/cpld trough particular
interface but why not just to have fpga core driver just to unify
this user access.

When we have agreement on this another valid discussion is
if firmware interface is OK for this purpose or NOT. Or if make sense
to create different interface or have all of them.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]