[PARPORT] Re: Help using PPDEV with EPP

From: Tim Waugh (twaugh@redhat.com)
Date: Fri Aug 11 2000 - 11:44:59 EDT

  • Next message: David Hawkins: "[PARPORT] Help using PPDEV with EPP"

    On Mon, Aug 07, 2000 at 07:28:57PM -0700, David Hawkins wrote:

    > 3. ran 'make config' and setup the parallel ports as loadable
    > modules - same for ppdev. Note: I also ran make xconfig to
    > do this, however, although ppdev showed up in the selection
    > menu, attempts to alter the check-box gave an error (visible
    > back in the xterm it was executed from). I recompiled the
    > kernel, updated the slocate database and ran 'slocate ppdev'.
    > Although there were some new ppdev directories generated
    > during the make process, I didn't get a ppdev.o file
    > generated. Any comments on this?

    Did you do 'make modules'? slocate won't show you anything that's
    been created since the last updatedb: did you look for ppdev.o in the
    right place (drivers/char)?

    > 6. I then ran variations on the code below and have the
    > following observations/suggestions:
    > - the call to PPNEGOT fails. I didn't delve too far into the
    > source code for this call, but does this call require a response from
    > the 1284 device? If it does, what are the address/data cycles -
    > I can easily implement the appropriate response in my device.

    It performs IEEE 1284 negotiation. If your device doesn't do that,
    just don't bother with PPNEGOT.

    > - both writes appear to go to the address port, (using PPSETMODE to
    > select the data port didn't seem to work).

    All PPSETMODE does it tell the ppdev driver which IEEE 1284 mode
    should be used for read() and write().

    > I looked at the source code to see what the function calling
    > sequence looks like and get:
    > User space read/write are implemented via pp_read / pp_write,
    > which are implemented via parport_read / parport_write
    > in which a switch statement selects from the four functions
    > ieee1284_epp_[read/write]_[addr/data].

    If the lowlevel driver (parport_pc in your case) provides
    hardware-accelerated functions for those transfers then they are used

    In parport_pc port->ops gets set to use ieee1284_xxx by default; the
    hardware detection routines sometimes override them.

    > So why the added complexity in the implementations of the
    > ieee1284_epp_[read/write]_[addr/data] functions and why does it
    > look like the calls resolve to SPP reads/writes instead of EPP address
    > or data reads/writes?

    EPP transfers can be done without EPP hardware; if the hardware is
    there it can be used, otherwise you have to use SPP registers.

    > There is a note at the top of these functions mentioning they are
    > untested.
    > If someone can give me the rational behind their implementation,
    > I will happily provide 'testing' of these functions in my environment.

    The ieee1284_xxx routines? They just do the EPP handshaking. Note
    the difference between the EPP on-the-wire protocol and the chipset
    hardware that does it. Take a look at IEEE 1284.

    > In the ParPort docs, it is not clear what the difference between
    > read()
    > write() calls and ioctls with PPRDATA and PPWDATA.

    PPRDATA and PPWDATA deal with the current state of the data pins.
    Nothing more.

    read()/write() perform IEEE 1284 data/address transfers.

    > Looking at
    > the source code, I see that the ioctls resolve to parport_write_data
    > and parport_read_data, which as mentioned above resolve to SPP
    > read/writes in parport_pc.h. Would it be more appropriate for these
    > calls to mimic pp_read and pp_write?

    Not at all: pp_read and pp_write are for doing IEEE 1284 data/address
    transfers, whereas parport_read_data/parport_write_data ===


    -- 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 : Fri Aug 11 2000 - 11:50:53 EDT