Programming interface

Claims access to the port. As a user-land device driver writer, you will need to do this before you are able to actually change the state of the parallel port in any way. Note that some operations only affect the ppdev driver and not the port, such as PPSETMODE; they can be performed while access to the port is not claimed.

Instructs the kernel driver to forbid any sharing of the port with other drivers, i.e. it requests exclusivity. The PPEXCL command is only valid when the port is not already claimed for use, and it may mean that the next PPCLAIM ioctl will fail: some other driver may already have registered itself on that port.

Most device drivers don't need exclusive access to the port. It's only provided in case it is really needed, for example for devices where access to the port is required for extensive periods of time (many seconds).

Note that the PPEXCL ioctl doesn't actually claim the port there and then---action is deferred until the PPCLAIM ioctl is performed.

Releases the port. Releasing the port undoes the effect of claiming the port. It allows other device drivers to talk to their devices (assuming that there are any).

Yields the port to another driver. This ioctl is a kind of short-hand for releasing the port and immediately reclaiming it. It gives other drivers a chance to talk to their devices, but afterwards claims the port back. An example of using this would be in a user-land printer driver: once a few characters have been written we could give the port to another device driver for a while, but if we still have characters to send to the printer we would want the port back as soon as possible.

It is important not to claim the parallel port for too long, as other device drivers will have no time to service their devices. If your device does not allow for parallel port sharing at all, it is better to claim the parallel port exclusively (see PPEXCL).

Performs IEEE 1284 negotiation into a particular mode. Briefly, negotiation is the method by which the host and the peripheral decide on a protocol to use when transferring data.

An IEEE 1284 compliant device will start out in compatibility mode, and then the host can negotiate to another mode (such as ECP).

The ioctl parameter should be a pointer to an int; values for this are in incluce/linux/parport.h and include:

• IEEE1284_MODE_COMPAT

• IEEE1284_MODE_NIBBLE

• IEEE1284_MODE_BYTE

• IEEE1284_MODE_EPP

• IEEE1284_MODE_ECP

The PPNEGOT ioctl actually does two things: it performs the on-the-wire negotiation, and it sets the behaviour of subsequent read/write calls so that they use that mode (but see PPSETMODE).

Sets which IEEE 1284 protocol to use for the read and write calls.

The ioctl parameter should be a pointer to an int.

Retrieves the time-out value. The read and write calls will time out if the peripheral doesn't respond quickly enough. The PPGETTIME ioctl retrieves the length of time that the peripheral is allowed to have before giving up.

The ioctl parameter should be a pointer to a struct timeval.

Sets the time-out. The ioctl parameter should be a pointer to a struct timeval.

Sets the control lines. The ioctl parameter is a pointer to an unsigned char, the bitwise OR of the control line values in include/linux/parport.h.

Returns the last value written to the control register, in the form of an unsigned char: each bit corresponds to a control line (although some are unused). The ioctl parameter should be a pointer to an unsigned char.

This doesn't actually touch the hardware; the last value written is remembered in software. This is because some parallel port hardware does not offer read access to the control register.

The control lines bits are defined in include/linux/parport.h:

• PARPORT_CONTROL_STROBE

• PARPORT_CONTROL_AUTOFD

• PARPORT_CONTROL_SELECT

• PARPORT_CONTROL_INIT

Frobs the control lines. Since a common operation is to change one of the control signals while leaving the others alone, it would be quite inefficient for the user-land driver to have to use PPRCONTROL, make the change, and then use PPWCONTROL. Of course, each driver could remember what state the control lines are supposed to be in (they are never changed by anything else), but in order to provide PPRCONTROL, ppdev must remember the state of the control lines anyway.

The PPFCONTROL ioctl is for "frobbing" control lines, and is like PPWCONTROL but acts on a restricted set of control lines. The ioctl parameter is a pointer to a struct ppdev_frob_struct:

	
struct ppdev_frob_struct {
        unsigned char mask;
        unsigned char val;
};
	
       

The mask and val fields are bitwise ORs of control line names (such as in PPWCONTROL). The operation performed by PPFCONTROL is:

	
	new_ctr = (old_ctr & ~mask) | val;
       

In other words, the signals named in mask are set to the values in val.

Returns an unsigned char containing bits set for each status line that is set (for instance, PARPORT_STATUS_BUSY). The ioctl parameter should be a pointer to an unsigned char.

Controls the data line drivers. Normally the computer's parallel port will drive the data lines, but for byte-wide transfers from the peripheral to the host it is useful to turn off those drivers and let the peripheral drive the signals. (If the drivers on the computer's parallel port are left on when this happens, the port might be damaged.)

This is only needed in conjunction with PPWDATA or PPRDATA.

The ioctl parameter is a pointer to an int. If the int is zero, the drivers are turned on (forward direction); if non-zero, the drivers are turned off (reverse direction).

Sets the data lines (if in forward mode). The ioctl parameter is a pointer to an unsigned char.

Reads the data lines (if in reverse mode). The ioctl parameter is a pointer to an unsigned char.

Clears the interrupt count. The ppdev driver keeps a count of interrupts as they are triggered. PPCLRIRQ stores this count in an int, a pointer to which is passed in as the ioctl parameter.

In addition, the interrupt count is reset to zero.

Set a trigger response. Afterwards when an interrupt is triggered, the interrupt handler will set the control lines as requested. The ioctl parameter is a pointer to an unsigned char, which is interpreted in the same way as for PPWCONTROL.

The reason for this ioctl is simply speed. Without this ioctl, responding to an interrupt would start in the interrupt handler, switch context to the user-land driver via poll or select, and then switch context back to the kernel in order to handle PPWCONTROL. Doing the whole lot in the interrupt handler is a lot faster.