You’ve convinced me, now tell me what QSSL uses in their drivers?
With the exception of the serial drivers, IST.
As the original poster, I should update and let people know that my driver is working, and it was done by using some ISR code to access the MSR’s.
I concur with several who commented, and I agree that requiring a driver to access MSR’s in order to control a device is a bad hardware design. But that’s the way the CS5536 device from AMD operates, so that’s what I had to do. Fortunately, there are only two access that have to be done, and these are only at initialization time. There is one MSR read to determine the base I/O address of the device, and there is one MSR write to indicate what we want to happen when the timer expires (RESET/NMI/IRQx/etc.). After these two MSR operations, everything else operates in I/O space.
Since the RDMSR and WRMSR instructions are not time criticial, I just hooked an ISR into the QNX timer, and passed the ISR a pointer to some memory that had the MSR location/value pair, as well as a flag used to indicate that the operation was complete. As soon as the operation completed, I detached the ISR.
Thanks for the update. I am wondering why it wasn’t possible to do these two operations in the startup code?
Putting these two operations into startup code was considered. However, we are building a Class III medical device, and have extremely rigorous verification and validation requirements. These requirements are less intensive for COTS software components, so it is in our best interest to leave the BSP/startup code alone.
Ahhh, so you don’t want to open up the startup code to the full-blown whitebox testing. I’ve worked on a Class III medical device myself, so I am very familiar with the V&V requirements.
Of course, if you place some code in an interrupt handler you have modified the runtime image of the kernel. OTOH, that code should be small enough to be provably correct.