Where to put board-specific drivers

Where to put board-specific drivers

[Ira W. Snyder]

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.

Thanks,
Ira

Re: Where to put board-specific drivers

[Kumar Gala]

On Sep 2, 2010, at 3:04 PM, Ira W. Snyder wrote:

> Hello all,
>=20
> I've written several drivers for a custom board. The board is =
basically
> an mpc8349_mds board with some extra FPGAs for data processing.
>=20
> 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.
>=20
> 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.

- k=

Re: Where to put board-specific drivers

[Ira W. Snyder]

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

Re: Where to put board-specific drivers

[Sean MacLennan]

On Thu, 2 Sep 2010 13:04:34 -0700
"Ira W. Snyder" <iws@ovro.caltech.edu> 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.

Drivers should go in the proper place if it all possible. For example,
for Pika's warp, the watchdog driver is in the watchdog directory
(drivers/watchdog/pika_wdt.c) even though it is FPGA based and very
specific to the warp.

However, the LEDS where put in arch/powerpc/platforms/44x/warp.c. So it
is in the platform code. I also put our FPGA based DTM (Dynamic Thermal
Management) in the warp.c file.

If you submit the code... the reviewers will make recommendations on
where it should go.

Cheers,
   Sean

Cheers,
   Sean

Re: Where to put board-specific drivers

[Sean MacLennan]

On Thu, 2 Sep 2010 14:12:22 -0700
"Ira W. Snyder" <iws@ovro.caltech.edu> wrote:


> 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.

Could these drivers be merged?


Cheers,
   Sean

Re: Where to put board-specific drivers

[Ira W. Snyder]

On Thu, Sep 02, 2010 at 05:24:34PM -0400, Sean MacLennan wrote:
> On Thu, 2 Sep 2010 14:12:22 -0700
> "Ira W. Snyder" <iws@ovro.caltech.edu> wrote:
> 
> 
> > 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.
> 
> Could these drivers be merged?
> 

I would like to get them merged if possible. I talked with GregKH
several months ago, and he suggested that I should be able to get them
merged, even if I am the only user. They provide a good incentive to get
others who maintain similar drivers out-of-tree to get them merged as
well.

I'll post up the code shortly and let the reviewers tear me to shreds. :)

Thanks for the input,
Ira