RFC: kpc2000 driver naming
gregkh at linuxfoundation.org
Mon May 6 15:16:25 UTC 2019
On Mon, May 06, 2019 at 02:38:16PM +0000, Matt Sickler wrote:
> >-----Original Message-----
> >From: 'gregkh at linuxfoundation.org' <gregkh at linuxfoundation.org>
> >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
> 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,
More information about the devel