> However, I'm not too sure that I'm happy about this situation:
>
> - client negotiates to ECP mode
> - FIFO fills up
> - client asks for 1 byte of data.
> - we block the FIFO and read it all in, giving 1 byte back to
> application
> - client terminates back to compatibility mode
> [... another client comes along, and goes... ]
> - client negotiates back to ECP mode and asks for data
> - we give it the data we remembered from before
>
> I think we need to forget the data once the client has terminated back
> to compatibility mode. The reason is that there are some things (like
> device ID) which are defined like this.
I agree with you with the fact that we have to forget the data when
client goes back to compatible mode.
I was thinking about saving FIFO residue for the following kind of
situation :
- client negociates to ECP mode
- client calls parport_pc_ecp_read_block_pio
- parport_pc_ecp_read_block_pio negociates to ECP reverse idle
- FIFO fills up
- we block the FIFO and read it all in, giving what the client requested
and saving the residue
- parport_pc_ecp_read_block_pio goes to ECP forward idle
- (client optionally sends data)
- client either asks for more, we first give back the residue
The reason for this is the following. I have an IEEE1284 peripheral
(homemade) which sends a stream of data (mainly images) to the computer.
There is no way for the PC to know how much data is available.
I have to agree that the protocol is quite broken, but I didn't choose
it myself and can't change it.
What I'd like to do is to read as much data as possible when idle or out
of data, filling a buffer, and then process the data. The read/write
operations are asynchronous (I dream of a full duplex parallel port :-).
Saving the FIFO residue for a later call to
parport_pc_ecp_read_block_pio seems to me to be the only way to get the
result I want. parport_pc_ecp_read_block_pio would be trigered by the
parport_irq when data would be available, and I would fill my driver's
internal buffer with the data until the buffer is full. The parallel
port wouldn't be released between operations.
I'm open to any comment.
Cheers,
Laurent Pinchart
-- 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 : Tue Jun 12 2001 - 04:57:56 EDT