lkml.org 
[lkml]   [2013]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH] fpga: Introduce new fpga subsystem
    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


    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2013-09-25 13:01    [W:4.691 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site