Re: [PARPORT] Questions with ppdev

From: Tim Waugh (twaugh@redhat.com)
Date: Thu Mar 15 2001 - 04:46:34 EST

  • Next message: Michael Reinelt: "Re: [PARPORT] Questions with ppdev"

    On Thu, Mar 15, 2001 at 08:45:35AM +0100, Michael Reinelt wrote:

    > First, I found that the ioctl(PPEXCL) didn't work. I discovered that the
    > reason is lp.o, which seems to have the port open, too. It works if I
    > load lp.o with the parameter 'parport=1,none'. If I don't have exclusive
    > access to the port, can this lead to problems?

    Drivers can be in user space (via ppdev) and in kernel space. Only
    one PPEXCL driver is allowed per port. You couldn't be that driver
    because lp had already registered (non-PPEXCL) for that port.

    Not having exclusive access just means that another driver might
    possibly try talking to (another device on) the port. This is only
    really an issue for devices that won't work in daisy-chain
    configurations, even as the last device on the chain. In particular,
    if your device is going to be claiming the port and not releasing it
    for large amounts of time (thirty seconds, a minute, minutes, etc), it
    should probably claim the port exclusively.

    > Another thing I really don't understand is the autoloading of
    > parport_pc.o. If I do a 'modprobe ppdev', it loads parport.o and
    > ppdev.o, but not parport_pc.o (I'm using devfs, and I have an entry
    > 'alias /dev/parport* ppdev'). I should name parport_pc.o somewhere, but
    > where and how?

    You should alias 'parport_lowlevel' to parport_pc in modules.conf.
    When your driver opens the ppdev port, 'parport_lowlevel' will get
    loaded.

    > Testing this stuff is really annoying because I cannt unload lp.o. Even
    > if nobody uses a parallel port (lpd ist not running), I get the
    > following usage:
    >
    > lsmod:
    > lp 5456 1
    > parport_pc 23072 1

    Did you enable 'PARPORT_LP_CONSOLE' when you configured your kernel?
    If so, lp can't be unloaded.

    > I don't like c) because it's non-portable and not available on older
    > cpu's

    select() is portable, but you don't get a guaranteed maximum delay.

    > Maybe ppdev should provide an interface to the kernel udelay()
    > function?

    Not sure. I'd rather not. Anyone else know the answer to the timing
    issue?

    Tim.
    */



    -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --



    This archive was generated by hypermail 2b29 : Thu Mar 15 2001 - 04:54:38 EST