Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Tue, 8 Sep 2009 15:48:27 -0400

In anticipation of doing some work with the MRF timing system hardware I have been considering ways to extend devLib.

The Micro Research Finley devices come in several form factors (VME64x, cPCI, PMC).
The mrfEventSystem IOC [1] implements this on top of (and along side) devLib,
but it would make more sense to add this functionality to devLib.

I am thinking about the API and would appreciate any comments.
If anyone is curious I have started to implement some of this [2].

VME64 CSR/CR
------------

All that is needed here is a uniform way to do probing.
This can be implemented on top of the existing api without adding calls to the 'virtual os' table.

------------------------------------------
struct VMECSRDevice {
	epicsUInt32 vendor,board,revision;
};
#define VMECSRANY 0xFfffFfff

epicsShareFunc int devSearchVMECSR(
	const struct VMECSRDevice* devs,
	int startdev,
	struct VMECSRDevice* info
);

#define devVMECSRBase(slot) ( (slot)<<19 )
------------------------------------------

A driver would pass a NULL terminated list of device ids into devSearchVMECSR().
Entries in this list can contain the wildcard (VMECSRANY) so the actual match is written to the last argument ('info').
The return value is the slot number (0-31) (or -1 on error).
Note that VME slot 0 is CSR slot 1.
CSR slot 0 is the 'default' when the crate does not have the geographic address lines.

The VME base address for this slot can be found with the devVMECSRBase() macro.
>From this the driver can manipulate any device specific registers in the CSR space.

PCI
---

Adding PCI support is more involved since there is less to build on.

------------------------------------------
typedef struct {
  epicsUInt16 device, vendor;
  epicsUInt32 sub_device, sub_vendor;
  epicsUInt32 pci_class;
  epicsUInt16 revision;
} epicsPCIID;
#define DEVPCI_ANY_SUBDEVICE 0x10000
#define DEVPCI_ANY_SUBVENDOR 0x10000
#define DEVPCI_ANY_CLASS 0x1000000
#define DEVPCI_ANY_REVISION 0x100
------------------------------------------

Again devices would be matched from a list with wildcards for some fields.
The reason for not having wildcards for device and vendor stems from RTEMS, and wanting to use the api in (rtems/pci.h) only.  Specifically that the pci_find_device() call does not allow wildcards for device or vendor.  This could of course be dealt with, but I'm not sure it is worth the trouble.

------------------------------------------
struct PCIBar {
  volatile void *base;
  epicsUInt32 len;
  unsigned int ioport:1; /* 0 memory, 1 I/O */
  unsigned int addr64:1; /* 0 32 bit, 1 64 bit */
  unsigned int below1M:1; /* 0 Normal, 1 Must be mapped below 1M */
};

typedef struct {
  epicsPCIID   id;
  unsigned int bus;
  unsigned int device;
  unsigned int function;
  struct PCIBar bar[6];
  volatile void *erom;
  epicsUInt8 irq;
} epicsPCIDevice;
------------------------------------------

Some structures to hold information about a single device.

------------------------------------------
epicsShareFunc
int devPCIFind(
     const epicsPCIID *idlist,
         unsigned int  instance,
const epicsPCIDevice **found
);
------------------------------------------

A similar search function.
'found' is constant so that one copy can be returned to all callers.

------------------------------------------
epicsShareFunc
int
devPCIToLocalAddr(
  const epicsPCIDevice *idlist,
          unsigned int  bar,
        volatile void **ppLocalAddr
);
------------------------------------------

This function may not be necessary.
It is intended as a hook for any OS initialization before a region is accessed.

I would also change the existing PCI interrupt functions to take a 'const epicsPCIDevice*'
instead the BDF triple.

[1] http://epics.svn.sourceforge.net/viewvc/epics/applications/trunk/mrfEventSystem/

[2] http://pubweb.bnl.gov/users/mdavidsaver/www/files/vmecsr-b.tar.gz

The VME64 part has had some testing, but the PCI part has not.
Only devpciApp requires 3.14.11, vmecsrApp compiles against 3.14.10.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System