On Thu, 9 Mar 2000, Greg Nelson wrote:
> 1) What specifically are the problems regarding the FIFO? I have a
> set of specs and datasheets that I can consult to see if these can
> be resolved.
When we're in the reading path, and using the FIFO, the user has told us
how many bytes we can return. So if the peripheral is sending us a
constant stream of data (and we don't know if this is the case), we'll
have to tell it to shut up after a certain point.
But in the datasheets I've been looking at, there doesn't seem to be a way
to tell the chipset to stop accepting data into the FIFO while we read out
the contents. So we have this situation:
FIFO
read 3 bytes |***-------| peripheral has more to send (O)
got 1 byte |**OO------| sent 2 bytes
got another |*OO-------|
and another |OO--------|
reset FIFO (empty)
We lost data. Even if we read out all of the data in the FIFO before we
reset, there's nothing to stop the peripheral filling it up again as we
read it out.
Do you see the problem now?
> 2) What is the status of the parport_pc_ecp_read_block_pio() code? Is
> it up-to-date with the rest of the driver and simply unused, or do
> I need to do something to bring it up-to-date?
I think it's up to date.
> 3) Can it be installed as the ecp_read_data handler in the same way
> that is done for write?
Yes.
> 4) Is anyone else working on this so I could coordinate with them to
> avoid stepping on toes?
I haven't been. I have no ECP peripherals to test with. :-( I don't know
about anyone else.
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 : Fri Mar 10 2000 - 05:05:41 EST