Messages in this thread | | | Date | Mon, 22 Sep 2008 18:10:38 -0700 (PDT) | From | Bill Unruh <> | Subject | parport_pc disables parallel port on unload. |
| |
I have a parallel port module gps.c which I have written ( after the short module described in Linux Device Drivers), whose purpose is to timestamp the occurance of interrupts on the parallel port Ack line to as high a temporal accuracy as possible.These are generated by the PPS line of a Gamin 18LVC gps receiver. Since I want the highest accuracy possible I do not want the latency of going through the stock drivers and waiting for a poll or select to let me know an interrupt has occured.
The problem I am running into is that the parport_pc driver, if it is unloaded, powers off the parallel port, making it useless for my purposes (or at least I do not know how to power it up again). Now I do not think that the parport driver should disable the port when it is unloaded, but rather leave it in the state it was in when the module was loaded, but the maintainer of parport_pc (alan@lxorguk.ukuu.org.uk) disagrees with me, and he is doing the maintaining, not me.
So, could anyone point me to some relatively comprehensible documentation ( or "canned program") to show me how to switch the parallel port back on if unloading parport_pc has switched it off. I assume it can be switched on again. Alternatively, how to tell parport_pc to release the registers of the parallel port so I can run my module even if parport_pc is loaded. (that of course sounds dangerous and could lead to contention) Having the interrupt be processed first by parport_pc and then by my userland program sounds like a recipie for long and variable latency (I am talking in terms of usec). (Mind you I hae not measured it but the direct interrupt is of the order of 1usec).
If parport_pc is not loaded first, then my program runs fine. And the clock discipline and scatter using ntp is of the order of 2usec, and I suspect much of that is ntp's relatively poor clock discipline algorithm (in comparison with the best possible) rather than problems with latency in the clock reading.
Thanks Bill
| |