lkml.org 
[lkml]   [2011]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets
Bastien ROUCARIES wrote:

> Why not check dmi years for this test and do the test only for board
> before 2000 ? Better safe than sorry

That would just leave the code broken on boards before 2000.

Here's a reference to the problem the test was supposed to fix:

http://lkml.indiana.edu/hypermail/linux/kernel/9901.2/1285.html

It says:

| A small number of IO chipsets do not have the EPP timeout function hence if
| there is no EPP device then the CPU is permantly in the HALT state and nothing
| happens LITERALLY! <CNTL><ALT><DEL> does not even function! The bulk (if not
| all) the IO chipsets in this category fail the bug check test, as a result it
| is assumed there is no EPP (or to dangerous to use). This may prevent some
| valid chipsets working properly.

It sounds like the test removed by [1] has false positives and false
negatives.

Jan Axelson's "Parallel Port Complete" recommends:

- first check for ECP as described in Microsoft's "Extended
Capabilities Port Protocol and ISA Interface Standard" document:

. First check for the presence of the ECR register, by checking
that bits 0 and 1 act like "empty" and "full" bits (so they
start out set and cleared respectively and after writing 0x34 you
can read back 0x35).

parport_ECR_present() does this and save the result to priv->ecr.

. Put the port in configuration mode by writing 0xf4 to the ECR,
etc (parport_ECP_supported() does these checks).

- if the above fails, then check for EPP. There are a couple of
choices suggested for that:

A) Write some values to one of the EPP registers and then read them
back. If nothing is plugged in there, that should provoke a
timeout; the spec doesn't say what you read back, but she found
that it would always read back what you wrote and that in practice
it worked for discovering EPP ports.

B) Check that the timeout bit (ECR bit 0) is set when a timeout occurs,
and then clear it. On some ports, just trying a transfer with
nothing plugged in will provoke a timeout, while on others ECR bit 7
needs to be set first. And of course there's more than one way to
clear it.

Intel's 82091 data sheet does not mention the timeout bit at all.
Maybe it doesn't implement it.

http://www.lvr.com/jansfaq.htm also mentions "Beware #1: on
SMC's chips (& maybe others), a set timeout bit can make the
port unusable in any mode, until a hard reset (or clearing the
bit)!" So one does have to make sure to clear the bit.

Would it make sense to switch to doing (A)? If not, is there some
test that can be used to detect an 82091 specifically (or are there
other chipsets that don't have the timeout bit)? Cc-ing Jan for
advice (thanks for your work in documenting what makes parallel ports
tick, Jan!).

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel/1191591


\
 
 \ /
  Last update: 2011-09-15 21:45    [W:1.567 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site