Lines Matching refs:device
13 This document describes the common device support routines for Linux/390.
15 I/O access method. This gives relief to the device drivers as they don't
19 either every single device driver needs to implement the hardware I/O
22 every single device driver would have to provide itself.
28 In order to build common device support for ESA/390 I/O interfaces, a
32 The common device support layer comprises the I/O support routines defined
33 below. Some of them implement common Linux device driver interfaces, while
50 * The channel device layer is gone.
70 terminate the current I/O request processed on the device.
75 routine determines the interrupt status and calls the device specific
81 first level interrupt handler only and does not comprise a device driver
83 describes the input to the device specific interrupt handler.
93 Linux/390 common device support (CDS) provides to allow for device specific
95 intend to provide the functionality required by every device driver
96 implementation to allow to drive a specific hardware device on the ESA/390
114 single device is uniquely identified to the system by a so called subchannel,
125 has to call every single device driver registered on this IRQ in order to
126 determine the device driver owning the device that raised the interrupt.
130 device drivers should use the new calling interface via the ccw_device only.
135 subchannel also takes a user defined attribute, the so called device number.
136 Both subchannel number and device number cannot exceed 65535. During sysfs
137 initialisation, the information about control unit type and device types that
139 the device are gathered. Device drivers can retrieve this set of hardware
144 applicable, the device drivers can use issue the READ DEVICE CHARACTERISTICS
145 ccw to retrieve device characteristics in its online routine.
148 ccw_device_start() interface that takes a device specific channel program (one
150 and initiates an I/O request on behalf of the device driver. The
152 to notify the device driver for every interrupt it observes, or with final status
153 only. See ccw_device_start() for more details. A device driver must never issue
164 This call enables a device driver to get information about supported commands
174 NULL - No extended data available, invalid device or command not found.
181 device driver I/O requests must be issued using this routine. A device driver
185 This description also covers the status information passed to the device
217 back to the device driver's interrupt handler. Allows a
218 device driver to associate the interrupt with a
257 Via ccw_device_set_options(), the device driver may specify the following
258 options for the device:
267 -EBUSY - The device is currently processing a previous I/O request, or there is
268 a status pending at the device.
269 -ENODEV - cdev is invalid, the device is not operational or the ccw_device is
273 accumulate the status in a struct irb and then call the device interrupt handler.
274 The intparm field will contain the value the device driver has associated with a
275 particular I/O request. If a pending device status was recognized,
282 The irb may contain an error value, and the device driver should check for this
290 set, the field erw.scnt in the esw describes the number of device specific
291 sense bytes available in the extended control word irb->scsw.ecw[]. No device
292 sensing by the device driver itself is required.
294 The device interrupt handler can use the following definitions to investigate
305 Depending on the device status, multiple of those values may be set together.
306 Please refer to the device specific documentation for details.
319 The irb->scsw.dstat field provides the (accumulated) device status :
326 DEV_STAT_DEV_END - device end
335 ccw_device_start() must be called disabled and with the ccw device lock held.
337 The device driver is allowed to issue the next ccw_device_start() call from
341 I/O device driver support has already obtained the IRQ lock, i.e. the handler
345 If a device driver relies on an I/O request to be completed prior to start the
354 In order to minimize I/O overhead, a device driver should use the
355 DOIO_REPORT_ALL only if the device can report intermediate interrupt
356 information prior to device-end the device driver urgently relies on. In this
357 case all I/O interruptions are presented to the device driver until final
360 If a device is able to recover from asynchronously presented I/O errors, it can
362 devices always report channel-end and device-end together, with a single
364 ready for the next I/O request and secondary status (device-end) when the data
365 transmission has been completed at the device.
372 presented to the device driver while overlapping I/O is performed. When a
385 If a device driver chooses to suspend the current channel program execution by
408 Sometimes a device driver might need a possibility to stop the processing of
409 a long-running channel program or the device might require to initially issue
413 ccw_device_halt() must be called disabled and with the ccw device lock held.
426 -EBUSY - the device is currently busy, or status pending.
428 -EINVAL - The device is not operational or the ccw device is not online.
432 A device driver may write a never-ending channel program by writing a channel
435 device drivers by setting the PCI CCW flag (CCW_FLAG_PCI). Once this CCW is
436 executed a program controlled interrupt (PCI) is generated. The device driver
438 read to a network device (with or without PCI flag) a ccw_device_halt()
446 ccw_device_clear() must be called disabled and with the ccw device lock held.
457 -EINVAL - The device is not operational or the ccw device is not online.
461 This chapter describes various routines to be used in a Linux/390 device
466 Get the address of the device specific lock. This is then used in