On Tuesday 04 December 2012, Eli Billauer wrote:
> I'm currently writing some documentation which will cover the API and
> also help reading the code, I hope. It takes some time...
>
> Until it's done, let's look at a usage example: Suppose that the FPGA's
> application is to receive a high-speed bitstream with time multiplexed
> data, demultiplex the bitstream into individual channel streams, and
> send each channel's data to the host. And let's say that there are 64
> channels in original bitstream. So the FPGA has now 64 independent
> sources of data.
>
> For that purpose, the Xillybus IP core (on the FPGA) is configured to
> create 64 pipes for FPGA to host communication. The names of these pipes
> (say, "chan00", "chan01", ...) are also stored in the FPGA.
>
> When the driver starts, it queries the FPGA for its Xillybus
> configuration, and creates 64 device nodes: /dev/xillybus_chan00,
> /dev/xillybus_chan01, ... /dev/xillybus_chan63.
>
> If the user wants to dump the data in channel 43 into a file, it's just:
>
> $ cat /dev/xillybus_chan43 > mydump.dat
>
> I hope this clarified things a bit.
>
> I can't see how the firmware interface would help here.
I think a lot of us (including Greg and me) were confused about
the purpose of the driver, since you did not include much documentation.
The request_firmware interface would be useful for loading a model
into the FPGA, but that doesn't seem to be what your driver is
concerned with. It's also a bit confusing because it doesn't appear
to be a "bus" in the Linux sense of being something that provides
an abstract interface between hardware and kernel device drivers.
Instead, you just have a user interface for those FPGA models that
don't need a kernel level driver themselves. This is something
that sits on a somewhat higher level -- if we want a generic FPGA
interface, this would not be directly connected to a PCI or AMBA
bus, but instead connect to an FPGA bus that still needs to be
invented.
In the user interface side that you provide seems to be on the
same interface level as the USB passthrough interface implemented
in drivers/usb/core/devio.c, which has a complex set of ioctls
but does serve a very similar purpose. Greg may want to comment
on whether that is actually a good interface or not, since I assume
he has some experience with how well it worked for USB.
My feeling for now is that we actually need both an in-kernel
interface and a user interface, with the complication that the
hardware should not care which of the two is used for a particular
instance. For the user interface, something that is purely read/write
based is really nice, though I wonder if using debugfs or sysfs
for this would be more appropriate than having lots of character
devices for a single piece of hardware.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
