Tim Waugh (tim@cyberelk.demon.co.uk)
Sun, 2 May 1999 12:14:06 +0100 (GMT)
On Sun, 2 May 1999, Pedro [iso-8859-1] Andrés Aranda [iso-8859-1] Gutiérrez wrote:
> parport0: PC-style at 0x378, irq 7 [SPP,ECP,ECPPS2]
> parport0: Unspecified, Unknown vendor Unknown device
> pda: Sharing parport0 at 0x378
> pda: epat 1.01, Shuttle EPAT chip c5 at 0x378, mode 0 (4-bit), delay 1
Pedro,
The first line here shows the modes that parport thinks the port is
capable of, and PS2 isn't listed. That means that the port won't let the
peripheral transfer data to the computer 8 bits at a time, at least not in
normal ('SPP') mode. You might be able to change this in the BIOS
settings.
However, it _is_ reporting that it's possible if pd sets the extended
control register to 'PS2 mode' (001 in top three bits). Grant, does pd
do that [frob_econtrol (p, 0xe0, 0x20)]?
When parport analyses the port, it leaves it in 'SPP' mode (000).
Possibly it should it in 'PS2' (001) mode instead, since the only
difference is that bit 5 of CTR (tri-state the port) is writable.
The other thing I notice about the messages you have is that an 'Unknown
device' made by an 'Unknown vendor' -- this shouldn't ever happen, really.
I would be grateful if you could change the line that says
#undef DEBUG_PROBE
to
#define DEBUG_PROBE
in linux/drivers/pnp/parport_probe.c, recompile, and show me the boot
messages again.
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 2.0b3 on Sun 02 May 1999 - 07:25:51 EDT