From andre.puschmann at tu-ilmenau.de  Mon Jun 25 04:08:25 2012
From: andre.puschmann at tu-ilmenau.de (Andre Puschmann)
Date: Mon, 25 Jun 2012 10:08:25 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
Message-ID: <js969o$djt$1@dough.gmane.org>

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



From mmokrejs at fold.natur.cuni.cz  Mon Jun 25 06:10:44 2012
From: mmokrejs at fold.natur.cuni.cz (Martin Mokrejs)
Date: Mon, 25 Jun 2012 12:10:44 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
In-Reply-To: <js969o$djt$1@dough.gmane.org>
References: <js969o$djt$1@dough.gmane.org>
Message-ID: <4FE83924.5040202@fold.natur.cuni.cz>

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>

From andre.puschmann at tu-ilmenau.de  Mon Jun 25 06:44:24 2012
From: andre.puschmann at tu-ilmenau.de (Andre Puschmann)
Date: Mon, 25 Jun 2012 12:44:24 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
In-Reply-To: <4FE83924.5040202@fold.natur.cuni.cz>
References: <js969o$djt$1@dough.gmane.org>
 <4FE83924.5040202@fold.natur.cuni.cz>
Message-ID: <4FE84108.6030508@tu-ilmenau.de>

Hi Martin,

On 06/25/2012 12:10 PM, Martin Mokrejs wrote:
> 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.

Well, I am not 100% certain but the card came with a driver CD and it
contains a inf file for Windows which is copyright by Oxford Technology.
So that might mean that my adapter has the Oxford chip. Is there any way
to check without breaking the housing?

>   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 think2 I posted some
> URLs while it was fresh in my memory. In the end I gave up.

Mmh, do you think the ECP patches help fixing this IRQ issues?

Regards,
Andre

> 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
>>
>>
> 
> 


-- 
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Cognitive Radio Network Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschmann at tu-ilmenau.de, Web: http://www.tu-ilmenau.de/crng
Office: Zuse Building, room 1071




From mmokrejs at fold.natur.cuni.cz  Mon Jun 25 08:44:05 2012
From: mmokrejs at fold.natur.cuni.cz (Martin Mokrejs)
Date: Mon, 25 Jun 2012 14:44:05 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
In-Reply-To: <4FE84108.6030508@tu-ilmenau.de>
References: <js969o$djt$1@dough.gmane.org>
 <4FE83924.5040202@fold.natur.cuni.cz> <4FE84108.6030508@tu-ilmenau.de>
Message-ID: <4FE85D15.6010108@fold.natur.cuni.cz>



Andre Puschmann wrote:
> Hi Martin,
> 
> On 06/25/2012 12:10 PM, Martin Mokrejs wrote:
>> 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.
> 
> Well, I am not 100% certain but the card came with a driver CD and it
> contains a inf file for Windows which is copyright by Oxford Technology.
> So that might mean that my adapter has the Oxford chip. Is there any way
> to check without breaking the housing?

Try lspci and also dmesg after loading the proper driver.

> 
>>   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 think2 I posted some
>> URLs while it was fresh in my memory. In the end I gave up.
> 
> Mmh, do you think the ECP patches help fixing this IRQ issues?

I could get the card running in ECP at all. It was only in SPP mode without
the patch. If your card is running in ECP+DMA mode you don't need them probably.
Or just try and report back the difference. It is also helpful to know if the patches
break other systems.

Martin


From andre.puschmann at tu-ilmenau.de  Fri Jun 29 14:07:18 2012
From: andre.puschmann at tu-ilmenau.de (Andre Puschmann)
Date: Fri, 29 Jun 2012 20:07:18 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
In-Reply-To: <4FE85D15.6010108@fold.natur.cuni.cz>
References: <js969o$djt$1@dough.gmane.org>
 <4FE83924.5040202@fold.natur.cuni.cz> <4FE84108.6030508@tu-ilmenau.de>
 <4FE85D15.6010108@fold.natur.cuni.cz>
Message-ID: <4FEDEED6.2020208@tu-ilmenau.de>

Hi Martin,

On 06/25/2012 02:44 PM, Martin Mokrejs wrote:
> Andre Puschmann wrote:
>> Hi Martin,
>>
>> On 06/25/2012 12:10 PM, Martin Mokrejs wrote:
>>> 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.
>>
>> Well, I am not 100% certain but the card came with a driver CD and it
>> contains a inf file for Windows which is copyright by Oxford Technology.
>> So that might mean that my adapter has the Oxford chip. Is there any way
>> to check without breaking the housing?
> 
> Try lspci and also dmesg after loading the proper driver.

Sure, well the chip is indeed an Oxford chip according to lspci.


> I could get the card running in ECP at all. It was only in SPP mode without
> the patch. If your card is running in ECP+DMA mode you don't need them probably.
> Or just try and report back the difference. It is also helpful to know if the patches
> break other systems.

I am afraid I won't find the time to test all modes and the patches,
although I'd wish to. What I am concerned about for now is to get the
interrupt operation work ok. But I'll report back on that as soon as I
find something. In the meanwhile, I am happy to receive any feedback on
this, too.

Thanks
Andre



From andre.puschmann at tu-ilmenau.de  Fri Jun 29 14:07:18 2012
From: andre.puschmann at tu-ilmenau.de (Andre Puschmann)
Date: Fri, 29 Jun 2012 20:07:18 +0200
Subject: [Linux-parport] IRQ storm from Express card parallel port
In-Reply-To: <4FE85D15.6010108@fold.natur.cuni.cz>
References: <js969o$djt$1@dough.gmane.org>
 <4FE83924.5040202@fold.natur.cuni.cz> <4FE84108.6030508@tu-ilmenau.de>
 <4FE85D15.6010108@fold.natur.cuni.cz>
Message-ID: <4FEDEED6.2020208@tu-ilmenau.de>

Hi Martin,

On 06/25/2012 02:44 PM, Martin Mokrejs wrote:
> Andre Puschmann wrote:
>> Hi Martin,
>>
>> On 06/25/2012 12:10 PM, Martin Mokrejs wrote:
>>> 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.
>>
>> Well, I am not 100% certain but the card came with a driver CD and it
>> contains a inf file for Windows which is copyright by Oxford Technology.
>> So that might mean that my adapter has the Oxford chip. Is there any way
>> to check without breaking the housing?
> 
> Try lspci and also dmesg after loading the proper driver.

Sure, well the chip is indeed an Oxford chip according to lspci.


> I could get the card running in ECP at all. It was only in SPP mode without
> the patch. If your card is running in ECP+DMA mode you don't need them probably.
> Or just try and report back the difference. It is also helpful to know if the patches
> break other systems.

I am afraid I won't find the time to test all modes and the patches,
although I'd wish to. What I am concerned about for now is to get the
interrupt operation work ok. But I'll report back on that as soon as I
find something. In the meanwhile, I am happy to receive any feedback on
this, too.

Thanks
Andre


