On Mon, May 06, 2019 at 02:38:16PM +0000, Matt Sickler wrote: > >-----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. Ok, keeping them separate is fine, just wanted to make sure, thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
