On Thu, Sep 02, 2010 at 03:17:52PM -0500, Kumar Gala wrote: > > On Sep 2, 2010, at 3:04 PM, Ira W. Snyder wrote: > > > Hello all, > > > > I've written several drivers for a custom board. The board is basically > > an mpc8349_mds board with some extra FPGAs for data processing. > > > > All of the drivers were written to interface with a custom system > > controller FPGA, which handles things like LED control, FPGA > > programming, and fast data dumping from the data processing FPGAs. > > > > I'd like to start pushing some of these drivers into mainline, but I > > don't know where to put them. I don't think drivers/ is appropriate: > > these are highly board specific. Does arch/powerpc/ have a recommended > > place for board-specific drivers? I was thinking about > > arch/powerpc/drivers/, however that doesn't exist. > > If we decide to put them under arch/powerpc I'd suggest > arch/powerpc/platform/83xx/BOARDNAME/ > > However I'm not sure I think this is a good idea. We specifically moved > drivers out of arch/ppc land so they would get proper review via the proper > subsystem maintainers. So if its truly unique / simple board drivers than > the location I suggested is probably fine. If its something that a subsystem > exists than I do think it should be down in the subsystem driver dir. >
Thanks for replying Kumar. These drivers are very board specific, though they are not all extremely simple. Two of the four are ~1200 lines each. Not huge, but not trivial either. To give you three example drivers: 1) Data processing FPGA access driver This driver provides a simple character device to userspace which exposes one function: mmap. With it, you can mmap the entire data processing FPGA memory window into your process. With this, I provide non-realtime FPGA control to userspace applications. 2) Data processing FPGA capture driver This driver provides a simple character device to userspace which supports one function: read. Internally, it maintains a list of buffers which hold capture data. When the FPGA's are processing data, they dump data at 64Hz (every 15.625ms). If the data is not copied off the chips before the next dump, data is lost. DMA is required to move the data volume off the FPGAs fast enough to keep timing. Therefore this really does need to be in-kernel. 3) Data processing FPGA programmer The system controller has a hardware controlled FPGA programmer. It is required to use this programmer to program a new configuration into the data processing FPGAs. Their programming sequence has timing requirements that can only be met in hardware. It requires that the FPGA bitfile is in DMA-capabable memory. I used a char device for this too: write the bitfile to the device (it is buffered in-kernel), then give it the ioctl() to program the FPGAs. AFAIK, there is nothing like this in the kernel at the moment. That's why I asked if there is a better place to put this. Thanks, Ira _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
