Hello,
Recently Greg KH posted the first set of drivers for our PCIe device (kpc2000)
and shortly after that I posted the kpc2000_dma driver. I was wondering about
naming / structure standards in the Linux kernel.
First, a real quick background on these devices: Daktronics makes a PCIe card
with an FPGA on it to drive our LED displays (and other processing tasks).
Inside the FPGA, we use something similar to AXI-4 to divide the PCIe BAR
register space [1] into separate "IP cores". The kpc2000 driver is responsible
for probing the PCIe device, doing some basic setup (mapping the BAR, setting
up an IRQ, PCIe configuration, etc) and then enumerating these "cores".
Enumeration of the cores is facilitated by the "board info" core that is always
at the beginning of the BAR and has a defined format. Most of the cores are
controlled entirely by userspace - the driver will add a UIO sub device for
each one which userspace uses to control FPGA registers. Only 3 core types
are handled by drivers: DMA, I2C, SPI. These are IP cores inside the FPGA that
(in the case of i2c and spi) interact with other physical devices on the PCIe
card.
Currently, we only have the one PCIe device (the "P2K" card) but we have more
on our roadmap (one we've been calling "p3k" internally). I'm 99% confident
that the I2C and SPI cores will be exactly the same on the new FPGA design.
I'm 80% confident that the DMA engines themselves will be exactly the same on
the new FPGA design. The next card PCIe driver will quite likely be separate
from the kpc2000 driver because how bitstreams are stored / loaded / configured
is changing due to using a newer FPGA. There will likely be common code
between the two.
Now on to my actual questions: Once the drivers are "good enough" to be moved
outside of staging, I'm wondering where the drivers will end up and what their
names will/should be.
Since the I2C and SPI drivers are single-file, I'm guessing they're going to
move to drivers/i2c/busses/i2c-dak/ and drivers/spi/spi-dak/, respectively. I
tweaked the names, since "i2c-dak" and "spi-dak" make more sense to me than
"kpc_i2c" and "kpc_spi".
So that leaves the DMA and main PCIe drivers. Where do those end up in the
tree? Would "dak-dma" and "dak-p2k" (and eventually "dak-p3k") make more
sense as names for those drivers?
The final question relates to how Kconfig entries are setup. The I2C, SPI,
and DMA drivers could be "selected" on their own (even if the "dak-p2k" and
"dak-p3k" drivers aren't selected), but that doesn't make much sense because
they'd never get used in that configuration. Conversely, if you select the
"dak-p2k" driver, the I2C, SPI, and DMA drivers better get selected too,
otherwise the device won't function correctly. From what I can tell with
Kconfig, if A depends on B, you can't even see (let alone select) A without
already selecting B.
Right now, the Kconfig entries are setup like this (using the current names,
not the new ones presented above):
KPC2000_DMA depends on KPC2000 (this compiles the kpc2000_dma driver)
KPC2000_I2C depends on KPC2000 && I2C (this compiles the kpc2000_i2c
driver)
KPC2000_SPI depends on KPC2000 && SPI (this compiles the kpc2000_spi
driver)
KPC2000_CORE depends on KPC2000
KPC2000 depends on PCI (this compiles the kpc2000 driver)
Greg, what is the purpose of the KPC2000_CORE config option? Nothing (that I
see) depends on it, and it doesn't cause any code to get compiled.
I would have thought something like this makes more sense [2]:
KPC2000_DMA depends nothing
KPC2000_I2C depends on I2C
KPC2000_SPI depends on SPI
KPC2000 depends on PCI && KPC2000_DMA && KPC2000_I2C && KPC2000_SPI
Which way is "better"? Does it even matter which way it's setup?
[1] Technically, there are two BARs. The first one is primarily registers for
the DMA engines. The second one is dedicated to our IP cores.
[2] Using the new naming, and taking the p3k future into account:
DAK_DMA depends on nothing
DAK_I2C depends on I2C
DAK_SPI depends on SPI
DAK_P2K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI
DAK_P3K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI
Thanks,
Matt Sickler
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
