Re: [PARPORT] ECP FIFO residue

From: Laurent Pinchart (
Date: Tue Jun 12 2001 - 04:54:03 EDT

  • Next message: Laurent Pinchart: "Re: [PARPORT] ECP FIFO residue"

    > 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.


    Laurent Pinchart

    -- To unsubscribe, send mail to: --
    -- 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