On Wed, Oct 10, 2001 at 04:21:22PM -0400, Dave Strauss wrote:
> On Wed, 10 Oct 2001 10:27:08 +0100, Tim Waugh <twaugh@redhat.com> wrote:
> > "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.
>
> 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);
[...]
> 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.
Yes, that's the theory. Won't that work in parallel port FIFO mode as
well? Admittedly, this is the 'host recovery at event 35' plan, so is
specifically for ECP. But there doesn't seem to be any other
solution. As Phil said, we're explicitly not allowed to do what we
currently are doing, which is to change mode straight from PPF or ECP
to TST.
Incidentally, it's nStrobe we want to drive low, not STROBE, so I
think it should probably be:
parport_frob_control (port, PARPORT_CONTROL_STROBE,
PARPORT_CONTROL_STROBE);
Does that make things any better? It would be great to have someone
test that.
Tim.
*/
-- 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 : Thu Oct 25 2001 - 05:24:18 EDT