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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
