Searched full:request (Results 1 – 25 of 744) sorted by relevance
12345678910>>...30
| /Documentation/userspace-api/media/mediactl/ |
| D | request-api.rst | 4 .. _media-request-api:
6 Request API
9 The Request API has been designed to allow V4L2 to deal with requirements of
19 Supporting these features without the Request API is not always possible and if
26 The Request API allows a specific configuration of the pipeline (media
31 of request completion are also available for reading.
36 The Request API extends the Media Controller API and cooperates with
37 subsystem-specific APIs to support request usage. At the Media Controller
39 node. Their life cycle is then managed through the request file descriptors in
42 request support, such as V4L2 APIs that take an explicit ``request_fd``
[all …]
|
| D | media-request-ioc-queue.rst | 13 MEDIA_REQUEST_IOC_QUEUE - Queue a request
31 If the media device supports :ref:`requests <media-request-api>`, then
32 this request ioctl can be used to queue a previously allocated request.
34 If the request was successfully queued, then the file descriptor can be
35 :ref:`polled <request-func-poll>` to wait for the request to complete.
37 If the request was already queued before, then ``EBUSY`` is returned.
38 Other errors can be returned if the contents of the request contained
40 common error codes. On error both the request and driver state are unchanged.
42 Once a request is queued, then the driver is required to gracefully handle
43 errors that occur when the request is applied to the hardware. The
[all …]
|
| D | media-request-ioc-reinit.rst | 13 MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
31 If the media device supports :ref:`requests <media-request-api>`, then
32 this request ioctl can be used to re-initialize a previously allocated
33 request.
35 Re-initializing a request will clear any existing data from the request.
37 request and allocate a new request. Instead the completed request can just
40 A request can only be re-initialized if it either has not been queued
51 The request is queued but not yet completed.
|
| D | media-ioc-request-alloc.rst | 13 MEDIA_IOC_REQUEST_ALLOC - Allocate a request
34 If the media device supports :ref:`requests <media-request-api>`, then
35 this ioctl can be used to allocate a request. If it is not supported, then
36 ``errno`` is set to ``ENOTTY``. A request is accessed through a file descriptor
39 If the request was successfully allocated, then the request file descriptor
45 In addition, the request can be queued by calling
49 Finally, the file descriptor can be :ref:`polled <request-func-poll>` to wait
50 for the request to complete.
52 The request will remain allocated until all the file descriptors associated
54 longer uses the request internally. See also
[all …]
|
| D | request-func-close.rst | 2 .. c:namespace:: MC.request
7 request close()
13 request-close - Close a request file descriptor
33 Closes the request file descriptor. Resources associated with the request
34 are freed once all file descriptors associated with the request are closed
35 and the driver has completed the request.
36 See :ref:`here <media-request-life-time>` for more information.
|
| D | request-func-ioctl.rst | 7 request ioctl()
13 request-ioctl - Control a request file descriptor
31 The request ioctl command code as defined in the media.h header file, for
35 Pointer to a request-specific structure.
40 The :ref:`ioctl() <request-func-ioctl>` function manipulates request
43 The ioctl ``cmd`` code specifies the request function to be called. It
47 Macros and structures definitions specifying request ioctl commands and
48 their parameters are located in the media.h header file. All request ioctl
|
| D | media-funcs.rst | 21 media-ioc-request-alloc
22 request-func-close
23 request-func-ioctl
24 request-func-poll
25 media-request-ioc-queue
26 media-request-ioc-reinit
|
| D | media-func-ioctl.rst | 22 ``int ioctl(int fd, int request, void *argp)``
30 ``request``
31 Media ioctl request code as defined in the media.h header file, for
35 Pointer to a request-specific structure.
43 The ioctl ``request`` code specifies the media function to be called. It
59 Request-specific error codes are listed in the individual requests
|
| D | request-func-poll.rst | 7 request poll()
13 request-poll - Wait for some event on a file descriptor
40 for a request to complete.
45 is non-zero). Request file descriptor set the ``POLLPRI`` flag in ``revents``
46 when the request was completed. When the function times out it returns
50 Attempting to poll for a request that is not yet queued will
|
| /Documentation/driver-api/mmc/ |
| D | mmc-async-req.rst | 2 MMC Asynchronous Request
12 preparations for the next request are done in parallel with the current
16 time between when an MMC request ends and another MMC request begins.
21 MMC request.
30 a request and how fast the memory is. The faster the MMC/SD is the
31 more significant the prepare request time becomes. Roughly the expected
47 It starts a new MMC command request for a host. The function isn't
48 truly non-blocking. If there is an ongoing async request it waits
49 for completion of that request and starts the new one and returns. It
50 doesn't wait for the new request to complete. If there is no ongoing
[all …]
|
| /Documentation/driver-api/surface_aggregator/ |
| D | internal.rst | 70 Above this sits the *request transport layer (RTL)*. This layer is centered
73 It, specifically, distinguishes events from request responses, matches
74 responses to their corresponding requests, and implements request timeouts.
77 how request responses and, especially, events are dealt with. It provides an
79 workqueue for event and asynchronous request completion, and also manages
217 the request transport layer.
267 somewhat special. It is either set when the upper layer request is submitted
288 Request Transport Layer
291 The request transport layer is represented via |ssh_rtl| and builds on top
297 the corresponding callback. The request transport layer is structured around
[all …]
|
| /Documentation/admin-guide/nfs/ |
| D | nfs-idmapper.rst | 7 performing an upcall to userspace to request the information. There are two
8 ways NFS could obtain this information: placing a call to /sbin/request-key
11 NFS will attempt to call /sbin/request-key first. If this succeeds, the
12 result will be cached using the generic request-key cache. This call should
13 only fail if /etc/request-key.conf is not configured for the id_resolver key
14 type, see the "Configuring" section below if you wish to use the request-key
17 If the call to /sbin/request-key fails (if /etc/request-key.conf is not
26 The file /etc/request-key.conf will need to be modified so /sbin/request-key can
48 would edit your request-key.conf so it look similar to this:
57 request-key will find the first matching line and corresponding program. In
[all …]
|
| /Documentation/virt/kvm/ |
| D | vcpu-requests.rst | 10 KVM supports an internal API enabling threads to request a VCPU thread to
11 perform some activity. For example, a thread may request a VCPU to flush
12 its TLB with a VCPU request. The API consists of the following functions::
17 /* Check if VCPU @vcpu has request @req pending. */
20 /* Clear request @req for VCPU @vcpu. */
24 * Check if VCPU @vcpu has request @req pending. When the request is
31 * Make request @req of VCPU @vcpu. Issues a memory barrier, which pairs
32 * with another in kvm_check_request(), prior to setting the request.
36 /* Make request @req of all VCPUs of the VM with struct kvm @kvm. */
40 as possible after making the request. This means most requests
[all …]
|
| /Documentation/maintainer/ |
| D | pull-requests.rst | 23 the pull request on a separate branch. Typically you will base this branch
25 request to.
27 In order to create the pull request you must first tag the branch that you
33 Greg offers the following. A pull request with miscellaneous stuff for
48 you to describe the tag. In this case, you are describing a pull request,
52 merge the pull request. So write it up well, as it will be in the kernel
63 Note that if there is something odd about the pull request, that
72 I will take both what you write in the email pull request _and_ in
75 make it into the pull request email), or you can make the signed
77 the work later when you actually send me the pull request.
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-driver-ppi | 26 What: /sys/class/tpm/tpmX/ppi/request
30 This attribute shows the request for an operation to be
32 the OS to the pre-OS environment. The request should be an
33 integer value range from 1 to 160, and 0 means no request.
41 request it acted upon. The format is "<request> <response num>
59 This attribute shows whether it is allowed to request an
62 The format is "<request> <status num>: <status description>".
70 This attribute shows whether it is allowed to request an
|
| /Documentation/crypto/ |
| D | crypto_engine.rst | 23 crypto_async_request. It cannot know the underlying request type and thus only
36 Before transferring any request, you have to fill the context enginectx by
46 corresponding request is performed. If some processing or other preparatory
50 request is handled. Clean up / undo what was done in the prepare function.
52 * ``cipher_one_request``/``hash_one_request``: Handle the current request by
56 associated with the received request. You are able to retrieve the original
57 request by using:
76 At the end of the request process, a call to one of the following functions is needed:
|
| /Documentation/devicetree/bindings/dma/ |
| D | ti-dma-crossbar.txt | 1 Texas Instruments DMA Crossbar (DMA request router)
16 - ti,dma-safe-map: Safe routing value for unused request lines
17 - ti,reserved-dma-request-ranges: DMA request ranges which should not be used
18 when mapping xbar input to DMA request, they are either
23 When requesting channel via ti,dra7-dma-crossbar, the DMA client must request
27 dmas = <&edma_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC
53 /* Protect the sDMA request ranges: 10-14 and 100-126 */
54 ti,reserved-dma-request-ranges = <10 5>, <100 27>;
|
| /Documentation/virt/acrn/ |
| D | io-request.rst | 3 I/O request handling
6 An I/O request of a User VM, which is constructed by the hypervisor, is
8 corresponding to the address range of the I/O request. Details of I/O request
11 1. I/O request
15 communication between the hypervisor and Service VM. An I/O request is a
20 used as an array of 16 I/O request slots with each I/O request slot being 256
67 3. I/O request state transition
70 The state transitions of an ACRN I/O request are as follows.
76 - FREE: this I/O request slot is empty
77 - PENDING: a valid I/O request is pending in this slot
[all …]
|
| /Documentation/driver-api/surface_aggregator/clients/ |
| D | cdev.rst | 78 - ``REQUEST``
79 - Perform synchronous SAM request.
111 Executes a synchronous SAM request. The request specification is passed in
113 by the IOCTL to return status and result of the request.
115 Request payload data must be allocated separately and is passed in via the
120 completion of the request, the call will write the response to the response
124 Additionally, if the request has a response, this must be indicated via the
125 request flags, as is done with in-kernel requests. Request flags can be set
129 Finally, the status of the request itself is returned in the ``status``
131 indication of the IOCTL is separated from failure indication of the request:
[all …]
|
| /Documentation/userspace-api/media/cec/ |
| D | cec-func-ioctl.rst | 22 ``int ioctl(int fd, int request, void *argp)``
30 ``request``
31 CEC ioctl request code as defined in the cec.h header file, for
35 Pointer to a request-specific structure.
43 The ioctl ``request`` code specifies the cec function to be called. It
59 Request-specific error codes are listed in the individual requests
|
| /Documentation/block/ |
| D | ublk.rst | 28 ublk block device (``/dev/ublkb*``) is added by ublk driver. Any IO request
38 driver, thus completing the request cycle. This way, any specific IO handling
42 ``/dev/ublkb*`` is driven by blk-mq request-based driver. Each request is
46 Both the IO request forward and IO handling result committing are done via
50 implementation of userspace block device: not only IO request communication is
55 The interface is extendable and kabi compatible: basically any ublk request
105 such as ``nr_hw_queues``, ``queue_depth``, and max IO request buffer size,
112 related, or request queue limit related, but can't be IO logic specific,
217 double-write since the driver may issue the same I/O request twice. It
238 request of ``/dev/ublkb*``.
[all …]
|
| /Documentation/userspace-api/gpio/ |
| D | gpio-get-lineevent-ioctl.rst | 16 GPIO_GET_LINEEVENT_IOCTL - Request a line with edge detection from the kernel.
23 ``int ioctl(int chip_fd, GPIO_GET_LINEEVENT_IOCTL, struct gpioevent_request *request)``
31 ``request``
33 to request and its configuration.
38 Request a line with edge detection from the kernel.
80 On success 0 and the :c:type:`request.fd<gpioevent_request>` contains the file
81 descriptor for the request.
|
| /Documentation/power/ |
| D | pm_qos_interface.rst | 22 to the request list or elements of the list. For CPU latency QoS, the
23 aggregated target value is simply the min of the request values held in the list
46 removing the request.
52 Returns if the request is still active, i.e. it has not been removed from the
68 Only processes can register a PM QoS request. To provide for automatic
76 request on the parameter.
83 To remove the user mode request for a target value simply close the device
93 Values are updated in response to changes of the request list.
96 simply the minimum of the request values held in the parameter list elements.
121 removing the request.
[all …]
|
| /Documentation/filesystems/ |
| D | fuse.rst | 137 If a process issuing a FUSE filesystem request is interrupted, the
140 - If the request is not yet sent to userspace AND the signal is
141 fatal (SIGKILL or unhandled fatal signal), then the request is
144 - If the request is not yet sent to userspace AND the signal is not
145 fatal, then an interrupted flag is set for the request. When
146 the request has been successfully transferred to userspace and
147 this flag is set, an INTERRUPT request is queued.
149 - If the request is already sent to userspace, then an INTERRUPT
150 request is queued.
156 or may honor them by sending a reply to the *original* request, with
[all …]
|
| D | netfs_library.rst | 111 * Allow the netfs to expand a readahead request in both directions to meet its
117 interleaved for a single request.
157 The helpers manage the read request, calling back into the network filesystem
162 netfs_io_request struct allocated. If some parts of the request are in
163 progress when an error occurs, the request will get partially completed if
182 the read. The first is a structure that manages a read request as a whole::
212 to the helper functions or set during the request.
217 The file position of the start of the read request and the length. These
222 The size of the file at the start of the request.
236 request::
[all …]
|
12345678910>>...30