Eugene Weiss (eweiss@sas.upenn.edu)
Tue, 15 Feb 2000 21:25:53 -0500
> Odd. I've checked a couple of datasheets and I can't find anything like
> this.
>
> When failing to switch to mode 001, what are the high bits of ECR? Can
> you write a small test case for us to try just using inb/outb? I'd like
> to see if this is model- or vendor-specific.
The port responds to tests exactly as it should, returning a value of 0xff when
the direction is set to inward. It's just that it keeps this value even when
the device places a value on the lines, and will return the last value output
when the direction is reset to outward. The behavior is invisible unless there
is an actual device trying to send data, so I can't write a test routine that
demonstrates it. I'm certain that it is a model - specific problem, since most
of my testers didn't report it. And a couple of people from the parport list
emailed me to say that they had experienced problems with printers interacting
with other devices on Winbond ports. One suggested that I remove all parport
related modules before scanning, and another advised that I give up on the
Winbond port, and get a parallel port card.
The relevant ecr values are:
after bootup with parport in the kernel: 0x35
after lp is invoked as above, or after bootup with parport and parport_pc as
modules: 0x05;
Writing a value of 0x25 doesn't make the port work.
Writing a value of 0x35 does.
writing a value of 0x10, followed by 0x20 doesn't work.
after a value of 0x35 is written, writing 0x05, or 0x15, doesn't cause the
problem to reappear, so it must need some combination of ecr and control
register writes in order to induce it.
I suppose a no-tears solution might be to have lp save the ecr state when it
begins, and restore it before exiting.
It might be worth noting that this port doesn't play nice with ppdev (at least
with the 2.2.14 version), and deviceid 0.1 returns "device not IEEE 1284
compliant"; which is additional evidence that this is a hardware quirk.
>
> Incidentally, I've never actually verified that the parport_pc code
> complies with any of these rules, and I suspect that it doesn't. If
> someone has some spare time they don't know what to do with...
It does:
if (mode >= 2 && m >= 2) {
/* We have to go through mode 001 */
oecr &= ~(7 << 5);
oecr |= ECR_PS2 << 5;
outb (oecr, ecr);
}
-Eugene
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Tue 15 Feb 2000 - 21:33:13 EST