Nicolas Souchu (nsouch@teaser.fr)
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
>actually enforced).
>
>The SPI in 1284.3 looks like:
>
>SPI_Initialize
>SPI_GetDeviceNumber
>SPI_GetDeviceCoordinates
>SPI_GetDeviceID
>SPI_Open
>SPI_IO
>SPI_Close
>SPI_Lock
>SPI_Unlock
>SPI_QueryCapabilities
>
>The interface that parport will provide will probably look like this, in
>approximately the same order:
>
>parport_init
>parport_device_num
>parport_device_coord
>parport_device_id
>parport_register_device
>parport_negotiate
>parport_read
>parport_write
>parport_unregister_device
>parport_claim
>parport_release
>parport_capabilities
>
>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
>access.
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.
>
>Tim.
>*/
>
>
-- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org-- 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 Wed 30 Dec 1998 - 10:18:53 EST