Matwey V. Kornilov | 14 Dec 15:09 2014
Picon

OxPCIe952 EPP

Hi,

I've faced strange behavior of OXPCIE952 when EPP is used. The following
PCIe board is equipped with this chipset.

00:08.0 Parallel controller [0701]: Oxford Semiconductor Ltd Device
[1415:c110] (prog-if 02 [ECP])

Namely, I can not read in reverse mode. The interruptions at incoming
data happen, but when I try to read the data, EPP timeout always occurs.

Reverse mode is set up as the following (see
parport_pc_ecpepp_read_data() for the reference):

ECR control (base_hi+2) register is filled with the 0b100 in highest
three bits, and it is 0x81 after this,
EPP control (base+2) register is ORed by 0x20 and then is filled with
0bXXXX0100 to reset (it my case it becomes 0x34 after this).

EPP status (base+1) register is 0xce inside interrupt handler and
becomes 0xcf (EPP timeout flag is set) after the first attempt to read
from EPP data (base+4).

EPP works with the same code and peripheral at motherboard integrated
chipsets. Does anybody have ideas what is going on here?
matwey | 27 Aug 10:07 2014
Picon

[PATCHv5 0/2] parport: parport_pc: Fix false-positives at checking for Intel bug

From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>

Hi,

The following patch series is to deal with the issue on false-positives
of Intel EPP bug check [1].

More than a decade ago, the check was introduced in order to prevent EPP
operation on the some Intel LPT chipsets. The main issue to defence from
was CPU hang at EPP operation on broken chipsets. It is mentioned that
affected chipsets are Intel 82091. However, it is not known whether
there are others.

The check was implemented in strange manner. Now, there is no explanations
why. The check itself now leads to the false-positives, disabling EPP on
many PC-s (Dell OptiPlex series for instance). The latter is an issue.

Here is new version of the patches supposed to shrink the set of the false-positives.
We know that the initial problem arises on x86 with motherboard LPT controller.
The patches following are to enable initial check only for x86 and non-PCI based devices.
It is hard to correctly determine which CPUs could be installed into PentiumPro-compatible
socket, so I postponed initial Alan's suggestion.

For those who want to check theirs hardware, there's prebuilt usb-stick image available:
https://susestudio.com/a/OdbKqm/opensuse-13-1-parport_pc

The patches organized as following:

1. Introduce-intel_bug_present-function

(Continue reading)

Michael Schwingen | 21 Jul 12:23 2014

Patch for parport_serial.c / netmos 9845

Hi,

is this the right place to submit patches for
drivers/parport/parport_serial.c?

I have a Netmos 9845-based PCI card with 4 serial and 1 parallel port, where
the parallel port is not detected by the kernel, because the parallel port
is at BAR 5 instead of BAR 2 as the generic netmos_9xx5_combo entry assumes.

The attached patch adds a fixed entry for this configuration - this works
and should have minimal impact on other 9845-based cards, however, I wonder
if there is a way to auto-detect the correct PCI BARs for one or two
parallel ports.

cu
Michael

Netmos 9845-based card with 4 serial and 1 parallel port is
mis-detected, because the parallel port is at BAR 5 instead of BAR 2
as netmos_9xx5_combo entry assumes.

Signed-off-by: Michael Schwingen <michael <at> schwingen.org>
---

diff -ur linux-3.15.6-orig/drivers/parport/parport_serial.c linux-3.15.6/drivers/parport/parport_serial.c
--- linux-3.15.6-orig/drivers/parport/parport_serial.c	2014-07-18 01:23:31.000000000 +0200
+++ linux-3.15.6/drivers/parport/parport_serial.c	2014-07-21 11:33:54.004069286 +0200
 <at>  <at>  -31,6 +31,7  <at>  <at> 
 	titan_110l = 0,
 	titan_210l,
(Continue reading)

Matwey V. Kornilov | 7 Jul 09:01 2014
Picon

[PATCHv3 2/2] Add force_epp module option for parport_pc.

From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey.kornilov <at> gmail.com>
Date: Wed, 25 Jun 2014 01:08:45 +0400
Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc.

The detection of Intel EPP bug is known to produce much false positives.
The new option is introduced to force enable EPP in spite of the test result.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index a6eaafb..fb7530d 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -105,6 +105,9  <at>  <at>  static int user_specified;
         (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
  static int verbose_probing;
  #endif
+#ifdef CONFIG_PARPORT_1284
+static int force_epp;
+#endif
  static int pci_registered_parport;
  static int pnp_registered_parport;

 <at>  <at>  -1764,7 +1767,7  <at>  <at>  static int parport_EPP_supported(struct parport *pb)
  		return 0;  /* No way to clear timeout */
(Continue reading)

Matwey V. Kornilov | 7 Jul 09:00 2014
Picon

[PATCHv3 1/2] Introduce intel_bug_present function.

From c89138e2c968c07dd11b3c6bfc05a803d0c5434d Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey.kornilov <at> gmail.com>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv3 1/2] Introduce intel_bug_present function.

Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 38 ++++++++++++++++++++++++++------------
  1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..a6eaafb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -1702,6 +1702,30  <at>  <at>  static int parport_ECP_supported(struct parport *pb)
  }
  #endif

+static int intel_bug_present(struct parport *pb)
+{
+	const struct parport_pc_private *priv = pb->private_data;
+	int bug_present = 0;
+
+	if (priv->ecr) {
+		/* store value of ECR */
(Continue reading)

Matwey V. Kornilov | 7 Jul 08:59 2014
Picon

[PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug

From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug

Hi,

The following patch series is to deal with the issue on false-positives
of Intel EPP bug check [1].

More than a decade ago, the check was introduced in order to prevent EPP
operation on the some Intel LPT chipsets. The main issue to defence from
was CPU hang at EPP operation on broken chipsets. It is mentioned that
affected chipsets are Intel 82091. However, it is not known whether
there are others.

The check was implemented in strange manner. Now, there is no explanations
why. The check itself now leads to the false-positives, disabling EPP on
many PC-s (Dell OptiPlex series for instance). The latter is an issue.

Given that our knowledge of the initial problem is quite limited now,
I introduce special option for parport_pc, allowing user to disable check.
This won't introduce regressions.

The patches organized as following:

1. Introduce-intel_bug_present-function.

The transparent refactoring of the check is performed.
Make the check be immutable regarding to ECR register.

(Continue reading)

Matwey V. Kornilov | 30 Jun 10:48 2014
Picon

[PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.

From f5384f47688c116ac765b18bfb01e28b4233b97f Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 01:08:45 +0400
Subject: [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.

The detection of Intel EPP bug is known to produce much false positives.
The new option is introduced to force enable EPP in spite of the test result.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 4b851bb..1a15b9c 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -105,6 +105,9  <at>  <at>  static int user_specified;
         (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
  static int verbose_probing;
  #endif
+#ifdef CONFIG_PARPORT_1284
+static int force_epp;
+#endif
  static int pci_registered_parport;
  static int pnp_registered_parport;

 <at>  <at>  -1765,7 +1768,7  <at>  <at>  static int parport_EPP_supported(struct parport *pb)
  		return 0;  /* No way to clear timeout */
(Continue reading)

Matwey V. Kornilov | 30 Jun 10:48 2014
Picon

[PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.

From 28bb276ff858caecddfde78133f6b5b261c40a59 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.

Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 35 +++++++++++++++++++++++++----------
  1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..4b851bb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -1702,6 +1702,29  <at>  <at>  static int parport_ECP_supported(struct parport *pb)
  }
  #endif

+static int intel_bug_present(struct parport *pb)
+{
+	int bug_present = 0;
+
+	if (priv->ecr) {
+		/* store value of ECR */
+		unsigned char ecr = inb(ECONTROL(pb));
(Continue reading)

kuba | 23 Jan 19:11 2014
Picon

Auto detection vs specifying ports

  Hi,

I have a pci parallel port card based on CH353L chip and built in 
parallel port. When I load parport_pc, It sucessfully finds built in 
parallel port but does not recognize the card. If I specify ports for 
the card and built in pport, It successfully finds my card but not the 
built in pport.

When I look at parport_pc_init function:

3296         if (io[0]) {
3297                 int i;
3298                 /* Only probe the ports we were given. */
3299                 user_specified = 1;
3300                 for (i = 0; i < PARPORT_PC_MAX_PORTS; i++) {
3301                         if (!io[i])
3302                                 break;
3303                         if (io_hi[i] == PARPORT_IOHI_AUTO)
3304                                 io_hi[i] = 0x400 + io[i];
3305                         parport_pc_probe_port(io[i], io_hi[i],
3306                                         irqval[i], dmaval[i], NULL, 0);
3307                 }
3308         } else
3309                 parport_pc_find_ports(irqval[0], dmaval[0])

it is autodetecting only if i don't specify ports. Why not search for 
specified ports and do autodetect?

if I do something like this:

(Continue reading)

Sebastian Andrzej Siewior | 4 Dec 21:08 2013
Picon

[PATCH] parport: parport_pc: fix id print of a device

Since commit 7106b4e3 ("8250: Oxford Semiconductor Devices") the debug
print of the device id does no longer match the real device if it is
located in the "enum" behind oxsemi_pcie_pport. The reason is that the
code assumes that each id contains one entry in the PCI table.
The fix is to lookup the currently used id from the id-> parameter.

Cc: Lee Howard <lee.howard <at> mainpine.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy <at> linutronix.de>
---
 drivers/parport/parport_pc.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index b0a0d53..3cdb60d 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -2817,16 +2817,12  <at>  <at>  static int parport_pc_pci_probe(struct pci_dev *dev,
 		if (irq == IRQ_NONE) {
 			printk(KERN_DEBUG
 	"PCI parallel port detected: %04x:%04x, I/O at %#lx(%#lx)\n",
-				parport_pc_pci_tbl[i + last_sio].vendor,
-				parport_pc_pci_tbl[i + last_sio].device,
-				io_lo, io_hi);
+				id->vendor, id->device, io_lo, io_hi);
 			irq = PARPORT_IRQ_NONE;
 		} else {
 			printk(KERN_DEBUG
 	"PCI parallel port detected: %04x:%04x, I/O at %#lx(%#lx), IRQ %d\n",
-				parport_pc_pci_tbl[i + last_sio].vendor,
-				parport_pc_pci_tbl[i + last_sio].device,
(Continue reading)

Sebastian Andrzej Siewior | 27 Nov 17:43 2013
Picon

[PATCH] parport: parport_pc: remove double PCI ID for NetMos

In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added
the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which
was at the v2.4.26 time frame. The patch made into 2.6.14.
Shortly before that patch akpm merged commit 296d3c783b ("[PATCH] Support
NetMOS based PCI cards providing serial and parallel ports") which made
into v2.6.9-rc1.
Now we have two different entries for the same PCI id.
I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode.
This patch takes Max's entry for titan_1284p1 (base != -1 specifies the
ioport for ECP mode) and replaces akpm's entry for netmos_9805 which
specified -1 (=none). Both share the same PCI-ID (my card has subsystem
0x1000 / 0x0020 so it should match PCI_ANY).

While here I also drop the entry for titan_1284p2 which is the same as
netmos_9815.

Cc: Maximilian Attems <maks <at> stro.at>
Cc: Andrew Morton <akpm <at> linux-foundation.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy <at> linutronix.de>
---
 drivers/parport/parport_pc.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 903e128..b0a0d53 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -2596,8 +2596,6  <at>  <at>  enum parport_pc_pci_cards {
 	syba_2p_epp,
 	syba_1p_ecp,
(Continue reading)


Gmane