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.
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.
You really wouldn't want to load 6.5MB into kernel space!
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
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
