[Linux-parport] IRQ storm from Express card parallel port

[Martin Mokrejs]

Hi Andre,
  I played with a card from another vendor based on MosChip. It was stated
in the manual one cannot use IRQ, only memory-mapped IO. When I did use ECP+DMA
my Linux locked up soon. I could print fine but to scan a page I need a lot of luck.
Well, I need a patch which you can find on this list to disable to "fix" which
disabled ECP on many systems, inadverently, and was still necessary for 3.2.5 kernel.
I am attaching them for your convenience.
  I was dreaming about http://www.usbgear.com/USBG-EX-LPT.html which is based
on Oxford chipset, hopefully working in IRQ mode as well.
  It probably not much helpful answer but that's all I could contribute, from my user
experience. Threads on HPLIP forums merely document that scanning does not work
over these adapters, mention some "soft" ECP mode used by HP printers/scanners
if I remember right. Lookup the archives of this list, I think I posted some
URLs while it was fresh in my memory. In the end I gave up.

Best,
Martin

Andre Puschmann wrote:
> Hi,
> 
> I've been looking at using a Express card to parallel port adapter to
> connect an external device to a PC without on-board parallel port. I got
> an adapter from Delock [1] which seems to work fine at first glance.
> Unfortunately, the IRQ handling seems to have problems. Whenever I
> trigger the first IRQ (I've just shortened pin 10 and ground), I receive
> an infinite number of IRQ from the parallel port which only stop after
> unloading the kernel modules. The testing code [2] works fine on another
> machine with on-board parallel port. I am using the standard Ubuntu
> 12.04 LTS kernel (3.2.0-25). I am wondering whether anybody else has
> observed such a strange behaviour before? It might be also related to
> Guan Xin's post "[BUG] IRQ storm from linux/drivers/char/ppdev.c".
> 
> Thanks
> Andre
> 
> [1] http://www.delock.de/produkte/F_263_Parallel_66220/merkmale.html
> [2] https://github.com/andrepuschmann/lptirq
> 
> 
> _______________________________________________
> Linux-parport mailing list
> Linux-parport at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-parport
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: MCS9901_parport_pc.c.patch
Type: text/x-patch
Size: 2427 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-parport/attachments/20120625/7e29d7e3/attachment.bin>
-------------- next part --------------
--- drivers/parport/parport_pc.c.orig	2012-01-05 00:55:44.000000000 +0100
+++ drivers/parport/parport_pc.c	2012-02-12 23:25:45.000000000 +0100
@@ -1999,8 +1999,6 @@
 
 static int parport_EPP_supported(struct parport *pb)
 {
-	const struct parport_pc_private *priv = pb->private_data;
-
 	/*
 	 * Theory:
 	 *	Bit 0 of STR is the EPP timeout bit, this bit is 0
@@ -2011,25 +2009,16 @@
 	 *
 	 *	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.
+	 *	This bit is usually high in non EPP modes, however, this
+	 *      is no reliable detection method. When the timeout bit is
+	 *      premanently high, then we are definitely not in EPP mode,
+	 *      while in the other case this remains unclear.
 	 */
 
-	/* If EPP timeout bit clear then EPP available */
+	/* If EPP timeout bit clear then assume EPP available */
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-				/* Phony EPP in ECP. */
-				return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */
@@ -2857,6 +2846,21 @@
 	{ sio_ite_8872_probe, NULL, },
 };
 
+void netmos_pci_postinit (struct pci_dev *pdev, int failed)
+{
+	/* The NetMos MCS9901 chips are forced to use ECR */
+	/* when operating in EPP mode. */
+	struct parport *pb = parport_find_base(pci_resource_start(pdev, 0));
+	if (!failed && pb) {
+		printk(KERN_INFO "%s: Forcing use of ECR for EPP trasfers\n", pb->name);
+		pb->modes |= PARPORT_MODE_EPP;
+		pb->ops->epp_read_data = parport_pc_ecpepp_read_data;
+		pb->ops->epp_write_data = parport_pc_ecpepp_write_data;
+		pb->ops->epp_read_addr = parport_pc_ecpepp_read_addr;
+		pb->ops->epp_write_addr = parport_pc_ecpepp_write_addr;
+	}
+}
+
 enum parport_pc_pci_cards {
 	siig_1p_10x = last_sio,
 	siig_2p_10x,
@@ -2954,7 +2958,7 @@
 	/* netmos_9755 */               { 2, { { 0, 1 }, { 2, 3 },} },
 	/* netmos_9805 */               { 1, { { 0, -1 }, } },
 	/* netmos_9815 */               { 2, { { 0, -1 }, { 2, -1 }, } },
-	/* netmos_9901 */               { 1, { { 0, -1 }, } },
+	/* netmos_9901 */               { 1, { { 0, 1 }, }, NULL, netmos_pci_postinit },
 	/* netmos_9865 */               { 1, { { 0, -1 }, } },
 	/* quatech_sppxp100 */		{ 1, { { 0, 1 }, } },
 };
-------------- next part --------------
A non-text attachment was scrubbed...
Name: disable_ecp.patch
Type: text/x-patch
Size: 980 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-parport/attachments/20120625/7e29d7e3/attachment-0001.bin>