Tim Waugh (tim@cyberelk.demon.co.uk)
Wed, 9 Dec 1998 20:55:56 +0000 (GMT)
On Wed, 9 Dec 1998, Nicolas Souchu wrote:
> >I meant for the reverse channel -- it might only speak compatibility mode
> >and ECP mode. Software-emulated ECP-write is only really justifiable with
> >your examples:
>
> NIBBLE mode is mandatory for the Device-ID sequence.
Oh yeah. Hadn't thought of that.
> >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.
I don't know how well that compares to the way ppbus does things...
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 2.0b3 on Wed 30 Dec 1998 - 10:18:53 EST