Carlos Henrique Bauer (chbauer@acm.org)
Fri, 12 Feb 1999 00:13:27 -0300
Hi,
Today I applied the patch-2.2.1-1284-6 patch and noticed that it has broken that
additional test for the EPP mode that I've sent you some days ago. After
applying the patch-2.2.1-1284-12843-3 patch I looked at the parport_pc.c code.
The 1284-6 patch changed the order of EPP probing tests in the function
parport_EPP_support. That's the problem. The test that now is the first leaves
the control register port in a condition the second test doesn't like. Inverting
the order of the tests again makes the EPP probing work in the ECP+EPP mode.
The patch is included bellow.
Best regards,
Carlos Henrique Bauer
--- linux/drivers/misc/parport_pc.c.back Fri Feb 12 00:31:09 1999
+++ linux/drivers/misc/parport_pc.c Fri Feb 12 00:38:17 1999
@@ -993,41 +993,23 @@
return PARPORT_MODE_PCECP;
}
-/* EPP mode detection
- * Theory:
- * Bit 0 of STR is the EPP timeout bit, this bit is 0
- * when EPP is possible and is set high when an EPP timeout
- * occurs (EPP uses the HALT line to stop the CPU while it does
- * the byte transfer, an EPP timeout occurs if the attached
- * device fails to respond after 10 micro seconds).
- *
- * This bit is cleared by either reading it (National Semi)
- * or writing a 1 to the bit (SMC, UMC, WinBond), others ???
- * This bit is always high in non EPP modes.
- */
+/* EPP mode detection */
+
static int __init parport_EPP_supported(struct parport *pb)
{
/* If EPP timeout bit clear then EPP available */
if (!parport_pc_epp_clear_timeout(pb))
return 0; /* No way to clear timeout */
- parport_pc_write_control(pb, parport_pc_read_control(pb) | 0x20);
- parport_pc_write_control(pb, parport_pc_read_control(pb) | 0x10);
- parport_pc_epp_clear_timeout(pb);
-
- parport_pc_read_epp(pb);
- udelay(30); /* Wait for possible EPP timeout */
-
- if (parport_pc_read_status(pb) & 0x01) {
- parport_pc_epp_clear_timeout(pb);
- return PARPORT_MODE_PCEPP;
- }
+ /*
+ * Theory:
+ * Write two values to the EPP address register and
+ * read them back. When the transfer times out, the state of
+ * the EPP register is undefined in some cases (EPP 1.9?) but
+ * in others (EPP 1.7, ECPEPP?) it is possible to read back
+ * its value.
+ */
- /* THEORY: write two values to the EPP address register and
- read them back. When the transfer times out, the state of
- the EPP register is undefined in some cases (EPP 1.9?) but
- in others (EPP 1.7, ECPEPP?) it is possible to read back
- its value. */
parport_pc_epp_clear_timeout(pb);
udelay(30); /* Wait for possible EPP timeout */
@@ -1044,6 +1026,32 @@
return PARPORT_MODE_PCEPP;
}
}
+
+ /*
+ * Theory:
+ * Bit 0 of STR is the EPP timeout bit, this bit is 0
+ * when EPP is possible and is set high when an EPP timeout
+ * occurs (EPP uses the HALT line to stop the CPU while it does
+ * the byte transfer, an EPP timeout occurs if the attached
+ * device fails to respond after 10 micro seconds).
+ *
+ * This bit is cleared by either reading it (National Semi)
+ * or writing a 1 to the bit (SMC, UMC, WinBond), others ???
+ * This bit is always high in non EPP modes.
+ */
+
+ parport_pc_write_control(pb, parport_pc_read_control(pb) | 0x20);
+ parport_pc_write_control(pb, parport_pc_read_control(pb) | 0x10);
+ parport_pc_epp_clear_timeout(pb);
+
+ parport_pc_read_epp(pb);
+ udelay(30); /* Wait for possible EPP timeout */
+
+ if (parport_pc_read_status(pb) & 0x01) {
+ parport_pc_epp_clear_timeout(pb);
+ return PARPORT_MODE_PCEPP;
+ }
+
return 0;
}
-- 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 Thu 11 Feb 1999 - 22:10:19 EST