Re: [PARPORT] Patch: Parport Winbond detection and misc (2.3.46)

From: Gunther Mayer (
Date: Tue Feb 22 2000 - 16:03:13 EST

  • Next message: "Re: [PARPORT] Backpack CD-Rewriter"

    Tim Waugh wrote:

    > On Sat, 19 Feb 2000, Gunther Mayer wrote:
    > > Highlights:
    > > - Support for Winbond Super-IO chips (expandable to other manufacturers)
    > > "insmod parport_pc superio=1 irq=auto dma=auto" to autodetect and
    > > report it
    > This is quite neat. I wonder if it's possible to detect it without
    > needing 'superio=1'..?

    Of course, I just considered poking at these ports (0x3f0, 0x2e,...) too
    to make it standard. The next version will detect some SMSC chips too; this
    shows linux doesn`t detect EPP-mode on37c669 when operated as "ECP+EPP"
    (it is detected correctly when set to "EPP" in the BIOS).

    > > - Provide more human-readable output on assorted places, to
    > > assist further progress on debugging and features
    > > - Correct very minor glitches concerning ECP/ISA standard obeyance
    > > (major glitches not yet addressed :-)
    > Can you send these to me as separate patches please?

    I will rearrange the patch...

    > > Other Changes
    > > - Print the complete IEEE1284 Device ID (unmangled) and
    > > be merciful to devices that didn't get everything right
    > I don't think this is really necessary -- it's already available in /proc
    > anyway. I quite like the pretty printing.

    It`s just the pretty-printed Device ID in
    /proc/sys/dev/parport/parport0/autoprobe !
    I just want to KNOW the raw Device ID (the standard even says it must be

    > > The idea is switching DPRINTK off as done in this patch.
    > I'd like to keep that on a while longer.

    OK. I plan to add more DPRINTKs to find my ECP+LJ1100A crash.

    > > - The "lp" driver registers itself to "/proc/driver/lp" and gives some
    > > fancy human-readable output. Here I can see how slow my printer is :-)
    > Let's be careful about adding more file formats! (There's always tunelp
    > for this sort of thing..)

    The advantage of /proc is it's easy availability, no need to hunt for the
    newest tools...
    I'd even like a generic layer at device level that counts the reads/writes
    for every device!

    Every driver should provide information about it's current state
    and paramters, so we either have a /proc-entry or a separate tool per

    > > Actually I wonder if I can use ECP to speak to my printer, that does
    > > currently only 20K/sec in SPP mode. A quick hack only hung both linux
    > > and the printer completely.
    > I've wondered about this too, but I don't have a printer that speaks ECP.

    Even so it should not hang completely. I will add debugging to see why...

    Regards, Gunther

    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Tue Feb 22 2000 - 16:07:57 EST