Nicolas Souchu (firstname.lastname@example.org)
Fri, 11 Dec 1998 22:42:49 +0000
On Wed, Dec 09, 1998 at 08:55:56PM +0000, Tim Waugh wrote:
>> >For some reason, the SPI in 1284-1994 says that the list of modes that
>> >SPI_IO understands (for its 'mode' parameter) includes both ECP and
>> >ECP-with-software-emulation. Weird.
>> I haven't read it in depth yet. Could this interface stand for a common
>> interface to FreeBSD and Linux? This would hide our differences and let
>> us share drivers, at least in ECP mode.
>I'm not sure it would really work that way. 1284.3 provides a "service
>provider interface" which is just an abstract interface. The meanings may
>stay the same, but the actual source code will likely be different for
>different implementations. The Linux implementation probably won't be
>100% compatible in meaning actually -- 1284.3 allows concurrent read
>operations, which would be difficult with the sharing model we have.
>A brief overview: drivers register their devices with a parport, and must
>claim the parport before use, and release it afterwards. When a driver
>has claimed a port, it has exclusive access (although this is not
>The SPI in 1284.3 looks like:
>The interface that parport will provide will probably look like this, in
>approximately the same order:
>It's mostly the same in meaning, but there are differences. SPI_IO is
>broken up into claiming, negotiating, reading, writing, and releasing.
>Also, 1284.3 says that SPI_Lock and SPI_Unlock are optional. That doesn't
>really fit well with our sharing model, which only grants exclusive
Ok, but we could write SPI functions. I'm pretty sure OfficeJet drivers
will do SPI-like calls for example.
Are all the parport_xxx calls needed by upper drivers if the later always have
to call all of them in the same way?
>I don't know how well that compares to the way ppbus does things...
Fairly like parport. IEEE1284.3 is not supported though.
-- email@example.com / firstname.lastname@example.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
-- To unsubscribe, send mail to: email@example.com -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:53 EST