Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 4 May 2018 12:20:19 -0700

On 05/04/2018 05:07 AM, Jörn Dreyer wrote:
> I am currently working on a driver for a PCI card. To access this card I have 
> writen a small uio kernel driver for Linux based on the concept from mrfio2. 

Did you see the 'uio_pci_generic' driver which comes with Linux, and my
'pci_generic_msi' variant in devlib2?

> In the asynDriver that I'm working on I use devlib2 to get access to the 
> mapped memory regions of the card following the concept of evrMrmApp from 
> mrfio2.  In mrfCommon a lot of macros (BITSET, BITCLR, READS and WRITE for 
> various bitwidth) are defined. 

Which ones would you find useful?  I didn't port them over because, in hindsight
I'm not sure they were so helpful to me.

The original goal was to prevent unintentional access with an incorrect width.
eg. Using a 32-bit read of a 16-bit register.  In practice with mrfioc2
this was a waste.  Due to the strict recipe needed to work with both vme and pci,
only 32-bit reads could be used.

Also in hindsight, the BITSET/CLR read-modify-write macros are a recipe for
race conditions if used without preventing concurrent access (eg. interrupt
disable or mutex).  This convenience was a little too convenient.

> Should these macros not be part of devlib2? This way other modules could 
> profit from this work much easier. Pulling these files into my project would 
> require to install the mrfio2 module even if I do not have the hardware. Not 
> thinking about license conflicts that might arise if I copy the code over to 
> my project.

mrfioc2 uses the same EPICS open license as devlib2, and Base itself.  So I
don't think that this aspect will make your life more complicated than it
already is (if you're thinking about licensing).

> Regards,
> Jörn Dreyer
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System