Lines Matching refs:I
4 Device Driver I/O Support Routines
16 I/O access method. This gives relief to the device drivers as they don't
19 I/O (PIO), and other hardware features more. However, this implies that
20 either every single device driver needs to implement the hardware I/O
29 In order to build common device support for ESA/390 I/O interfaces, a
30 functional layer was introduced that provides generic I/O access methods to
33 The common device support layer comprises the I/O support routines defined
64 enable a device, allowing for I/O interrupts.
67 initiate an I/O request.
73 terminate the current I/O request processed on the device.
77 routine whenever an I/O interrupt is presented to the system. The do_IRQ()
79 interrupt handler according to the rules (flags) defined during I/O request
95 The following chapters describe the I/O related interface routines the
116 they are presenting I/O completion a unified way : I/O interruptions. Every
131 In order not to introduce a new I/O concept to the common Linux code,
142 types that imply specific I/O commands (channel command words - CCWs) in
159 In order to allow for easy I/O initiation the CDS layer provides a do_IO()
162 an I/O request on behalf of the device driver. The do_IO() routine allows for
163 different I/O methods, synchronous and asynchronous, and allows to specify
166 to allow for overlapped I/O processing. See do_IO() for more details. A device
167 driver must never issue ESA/390 I/O commands itself, but must use the
170 For long running I/O request to be canceled, the CDS layer provides the
172 (HSCH) command without having pending I/O requests. This function is also
220 During system startup - init_IRQ() processing - the generic I/O device support
277 The ESA/390 I/O architecture defines certain device specific I/O functions.
312 call request_irq() prior to be able to issue any I/O request for it, including
315 Please see the "ESA/390 Common I/O-Commandss and Self Description" manual,
352 able to properly react on interrupts related to the read_dev_chars() I/O
376 -EBUSY - an irrecoverable I/O error occurred or the device is not
398 device dependent I/O commands for the device specific layout of the node
423 -EIO - An irrecoverable I/O error occured or the device is
493 must preserve for later usage. I.e. it must not be released prior to a call
505 solicited I/O request. The device driver must be able to handle this situation
510 I/O device driver support layer. The device driver's interrupt handler must
585 became invalid (native, LPAR). In order to prevent further I/O the IRQ was
606 preserve for later usage. I.e. it must not be released prior to a call to
625 solicited I/O request. The device driver must be able to handle this situation
630 platform specific common I/O support layer. The device driver's interrupt
649 Unfortunately the free_irq() is defined not to return error codes. I.e. if
668 one-to-one, this may require more extensive I/O processing than anticipated,
679 -EBUSY - device (subchannel) is currently processing an I/O
720 -EBUSY - device (subchannel) is currently processing an I/O
728 do_IO() - Initiate I/O Request
730 The do_IO() routines is the I/O request front-end processor. All device driver
731 I/O requests must be issued using this routine. A device driver must not issue
732 ESA/390 I/O commands itself. Instead the do_IO() routine provides all
737 with the associated I/O request when calling do_IO().
745 irq : irq (subchannel) the I/O request is destined for
750 particular I/O request.
751 lpm : defines the channel path to be used for a specific I/O
753 flag : defines the action to e parformed for I/O processing
797 device is currently processing a previous I/O request
805 When the I/O request completes, the CDS first level interrupt handler will
809 device driver has associated with a particular I/O request. If a pending
811 may happen during I/O initiation or delayed by an alert status notification.
812 In any case this status is not related to the current (last) I/O request. In
814 to indicate I/O completion as the I/O request was never started, even though
825 DEVSTAT_STATUS_PENDING - a pending status was found. The I/O
831 I/O requst identified by intparm.
893 I/O mask value in the PSW must be disabled. This can be accomplished by calling
910 I/O interrupts (see above) already. Option (ii) obtains the device gate und
911 puts the CPU into I/O disabled state by preserving the current PSW flags.
918 similar needs to be scheduled. During I/O processing the Linux/390 generic
919 I/O device driver support has already obtained the IRQ lock, i.e. the handler
926 I/O request processing. All I/O devices, but the console device are driven
929 I/O completion. As this special ISC is gated, all sync. requests in a SMP
947 If a device driver relies on an I/O request to be completed prior to start the
948 next it can reduce I/O processing overhead by chaining a NoOp I/O command
952 busy, not being able to process I/O requests for other devices on the same
956 In order to minimize I/O overhead, a device driver should use the
959 case all I/O interruptions are presented to the device driver until final
962 If a device is able to recover from asynchronosly presented I/O errors, it can
963 perform overlapping I/O using the DOIO_EARLY_NOTIFICATION flag. While some
966 ready for the next I/O request and secondary status (device-end) when the data
970 can handle lost data on the network to allow for enhanced I/O processing.
974 presented to the device driver while overlapping I/O is performed. When a
991 (CCW) must start the I/O operation with the DOIO_ALLOW_SUSPEND option or the
1013 -ENOTCONN - there is no I/O request pending for completion
1019 halt_IO() - Halt I/O Request Processing
1023 a halt subchannel (HSCH) I/O command. For those purposes the halt_IO() command
1031 intparm : interruption parameter; value is only used if no I/O
1033 the I/O request is returned
1039 -EBUSY - the device is currently performing a synchronous I/O
1058 We don't allow to stop sync. I/O requests by means of a halt_IO() call. The
1102 for interrupts during I/O interrupt handling or in case of a panic() message