On Wed, Dec 6, 2017 at 10:28 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Alan Tull >> Sent: 06 December 2017 15:30 >> On Wed, Dec 6, 2017 at 3:44 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: >> > From: Wu Hao >> >> Sent: 06 December 2017 05:30 >> > ... >> >> > Regarding file names, it seems like the files added to drivers/fpga >> >> > could be uniformly named dfl-*.[ch]. Some are fpga-dfl-*.[ch] while >> >> > other are currently dfl-*.[ch] currently. >> > >> > They don't even want to do into a drivers/fgpa directory. >> > Maybe drivers/dfl or drivers/dfl/intel >> >> It's plugged into the fpga framework in drivers/fpga. This patchset >> also handles reprogramming the fpga, not just the dfl style >> enumeration. But your points about this being not just for FPGA are >> interesting to me. Do you have a use for this that isn't >> FPGA-centric? > > That all just seems wrong to me. > If you've managed to invent some common code for reprogramming fpga > I'd have though it would be library functions. Why don't you familiarize yourself with the fpga framework before commenting on it? ;) > > The driver ought to sit somewhere related to its functionality. > > Our fpga loads from a serial EEPROM, the image is about 6.5MB. > We can rewrite it from userspace by mmap()ing part of one of the BARs > to access some very locally written (by me) VHDL that does most of > the required bit-banging for 32it word accesses. The fpga framework is intended to handle cases where the it is desired to reprogram the fpga a lot without having to reboot. It doesn't sound like that is your use case. > You really wouldn't want to load 6.5MB into kernel space! No, and there have been proposals, shot down so far regarding streaming firmware images a page at a time. > > We also had to solve the problem of 9 separate driver modules that > want to access different parts of the BARs. > I think we have 46 separate slaves in the fpgas BARs (most are in 1 BAR). > Some of these are common between different boards (or completely different > memory maps for the same board. > > I can imagine some generic method of having a 'board' driver for a > specific PCI-id that knows the BAR offsets of various functions so that > other sub-drivers could be loaded to access those functions. > But that is some kind of pseudo-bus not fpga specific in any way. > > David > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
