Messages in this thread | | | Date | Thu, 19 Sep 2013 12:03:39 +0200 | From | Pavel Machek <> | Subject | Re: [RFC PATCH] fpga: Introduce new fpga subsystem |
| |
Hi!
> > + Jason Gunthorpe > > Thanks, looks interesting, we could possibly use this interface if it > met our needs.. > > > On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote: > > > This new subsystem should unify all fpga drivers which > > > do the same things. Load configuration data to fpga > > > or another programmable logic through common interface. > > > It doesn't matter if it is MMIO device, gpio bitbanging, > > > etc. connection. The point is to have the same > > > inteface for these drivers. > > So, we have many years of in-field experience with this and this API > doesn't really match what we do. > > Here are the steps we perform, from userspace: ...
> - Ask kernel to place FPGA into reset and prepare for programming > * Kernel can return an error (eg FPGA failed to erase, etc) > * this is the PROG_N low -> DONE high, PROG_N high -> INIT_N high > sequencing on Xilinx chips > - Ask kernel to load a bitstream. > * Userspace locats the bitstream file to load, and the mmaps it. > * Userspace passes the entire file in a single write() call to the > kernel which streams it over the configuration bus > * The kernel can report an erro rhere (eg Xilinx can report CRC > error) > - Ask the kernel to verify that configuration is complete. > * On Xilinx this wait for done to go high > - Ask the kernel to release the configuration bus (tristate > all drivers) (or sometimes we have to drive the bus low, > it depends on the bitfile, user space knows what to do) > > It is very important that userspace know exactly which step fails > because the resolution is different. We use this in a manufacturing > setting, so failures are expected and need quick root cause > determination. > > You could probably address that need by very clearly defining a > variety of errno values for the various cases. However, it would be a > disaster if every driver did something a little different :|
Well, exact steps are a bit hw-specific, too. So, if anything, I'd suggest standartizing the errno values.
> Using request_firmware exclusively is not useful for us. We > format the bitfile with a header that contains our internal tracking > information. Sometimes we need to bitswap the bitfile. Our userspace > handles all of this and can pass a bitfile in memory to write().
Take a look at https://www.kernel.org/doc/Documentation/firmware_class/README . You can do processing at
4), userspace: - hotplug: cat appropriate_firmware_image > \ /sys/class/firmware/xxx/data
What is the specific reason request_firmware is unsuitable?
Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |