Re: [hpoj-devel] 2.4 kernel issues

[<pa...@rc...>]

Burkhard Kohl wrote:
> I think the debug messages were a bit misleading. I resolved this
> to be a failure during the transmit mode negotiation phase due 
> to the parport being set to reverse mode. This can be cured by
> inserting a 
> 	parport_data_forward(l->port);
> statement just before the 
> 	parDataWrite(l, ...);
> statement of event 0. (or inside the parDataWrite() function call).
> 
> But now the driver runs into another problem - the peripheral answers
> the hosts MLCConfigSocket command for socket 1 with MLCError 7 after
> a succesful MLCInit/InitReply pair

Hi, Burkhard.  MLC Error 7 means that a packet was received for a channel
that wasn't open, meaning that one or both of the first tso bytes of the
packet (in this case, the ConfigSocket command) was incorrect.  However,
your debug output seemed correct, so perhaps there's a timing issue
associated with the change you made (see above) which causes the data
lines not to be stable (i.e. not the value you wrote to them) when the
peripheral is trying to read them.  You could try putting a short delay
after writing the data lines and before setting nStrobe to 0 when sending
the data byte.

> From the parport driver sources I see that there is no BECP support 
> for now - do you expect to have it in the near future? In ieee12844pp.c
> there is actually only one event (41) referring to becp when switching
> from ecp reverse to forward when the peripheral is idle.
Bounded ECP mode is essentially regular ECP mode with some added restrictions
placed on the host and peripheral.  It's documented in the 1284.3 spec
(which may or may not be released yet).  For our purposes, I don't think
we actually need kernel support for it, since ieee12844pp.c is handling
all of the signalling itself.

David