[PARPORT] getting the parport subsystem to recognize a PPC34C60 chip

From: Charles Lepple (clepple@ghz.cc)
Date: Mon May 13 2002 - 20:38:37 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] getting the parport subsystem to recognize a PPC34C60 chip"

    I've been doing some development with TI's 'C5402 and 'C6211/6711 DSKs,
    and I would like to be able to transfer data from them under Linux. (I
    realize that the tools do not yet exist to cross-compile to these boards
    from Linux, but for the moment, I am content to do the development in
    Windows and do the data collection in Linux.)

    Both of these boards have a SMSC PPC34C60 parallel port slave interface
    chip, which provides a pseudo-ISA bus interface to the rest of the board
    (specifically, a host port on the DSP, and a JTAG test bus controller).
    The datasheet is here: http://www.smsc.com/main/datasheets/34c60.pdf

    The first thing I need to do, though, is get the chip to be recognized as
    a valid IEEE-1284 device under Linux. Everything in the data sheet
    indicates 1284 compatibility, and SMSC even provides timing diagrams for
    accessing the chip (both read and write cycles) under SPP, ECP and EPP
    modes.

    I read Tim Waugh's parport documentation, and started playing with his
    example code for a user-space driver (using /dev/parportX and the
    associated ioctls). Basically, the chip appears to be in some sort of
    pass-thru mode, in that it is not responding to any negotiation. The SMSC
    datasheet talks about the Distec (sp?) daisy-chain protocol, which I
    assume is what drivers/parport/daisy.c is doing, but some pieces seem to
    be missing.

    Here's an excerpt from a 2.4.9 kernel (from an updated RedHat 7.2 box; I
    tried a later kernel as well on my laptop, and I think there is much
    brokenness in the ThinkPad Super-IO chipset):

    parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,COMPAT,ECP]
    parport0: Found 1 daisy-chained devices
    parport0: Peripheral not IEEE1284 compliant (0x7F)
    ppdev0: registered pardevice
    parport0: Peripheral not IEEE1284 compliant (0x7F)
    ppdev0: unregistered pardevice

    The ppdev0 lines are triggered by running my user-space program.

    All of the /proc files that usually contain 1284 probe information are
    basically empty, and the kernel message log doesn't indicate any sort of
    attempt at probing.

    This is what I get when I disconnect the board, and reload the parallel
    port module stack:

    parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,COMPAT,ECP]
    parport0: cpp_daisy: aa5500ff(38)
    parport0: assign_addrs: aa5500ff(38)
    parport0: Peripheral not IEEE1284 compliant (0x7F)
    parport0: cpp_daisy: aa5500ff(38)
    parport0: assign_addrs: aa5500ff(38)
    parport0: Peripheral not IEEE1284 compliant (0x7F)

    Does anyone know if I can even do the daisy-chain enable command from user
    space? Also, shouldn't there be some sort of indication about the product
    ID from the daisy-chain scan? I have schematics for the DSK boards, so I
    know what should be coming up as the product ID.

    Incidentally, Windows 98 did not prompt me for a driver disk when I first
    hooked up the board (which was before installing TI's Code Composer Studio)
    , so it is possible that the PnP stuff doesn't work, and that they simply
    detect the board by assuming that it exists, and probing known registers.

    Once I solve the problem of getting the chip to respond, I'd love to hear
    from anyone who has a good example driver that does byte-wide reads, but I'
    m getting ahead of myself now.

    Any help would be most appreciated. I would be more than happy to return
    the favor by helping fill in the missing pieces in the documentation.

    --
    Charles Lepple <clepple@ghz.cc>
    http://www.ghz.cc/charles/
    

    -- 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 : Mon May 13 2002 - 20:46:08 EDT