Thomas Sailer (sailer@ife.ee.ethz.ch)
Fri, 07 May 1999 13:31:05 +0200
Tim Waugh wrote:
> I'd appreciate comments on it. I don't really want to go and make the
> changes only to find out that they're not useful. ;-)
Ok :-)
omitting read/write/from econtrol would make things easier :-)
I'm glad to see that you intend to differentiate ports by their
number and not by their IO address. The "IO Address" as unique
identification number is going to have problems anyway.
{claim,yield}_or_block: are they blocking interruptibly or
uninterruptibly?
What do we need write_status for?
I'm glad you want the epp routines to take a block of bytes,
I was going to suggest that anyway :-)
get_residue: can't this be folded into the ecp routines? The problem
is that if a parport implementation has a different FIFO strategy
than M$ reference implementation, emulating that "functionality"
is going to be funny, to say it nicely.
Also, isn't the data and the address FIFO a distinct entity, or
have I understood something wrongly?
Who is handling direction switching for ECP? ecp_{read,write}_*
implicitly?
Now why am I asking this?
I recently bought an USB<->IEEE1284 cable that uses a
Lucent USS720 chip. When driving a printer, the chip
has an "automatic mode" that emulates an USB printer,
so no specific driver is needed.
It also has a "manual mode" where software can directly
manipulate a fairly standard set of parport registers
via USB control transfers.
And that leads to the first problem: while it is
easy to emulate eg. parport_write_control, it has
to be called from a process context, it may not
be called from an interrupt routine nor a BH.
Since the port is attached to the USB host controller
(and multiple cables may be), it doesn't have an
"IO address", so distinguishing ports by IO address
doesn't work.
Roughly the same goes for interrupts. It supports interrupts,
but doesn't have an associated "hardware" IRQ (it goes indirectly
via the USB host controller interrupt), so how do I signal
higher level drivers that this port has interrupts, but the
procfs code should not even think of trying to change interrupt
numbers?
Then, the ECP FIFO strategy is quite different from
that of M$ reference design. The controller
utilizes USB bulk pipe FIFO's for ECP IO, so I don't
quite see right now how I should emulate your get_fifo_residue
Tom
-- 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 Fri 07 May 1999 - 07:32:27 EDT