On Wed, 10 Oct 2001 10:27:08 +0100, Tim Waugh <twaugh@redhat.com> wrote:
>
> On Sun, Sep 16, 2001 at 10:56:47PM +0100, Philip Blundell wrote:
>
> > It's worth pointing out that the trick of using test mode to measure
> > the FIFO occupancy isn't explicitly sanctioned by any datasheet I've
> > read. And, indeed, they do normally state that you should only
> > change mode when the FIFO is empty.
>
> "The Microsoft Document" suggests driving nStrobe low to prevent
> further data transfers "even if the peripheral starts accepting
> data". Then fill the FIFO, and for PWord>1, go to mode 001 and see
> what cnfgA says in the low bit pair.
>
> Does that sound a better plan?
>
> Tim.
>
I'm not quite sure I understand exactly what you're proposing; would
it be something like this (in parport_pc_ecp_write_block_pio()):
. . .
if (change_mode (port, ECR_PS2) == -EBUSY) {
const struct parport_pc_private *priv =
port->physport->private_data;
printk (KERN_DEBUG "%s: FIFO is stuck\n", port->name);
/* Prevent further data transfer. */
REMOVE-- frob_econtrol (port, 0xe0, ECR_TST << 5);
ADD++ parport_frob_control(port, PARPORT_CONTROL_STROBE, 0);
/* Adjust for the contents of the FIFO. */
for (written -= priv->fifo_depth; ; written++) {
if (inb (ECONTROL (port)) & 0x2)
/* Full up. */
break;
outb (0, FIFO (port));
}
. . .
I would need to add some code at the end of the loop to deal with
Pword != 1 byte, but for my current hardware that's not an issue.
The theory here is that the host can't transfer a(nother) byte while
nStrobe is low, right? Of course this only works in ECP mode.
Anyway, I tried this and it's no better.
I suspect at least part of the problem occurs because the hardware
is doing all the handshaking and there's no way to know what state
the channel is in when we decide to time out.
-- Dave Strauss
-- 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 2b29 : Wed Oct 10 2001 - 16:22:52 EDT