Re: parport_pc disables parallel port on unload.

Re: parport_pc disables parallel port on unload.

[Bodo Eggert]

Bill Unruh <unruh@physics.ubc.ca> wrote:

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

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

You can copy/paste the relevant parts from the parport_pc driver.

Re: parport_pc disables parallel port on unload.

[Bill Unruh]

On Wed, 24 Sep 2008, Bodo Eggert wrote:

> Bill Unruh <unruh@physics.ubc.ca> wrote:
>
>> 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.
>
>> 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.
>
> You can copy/paste the relevant parts from the parport_pc driver.

Of course, then, identifying the relevant parts becomes the problem, but
thank you.

>
>

-- 
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

parport_pc disables parallel port on unload.

[Bill Unruh]

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