Experimental Physics and
Industrial Control System

Jörn Dreyer <[email protected]> · Mon, 07 May 2018 10:37:14 +0200

Hi Michael,

thanks for the response. 

Am Freitag, 4. Mai 2018, 21:20:19 CEST schrieb Michael Davidsaver:

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

Yes, I saw it. But It's not an option for me, as I'm going to setup a system 
that needs to be ready right after every reboot of the PC. The setup I'm 
working on should be as much automatic as possible, so even an inexperienced 
user can copy it. 

> 
> 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.
> 
In principle all of them. My device has 8, 16 and 32 bit registers.

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

That's true, so one would make the 8 and 16 bit function by an #ifdef 
construct invisible on VME systems.
> 
> 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.
> 
I don't know of a way to disable interrupts from userspace. So this functions 
would require an implementation of an iocl in the kernel driver. 
For my device I could use of course the PLX SDK as it is based on a PLX chip 
for the PCI Interface. Yes it still uses PCI not PCIe. :( It becomes hard to 
find a mainboard with such interface nowadays. But the use of the PlxSDK would 
complicate the installation more that I am willing to accept.

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

My worry was because some of the files (e.g. mrfIoOopsDef.h)  do not have the 
License reference header included, so the licensing is not clear. 

Regards,
Jörn Dreyer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System