Tim Waugh (tim@cyberelk.demon.co.uk)
Tue, 8 Dec 1998 19:37:39 +0000 (GMT)
On Tue, 8 Dec 1998, Thomas Sailer wrote:
> Ok. I've looked at your patch a bit more thoroughly,
> and it would also be quite easy to do what negotiate
> does but without negotiation :-)
Only if you make the functions non-static, which I'd rather not do. I'm
working on a patch, which I hope to be able to make available tonight.
I've changed my mind about ieee1284.ops ;-). I'm now adding a couple of
functions to port->ops.
> Another thing: You've already done the IMHO hard thing,
> namely doing ECP on a SPP, but surely we want to
> use the hardware ECP mode if available?!
Oops, that got in there by accident. That's for ECP software emulation
(IEEE1284_MODE_ECPSWE).
> At least in my application it doesn't make sense
> to use ECP when the hardware doesn't directly support it.
The only reason it would be necessary is if the peripheral ONLY speak ECP
mode, and we don't have the hardware for it.
> > But what if the peripheral changes the channel it talks to us on? It can
> > do that any time it likes.
>
> Is the peripherial allowed to do this? I thought address transfers
> are only defined in forward mode...
It is allowed to, if I read the standard correctly. Data and commands can
both come over the reverse channel, and table 2 lists the reverse channel
commands as:
Bit 7 Bits 6..0
0 Run-length count
1 Channel address
The proviso is that a channel address command issued from the peripheral
only affects the peripheral-to-host communication channel (i.e. the
reverse channel, and not the forward channel).
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 2.0b3 on Wed 30 Dec 1998 - 10:18:52 EST