>-----Original Message----- >From: 'gregkh@xxxxxxxxxxxxxxxxxxx' <gregkh@xxxxxxxxxxxxxxxxxxx> >On Sun, May 05, 2019 at 10:14:17PM +0000, Matt Sickler wrote: >> The I2C and SPI drivers don't depend on anything other than the I2C >> and SPI subsystems. Actually, they might be depending on the kp2000 >> driver having the PCIe registers mapped into kernel space instead of doing >> that themselves. >> I'm not sure if that's the correct thing to do or not, so that might >> be something to look closely at with all these drivers. > >Are all of these drivers needed for this hardware to work? Should they even >be separate drivers or should they all be mushed into one? Can anyone do >anything useful with just one of them? > >> Yes, all 4 drivers are required for proper functioning of the card. >> SPI is used to reprogram the flash chips that store the FPGA >> bitstream. I2C is used for monitoring and programming clock >> generators. DMA is required for some parts of other cores. > >So should we just merge this into one driver at link time? That would make >more sense, right? Yes. All the drivers are required for the hardware to work. In some sense, they "could" be used independently, but most likely only within Daktronics hardware. I guess if someone else had an FPGA design that needed a SPI controller, they could reuse our driver as long as their FPGA implemented a compatible SPI controller. One thing I would be concerned with would be future FPGA designs that need to mix-and-match. For example (using new names), today we have the P2K card which uses the dak-p2k main driver, and dak-i2c, dak-spi, and dak-dma "sub-drivers". Perhaps the next generation hardware would need to use a new dak-p3k main driver but can reuse the dak-i2c and dak-dma sub-drivers. And maybe it needs a new dak-spi-v2 driver (because something in the hardware changed in an incompatible way). This is all hypothetical though - it could range from complete driver reuse to needing all new drivers for everything - we won't know for sure until the new hardware designs ramp up in the next 6-12 months. If there's a way to do link-time trickery to get all 4 drivers compiled into one .ko, I'd be fine with that. I do think it's a good idea to keep them at least slightly separated to facilitate that mix-and-match scenario as well as just ease of maintaining the code. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel