From nacc at us.ibm.com  Mon May  2 02:29:13 2005
From: nacc at us.ibm.com (Nishanth Aravamudan)
Date: Tue May  3 04:54:51 2005
Subject: [Linux-parport] [PATCH] parport/ieee1284: use human-time in
	sleeping logic
In-Reply-To: <20050502061446.GB10173@us.ibm.com>
References: <20050502061446.GB10173@us.ibm.com>
Message-ID: <20050502062913.GE10173@us.ibm.com>

Be a little more precise with the conversions between milliseconds and
jiffies. Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

--- 2.6.12-rc3/drivers/parport/ieee1284.c	2005-04-29 11:03:05.000000000 -0700
+++ 2.6.12-rc3-dev/drivers/parport/ieee1284.c	2005-05-01 21:28:35.000000000 -0700
@@ -196,7 +196,7 @@ int parport_wait_peripheral(struct parpo
 		return 1;
 
 	/* 40ms of slow polling. */
-	deadline = jiffies + (HZ + 24) / 25;
+	deadline = jiffies + msecs_to_jiffies(40);
 	while (time_before (jiffies, deadline)) {
 		int ret;
 
@@ -212,13 +212,11 @@ int parport_wait_peripheral(struct parpo
 		if ((status & mask) == result)
 			return 0;
 
-		if (!ret) {
+		if (!ret)
 			/* parport_wait_event didn't time out, but the
 			 * peripheral wasn't actually ready either.
 			 * Wait for another 10ms. */
-			__set_current_state (TASK_INTERRUPTIBLE);
-			schedule_timeout ((HZ+ 99) / 100);
-		}
+			msleep_interruptible(10);
 	}
 
 	return 1;

From ms at gewi.kfunigraz.ac.at  Mon May  9 23:33:41 2005
From: ms at gewi.kfunigraz.ac.at (Martin Schitter)
Date: Tue May 10 04:59:58 2005
Subject: [Linux-parport] NetMos nm9855 patch
Message-ID: <20050510033341.GB2908@gewi.kfunigraz.ac.at>

could you please test/approve this little patch and include it to the kernel
sources.

 thank's 
 martin


patch tor the NetMos nm9855 (parport_pc/parport_serial):

kernel 2.6.12-rc2 adopted some code by Bjorn Helgaas supporting NetMos combo
controller cards. this implementation doesn't work for nm9855 based cards!

there are two reasons:

      a) the module 'parport_pc' doesn't want to give the resonsibility for
         the netmos_9855 to 'parport_serial' and can not handle the serial
         lines -- trivial to fix...
	 
	 http://lists.infradead.org/pipermail/linux-parport/2005-February/000250.html
	 http://lkml.org/lkml/2005/3/24/199
	 
      b) the support for the nm9855 in 'parport_serial' still doesn't work
         because of wrong assumptions about the relevant BARs 
	 
	 port address layout for this chip:

	 0000:00:09.0 Communication controller:
         	      NetMos Technology PCI 9855 
         	      Multi-I/O Controller (rev 01)        
	 	      (= 9710:9855)
         Subsystem: LSI Logic / Symbios Logic 1P4S (= 1000:0014)
  	 Flags: medium devsel, IRQ 177
	 I/O ports at a800 [size=8]  (= parport)
	 I/O ports at a400 [size=8]  
	 I/O ports at a000 [size=8]  (= serial)
	 I/O ports at 9800 [size=8]  (= serial)
	 I/O ports at 9400 [size=8]  (= serial)
	 I/O ports at 9000 [size=16] (= serial)


the following patch will fix the problem:

--- linux-2.6.12-rc4/drivers/parport/parport_pc.c.orig	2005-05-09 23:22:38.000000000 +0200
+++ linux-2.6.12-rc4/drivers/parport/parport_pc.c	2005-05-09 23:24:05.000000000 +0200
@@ -2751,7 +2751,6 @@
 	netmos_9755,
 	netmos_9805,
 	netmos_9815,
-	netmos_9855,
 };
 
 
@@ -2826,7 +2825,6 @@
         /* netmos_9755 */               { 2, { { 0, 1 }, { 2, 3 },} }, /* untested */
 	/* netmos_9805 */               { 1, { { 0, -1 }, } }, /* untested */
 	/* netmos_9815 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
-	/* netmos_9855 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
 };
 
 static struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2907,8 +2905,6 @@
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9805 },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9815,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9815 },
-	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	{ 0, } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci,parport_pc_pci_tbl);
--- linux-2.6.12-rc4/drivers/parport/parport_serial.c.orig	2005-05-09 23:23:05.000000000 +0200
+++ linux-2.6.12-rc4/drivers/parport/parport_serial.c	2005-05-09 23:34:16.000000000 +0200
@@ -34,6 +34,7 @@
 	titan_110l = 0,
 	titan_210l,
 	netmos_9xx5_combo,
+	netmos_9855,
 	avlab_1s1p,
 	avlab_1s1p_650,
 	avlab_1s1p_850,
@@ -87,6 +88,7 @@
 	/* titan_110l */		{ 1, { { 3, -1 }, } },
 	/* titan_210l */		{ 1, { { 3, -1 }, } },
 	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
+	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
 	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
 	/* avlab_1s1p_650 */		{ 1, { { 1, 2}, } },
 	/* avlab_1s1p_850 */		{ 1, { { 1, 2}, } },
@@ -120,7 +122,7 @@
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
 	{ 0x14db, 0x2110, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p},
 	{ 0x14db, 0x2111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p_650},
@@ -207,6 +209,7 @@
 /* titan_110l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 1, 921600 },
 /* titan_210l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 2, 921600 },
 /* netmos_9xx5_combo */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
+/* netmos_9855 */	{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
 /* avlab_1s1p (n/t) */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
 /* avlab_1s1p_650 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
 /* avlab_1s1p_850 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },


-------------- next part --------------
--- linux-2.6.12-rc4/drivers/parport/parport_pc.c.orig	2005-05-09 23:22:38.000000000 +0200
+++ linux-2.6.12-rc4/drivers/parport/parport_pc.c	2005-05-09 23:24:05.000000000 +0200
@@ -2751,7 +2751,6 @@
 	netmos_9755,
 	netmos_9805,
 	netmos_9815,
-	netmos_9855,
 };
 
 
@@ -2826,7 +2825,6 @@
         /* netmos_9755 */               { 2, { { 0, 1 }, { 2, 3 },} }, /* untested */
 	/* netmos_9805 */               { 1, { { 0, -1 }, } }, /* untested */
 	/* netmos_9815 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
-	/* netmos_9855 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
 };
 
 static struct pci_device_id parport_pc_pci_tbl[] = {
@@ -2907,8 +2905,6 @@
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9805 },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9815,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9815 },
-	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	{ 0, } /* terminate list */
 };
 MODULE_DEVICE_TABLE(pci,parport_pc_pci_tbl);
--- linux-2.6.12-rc4/drivers/parport/parport_serial.c.orig	2005-05-09 23:23:05.000000000 +0200
+++ linux-2.6.12-rc4/drivers/parport/parport_serial.c	2005-05-09 23:34:16.000000000 +0200
@@ -34,6 +34,7 @@
 	titan_110l = 0,
 	titan_210l,
 	netmos_9xx5_combo,
+	netmos_9855,
 	avlab_1s1p,
 	avlab_1s1p_650,
 	avlab_1s1p_850,
@@ -87,6 +88,7 @@
 	/* titan_110l */		{ 1, { { 3, -1 }, } },
 	/* titan_210l */		{ 1, { { 3, -1 }, } },
 	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
+	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
 	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
 	/* avlab_1s1p_650 */		{ 1, { { 1, 2}, } },
 	/* avlab_1s1p_850 */		{ 1, { { 1, 2}, } },
@@ -120,7 +122,7 @@
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
-	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
+	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
 	{ 0x14db, 0x2110, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p},
 	{ 0x14db, 0x2111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p_650},
@@ -207,6 +209,7 @@
 /* titan_110l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 1, 921600 },
 /* titan_210l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 2, 921600 },
 /* netmos_9xx5_combo */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
+/* netmos_9855 */	{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
 /* avlab_1s1p (n/t) */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
 /* avlab_1s1p_650 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
 /* avlab_1s1p_850 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
From bjorn.helgaas at hp.com  Tue May 10 11:06:32 2005
From: bjorn.helgaas at hp.com (Bjorn Helgaas)
Date: Tue May 10 11:34:37 2005
Subject: [Linux-parport] Re: NetMos nm9855 patch
In-Reply-To: <20050510033341.GB2908@gewi.kfunigraz.ac.at>
References: <20050510033341.GB2908@gewi.kfunigraz.ac.at>
Message-ID: <200505100906.32825.bjorn.helgaas@hp.com>

On Monday 09 May 2005 9:33 pm, Martin Schitter wrote:
> could you please test/approve this little patch and include it to the kernel
> sources.

I don't actually have any Netmos cards at all, so I can't test it,
but the patch looks good to me.  Thanks a lot for debugging and
fixing this!  If RMK doesn't object, I suggest that you add a
"Signed-off-by: Martin Schitter <ms@gewi.kfunigraz.ac.at>" line
and send it to Andrew Morton.

> patch tor the NetMos nm9855 (parport_pc/parport_serial):
> 
> kernel 2.6.12-rc2 adopted some code by Bjorn Helgaas supporting NetMos combo
> controller cards. this implementation doesn't work for nm9855 based cards!
> 
> there are two reasons:
> 
>       a) the module 'parport_pc' doesn't want to give the resonsibility for
>          the netmos_9855 to 'parport_serial' and can not handle the serial
>          lines -- trivial to fix...
> 	 
> 	 http://lists.infradead.org/pipermail/linux-parport/2005-February/000250.html
> 	 http://lkml.org/lkml/2005/3/24/199
> 	 
>       b) the support for the nm9855 in 'parport_serial' still doesn't work
>          because of wrong assumptions about the relevant BARs 
> 	 
> 	 port address layout for this chip:
> 
> 	 0000:00:09.0 Communication controller:
>          	      NetMos Technology PCI 9855 
>          	      Multi-I/O Controller (rev 01)        
> 	 	      (= 9710:9855)
>          Subsystem: LSI Logic / Symbios Logic 1P4S (= 1000:0014)
>   	 Flags: medium devsel, IRQ 177
> 	 I/O ports at a800 [size=8]  (= parport)
> 	 I/O ports at a400 [size=8]  
> 	 I/O ports at a000 [size=8]  (= serial)
> 	 I/O ports at 9800 [size=8]  (= serial)
> 	 I/O ports at 9400 [size=8]  (= serial)
> 	 I/O ports at 9000 [size=16] (= serial)
> 
> 
> the following patch will fix the problem:
> 
> --- linux-2.6.12-rc4/drivers/parport/parport_pc.c.orig	2005-05-09 23:22:38.000000000 +0200
> +++ linux-2.6.12-rc4/drivers/parport/parport_pc.c	2005-05-09 23:24:05.000000000 +0200
> @@ -2751,7 +2751,6 @@
>  	netmos_9755,
>  	netmos_9805,
>  	netmos_9815,
> -	netmos_9855,
>  };
>  
>  
> @@ -2826,7 +2825,6 @@
>          /* netmos_9755 */               { 2, { { 0, 1 }, { 2, 3 },} }, /* untested */
>  	/* netmos_9805 */               { 1, { { 0, -1 }, } }, /* untested */
>  	/* netmos_9815 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
> -	/* netmos_9855 */               { 2, { { 0, -1 }, { 2, -1 }, } }, /* untested */
>  };
>  
>  static struct pci_device_id parport_pc_pci_tbl[] = {
> @@ -2907,8 +2905,6 @@
>  	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9805 },
>  	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9815,
>  	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9815 },
> -	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
>  	{ 0, } /* terminate list */
>  };
>  MODULE_DEVICE_TABLE(pci,parport_pc_pci_tbl);
> --- linux-2.6.12-rc4/drivers/parport/parport_serial.c.orig	2005-05-09 23:23:05.000000000 +0200
> +++ linux-2.6.12-rc4/drivers/parport/parport_serial.c	2005-05-09 23:34:16.000000000 +0200
> @@ -34,6 +34,7 @@
>  	titan_110l = 0,
>  	titan_210l,
>  	netmos_9xx5_combo,
> +	netmos_9855,
>  	avlab_1s1p,
>  	avlab_1s1p_650,
>  	avlab_1s1p_850,
> @@ -87,6 +88,7 @@
>  	/* titan_110l */		{ 1, { { 3, -1 }, } },
>  	/* titan_210l */		{ 1, { { 3, -1 }, } },
>  	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
> +	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
>  	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
>  	/* avlab_1s1p_650 */		{ 1, { { 1, 2}, } },
>  	/* avlab_1s1p_850 */		{ 1, { { 1, 2}, } },
> @@ -120,7 +122,7 @@
>  	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
>  	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
>  	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
> -	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
> +	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
>  	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
>  	{ 0x14db, 0x2110, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p},
>  	{ 0x14db, 0x2111, PCI_ANY_ID, PCI_ANY_ID, 0, 0, avlab_1s1p_650},
> @@ -207,6 +209,7 @@
>  /* titan_110l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 1, 921600 },
>  /* titan_210l */	{ SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 2, 921600 },
>  /* netmos_9xx5_combo */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
> +/* netmos_9855 */	{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 1, 115200, 0, 0, netmos_serial_init },
>  /* avlab_1s1p (n/t) */	{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
>  /* avlab_1s1p_650 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
>  /* avlab_1s1p_850 (nt)*/{ SPCI_FL_BASE0 | SPCI_FL_BASE_TABLE, 1, 115200 },
> 
> 
> 

From domen at coderock.org  Fri May 13 18:23:50 2005
From: domen at coderock.org (domen@coderock.org)
Date: Sat May 14 08:26:30 2005
Subject: [Linux-parport] [patch 1/1] parport/ieee1284: use human-time in
	sleeping logic
Message-ID: <20050513222350.209425000@nd47.coderock.org>

From: Nishanth Aravamudan <nacc@us.ibm.com>


Be a little more precise with the conversions between milliseconds and
jiffies. Use msleep_interruptible() instead of schedule_timeout() to
guarantee the task delays as expected.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Domen Puncer <domen@coderock.org>

---
 ieee1284.c |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

Index: quilt/drivers/parport/ieee1284.c
===================================================================
--- quilt.orig/drivers/parport/ieee1284.c
+++ quilt/drivers/parport/ieee1284.c
@@ -196,7 +196,7 @@ int parport_wait_peripheral(struct parpo
 		return 1;
 
 	/* 40ms of slow polling. */
-	deadline = jiffies + (HZ + 24) / 25;
+	deadline = jiffies + msecs_to_jiffies(40);
 	while (time_before (jiffies, deadline)) {
 		int ret;
 
@@ -212,13 +212,11 @@ int parport_wait_peripheral(struct parpo
 		if ((status & mask) == result)
 			return 0;
 
-		if (!ret) {
+		if (!ret)
 			/* parport_wait_event didn't time out, but the
 			 * peripheral wasn't actually ready either.
 			 * Wait for another 10ms. */
-			__set_current_state (TASK_INTERRUPTIBLE);
-			schedule_timeout ((HZ+ 99) / 100);
-		}
+			msleep_interruptible(10);
 	}
 
 	return 1;

--

From charlesb at otcgaming.net  Mon May 16 18:23:04 2005
From: charlesb at otcgaming.net (Charles Blackburn)
Date: Mon May 16 18:23:10 2005
Subject: [Linux-parport] Inverting the parallel port pins
Message-ID: <00a401c55a65$d4b84510$0500a8c0@gamemachine>

I'm sending this to both lists on the off chance that someone may be
able to help..


I have managed to get the soundmodem (user-mode) wokring now under
2.6.11 (latest knoppix installed to HD), but the problem comes in that
the radio is constantly keyed up.

It seems that the data0 pin on parport0 is being held high by something
and I cant work out what.

I've searched through the archives going back the past year or so and
there have been several messages on the linux--hams one about this same
subject.

Basically what I'm asking, is there any way to invert the pin on the
parallel port in the user-mode soundmodem driver? It was metioned by
someone that there should be an option in sethdlc, but the problem is,
sethdlc doesn?t work with the user-mode soundmodem.

Hopefully someone can help (btw the interface works fine under windows
:( )

Regards and 73
Charles - 2E0GOM
ARICC UK Co-Ordinator - http://www.aricc.org
Kirklees RAYNET - http://www.kirkleesraynet.org.uk

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005
 


From joerg.wunsch at hno.atmel.com  Thu May 19 05:05:22 2005
From: joerg.wunsch at hno.atmel.com (Joerg Wunsch)
Date: Thu May 19 06:00:09 2005
Subject: [Linux-parport] NetMos nm9855 patch
In-Reply-To: <20050510033341.GB2908@gewi.kfunigraz.ac.at>
Message-ID: <20050519090522.GA12072@uriah.heep.sax.de>

I tried to hack up a 2.6.8-24 kernel to recognize my NetMos 9855
serial ports that way.  The ports are now recognized appropriately:

(DEBUG_AUTOCONF in uart8250.c already turned on)

May 19 10:59:02 sv10drdev kernel: ACPI: PCI interrupt 0000:02:08.0[A] -> GSI 9 (level, low) -> IRQ 9
May 19 10:59:02 sv10drdev kernel: PCI parallel port detected: 9710:9745, I/O at 0xb800(0x0)
May 19 10:59:02 sv10drdev kernel: parport1: PC-style at 0xb800 [PCSPP,TRISTATE,EPP]
May 19 10:59:02 sv10drdev kernel: lp1: using parport1 (polling).
May 19 10:59:02 sv10drdev kernel: ttyS4: autoconf (0xb000, 0x0000000000000000): iir=3 iir1=6 iir2=6 type=16550A
May 19 10:59:02 sv10drdev kernel: ttyS4 at I/O 0xb000 (irq = 9) is a 16550A
May 19 10:59:02 sv10drdev kernel: ttyS5: autoconf (0xac00, 0x0000000000000000): iir=3 iir1=6 iir2=6 type=16550A
May 19 10:59:02 sv10drdev kernel: ttyS5 at I/O 0xac00 (irq = 9) is a 16550A
May 19 10:59:02 sv10drdev kernel: ttyS6: autoconf (0xa800, 0x0000000000000000): iir=3 iir1=6 iir2=6 type=16550A
May 19 10:59:02 sv10drdev kernel: ttyS6 at I/O 0xa800 (irq = 9) is a 16550A
May 19 10:59:02 sv10drdev kernel: ttyS7: autoconf (0xa400, 0x0000000000000000): iir=3 iir1=6 iir2=6 type=16550A
May 19 10:59:02 sv10drdev kernel: ttyS7 at I/O 0xa400 (irq = 9) is a 16550A

Anyway, all my access attempts to ttyS4 through ttyS7 yield an EIO.

Does anyone have an idea where to continue debugging this?
-- 
cheers, J"org Wunsch

Contractor for Atmel Dresden, Germany
Never trust an operating system you don't have sources for. ;-)

From cailotto at sci.univr.it  Thu May 19 12:50:33 2005
From: cailotto at sci.univr.it (Dott. Stefano Cailotto)
Date: Thu May 19 12:57:42 2005
Subject: [Linux-parport] dummy parport
Message-ID: <00c701c55c92$dfe95a80$38f21b9d@kai>

Hi all, 
I'm new to the list and I have the following problem:
I have a rack server without a parallel port, but a program running on it (Xilinx Impact) needs it (even if it doesn't use it).
I tried to modprobe parport_pc, bt it fails to load (due, i suppose, to the lack of physical parport). 
I was wondering if there's a way  (dummy parport o some other trick) to solve this problem, i.e. to make the program believe there's a parallel port.
Thank a lot, 
Stefano
------------------------------------------------------------------------------------------------
  Stefano Cailotto - Research Consultant 
------------------------------------------------------------------------------------------------  
  Embedded Systems Design Center
  c/o  Dipartimento di Informatica - Universita` di Verona
  Strada le Grazie, 15 - 37134 Verona (Italy)
------------------------------------------------------------------------------------------------
  email: cailotto@sci.univr.it       
  tel: +39-045-802-7062 fax: +39-045-802-7068
------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/linux-parport/attachments/20050519/ac89a374/attachment.html
From joerg.wunsch at hno.atmel.com  Fri May 20 10:58:43 2005
From: joerg.wunsch at hno.atmel.com (Joerg Wunsch)
Date: Fri May 20 11:15:00 2005
Subject: [Linux-parport] NetMos nm9855 patch
In-Reply-To: <20050519090522.GA12072@uriah.heep.sax.de>
References: <20050510033341.GB2908@gewi.kfunigraz.ac.at>
	<20050519090522.GA12072@uriah.heep.sax.de>
Message-ID: <20050520145843.GA31830@uriah.heep.sax.de>

As Joerg Wunsch wrote:

> I tried to hack up a 2.6.8-24 kernel to recognize my NetMos 9855
> serial ports that way.  The ports are now recognized appropriately:

> May 19 10:59:02 sv10drdev kernel: ttyS4 at I/O 0xb000 (irq = 9) is a 16550A
...

> Anyway, all my access attempts to ttyS4 through ttyS7 yield an EIO.
> 
> Does anyone have an idea where to continue debugging this?

Turned out IRQ sharing was not enabled.  I'd appreciate if a patch
like the following one would remind the innocent administrator of his
mistake, as it's a bit queer the driver probes correctly yet fails to
open the device then.  Yes, I know *why* this happens (IRQ allocation
deferred until device open time), but it took me quite a while to find
out about that, and I'd like to spare other people that effort.

--- ./drivers/serial/8250.c.orig	2005-05-19 14:43:48.000000000 +0200
+++ ./drivers/serial/8250.c	2005-05-19 17:52:56.000000000 +0200
@@ -1142,8 +1142,13 @@
 
 		ret = request_irq(up->port.irq, serial8250_interrupt,
 				  irq_flags, "serial", i);
-		if (ret < 0)
+		if (ret < 0) {
+			if (irq_flags == 0 && ret == EBUSY)
+				printk(KERN_INFO
+				       "8250: IRQ %d chaining failed, needs IRQ sharing?\n",
+				       up->port.irq);
 			serial_do_unlink(i, up);
+		}
 	}
 
 	return ret;

-- 
cheers, J"org Wunsch

Contractor for Atmel Dresden, Germany
Never trust an operating system you don't have sources for. ;-)

From paul at astro.gla.ac.uk  Thu May 26 09:57:49 2005
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Thu May 26 10:12:52 2005
Subject: [Linux-parport] initialising the port with ppdev
Message-ID: <200505261457.54375.paul@astro.gla.ac.uk>

Hi,

I've been converting some code that previously using raw outb() so it using 
the kernel and ppdev instead.

One thing I've noticed is that when one claims the device (via PPCLAIM), the 
control lines are set to some arbitrary, fixed value.  For the application 
I'm working on (eeprom burner), this value happens to be most unfortunate as 
it switches on the VPP (programing) voltage.

There seems no way of telling the driver not to use this default value: the 
best I seem to be able to do is quickly PPFCONTROL the relevant lines to a 
safe value.  Unfortunately (I guess due to the switch to kernel-land), 
there's often context switches happening between the two ioctls, resulting in 
VPP being on for a noticeable time.

So, unless I've missed something, there's a bug here.  Two possible solutions:
  1.  fix the parport API (e.g. parport_pc_init_state() ), allowing the 
desired initial state to be passed.

  2.  fix ppdev so it will accept PPWCONTROL ioctls before a PPCLAIM and 
remember the state.  On claiming the device, ppdev could then immediately set 
the control lines to the cached values (from the PPWCONTROL).

(or perhaps some combination of these two...)

Does this make sense?

Cheers,

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-parport/attachments/20050526/ef47f70f/attachment.bin
