Searched full:request (Results 1 – 25 of 556) sorted by relevance
12345678910>>...23
| /Documentation/media/uapi/mediactl/ |
| D | request-api.rst | 27 .. _media-request-api:
29 Request API
32 The Request API has been designed to allow V4L2 to deal with requirements of
42 Supporting these features without the Request API is not always possible and if
49 The Request API allows a specific configuration of the pipeline (media
54 of request completion are also available for reading.
59 The Request API extends the Media Controller API and cooperates with
60 subsystem-specific APIs to support request usage. At the Media Controller
62 node. Their life cycle is then managed through the request file descriptors in
65 request support, such as V4L2 APIs that take an explicit ``request_fd``
[all …]
|
| D | media-request-ioc-queue.rst | 36 MEDIA_REQUEST_IOC_QUEUE - Queue a request
56 If the media device supports :ref:`requests <media-request-api>`, then
57 this request ioctl can be used to queue a previously allocated request.
59 If the request was successfully queued, then the file descriptor can be
60 :ref:`polled <request-func-poll>` to wait for the request to complete.
62 If the request was already queued before, then ``EBUSY`` is returned.
63 Other errors can be returned if the contents of the request contained
65 common error codes. On error both the request and driver state are unchanged.
67 Once a request is queued, then the driver is required to gracefully handle
68 errors that occur when the request is applied to the hardware. The
[all …]
|
| D | media-request-ioc-reinit.rst | 36 MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
55 If the media device supports :ref:`requests <media-request-api>`, then
56 this request ioctl can be used to re-initialize a previously allocated
57 request.
59 Re-initializing a request will clear any existing data from the request.
60 This avoids having to :ref:`close() <request-func-close>` a completed
61 request and allocate a new request. Instead the completed request can just
64 A request can only be re-initialized if it either has not been queued
75 The request is queued but not yet completed.
|
| D | media-ioc-request-alloc.rst | 36 MEDIA_IOC_REQUEST_ALLOC - Allocate a request
59 If the media device supports :ref:`requests <media-request-api>`, then
60 this ioctl can be used to allocate a request. If it is not supported, then
61 ``errno`` is set to ``ENOTTY``. A request is accessed through a file descriptor
64 If the request was successfully allocated, then the request file descriptor
70 In addition, the request can be queued by calling
74 Finally, the file descriptor can be :ref:`polled <request-func-poll>` to wait
75 for the request to complete.
77 The request will remain allocated until all the file descriptors associated
78 with it are closed by :ref:`close() <request-func-close>` and the driver no
[all …]
|
| D | request-func-close.rst | 30 request close()
36 request-close - Close a request file descriptor
60 Closes the request file descriptor. Resources associated with the request
61 are freed once all file descriptors associated with the request are closed
62 and the driver has completed the request.
63 See :ref:`here <media-request-life-time>` for more information.
69 :ref:`close() <request-func-close>` returns 0 on success. On error, -1 is
|
| D | request-func-ioctl.rst | 30 request ioctl()
36 request-ioctl - Control a request file descriptor
57 The request ioctl command code as defined in the media.h header file, for
61 Pointer to a request-specific structure.
67 The :ref:`ioctl() <request-func-ioctl>` function manipulates request
70 The ioctl ``cmd`` code specifies the request function to be called. It
74 Macros and structures definitions specifying request ioctl commands and
75 their parameters are located in the media.h header file. All request ioctl
|
| D | media-funcs.rst | 28 media-ioc-request-alloc
29 request-func-close
30 request-func-ioctl
31 request-func-poll
32 media-request-ioc-queue
33 media-request-ioc-reinit
|
| D | request-func-poll.rst | 30 request poll()
36 request-poll - Wait for some event on a file descriptor
48 :name: request-poll
66 With the :c:func:`poll() <request-func-poll>` function applications can wait
67 for a request to complete.
69 On success :c:func:`poll() <request-func-poll>` returns the number of file
72 is non-zero). Request file descriptor set the ``POLLPRI`` flag in ``revents``
73 when the request was completed. When the function times out it returns
77 Attempting to poll for a request that is not yet queued will
84 On success, :c:func:`poll() <request-func-poll>` returns the number of
|
| D | media-func-ioctl.rst | 30 .. c:function:: int ioctl( int fd, int request, void *argp )
39 ``request``
40 Media ioctl request code as defined in the media.h header file, for
44 Pointer to a request-specific structure.
53 The ioctl ``request`` code specifies the media function to be called. It
70 Request-specific error codes are listed in the individual requests
|
| /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/block/ |
| D | request.rst | 2 struct request documentation
14 2.0 Struct request members classification
16 2.1 struct request members explanation
25 Short explanation of request members
55 request type, etc.
57 int rq_status D Request status bits
67 unsigned long nr_sectors DBI Total number of sectors in request
72 segments in a request
75 segments in a request
78 of request
[all …]
|
| D | biodoc.rst | 62 1.2.1 Request Priority/Latency
70 2.3 Changes in the request structure
74 3.2.1 Traversing segments and completion units in a request
128 a per-queue level (e.g maximum request size, maximum number of segments in
145 Sets two variables that limit the size of the request.
147 - The request queue's max_sectors, which is a soft size in
151 - The request queue's max_hw_sectors, which is a hard limit
152 and reflects the maximum size request a driver can handle
159 Maximum physical segments you can handle in a request. 128
163 Maximum dma segments the hardware can handle in a request. 128
[all …]
|
| /Documentation/scsi/ |
| D | hptiop.txt | 81 I/O Request Workflow of Not Marvell Frey
85 A request packet can be allocated in either IOP or host memory.
87 To send a request to the controller:
89 - Get a free request packet by reading the inbound queue port or
90 allocate a free request in host DMA coherent memory.
104 - The IOP process the request. When the request is completed, it
108 For requests allocated in IOP memory, the request offset is posted to
113 flag is set in the request, the low 32-bit context value will be
116 - The host read the outbound queue and complete the request.
118 For requests allocated in IOP memory, the host driver free the request
[all …]
|
| /Documentation/filesystems/nfs/ |
| D | idmapper.txt | 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
46 would edit your request-key.conf so it look similar to this:
54 request-key will find the first matching line and corresponding program. In
[all …]
|
| /Documentation/virt/kvm/ |
| D | vcpu-requests.rst | 8 KVM supports an internal API enabling threads to request a VCPU thread to
9 perform some activity. For example, a thread may request a VCPU to flush
10 its TLB with a VCPU request. The API consists of the following functions::
15 /* Check if VCPU @vcpu has request @req pending. */
18 /* Clear request @req for VCPU @vcpu. */
22 * Check if VCPU @vcpu has request @req pending. When the request is
29 * Make request @req of VCPU @vcpu. Issues a memory barrier, which pairs
30 * with another in kvm_check_request(), prior to setting the request.
34 /* Make request @req of all VCPUs of the VM with struct kvm @kvm. */
38 as possible after making the request. This means most requests
[all …]
|
| /Documentation/maintainer/ |
| D | pull-requests.rst | 25 the pull request on a separate branch. Typically you will base this branch
27 request to.
29 In order to create the pull request you must first tag the branch that you
35 Greg offers the following. A pull request with miscellaneous stuff for
50 you to describe the tag. In this case, you are describing a pull request,
54 merge the pull request. So write it up well, as it will be in the kernel
65 Note that if there is something odd about the pull request, that
74 I will take both what you write in the email pull request _and_ in
77 make it into the pull request email), or you can make the signed
79 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
|
| D | sysfs-class-fpga-manager | 14 fix) then userspace can know, i.e. if the firmware request
28 * firmware request = firmware class request in progress
29 * firmware request error = firmware request failed
|
| /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 clinet 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>;
|
| D | stm32-mdma.txt | 17 - dma-requests: Number of DMA request signals supported by the controller.
41 1. The request line number
71 0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
72 0x01: Each MDMA request triggers a block transfer (max 64K bytes)
73 0x10: Each MDMA request triggers a repeated block transfer
74 0x11: Each MDMA request triggers a linked list transfer
75 4. A 32bit value specifying the register to be used to acknowledge the request
77 5. A 32bit mask specifying the value to be written to acknowledge the request
|
| D | fsl-imx-dma.txt | 4 DMA request bindings as described in dma/dma.txt .
35 - dmas: List of one or more DMA request specifiers. One DMA request specifier
37 specifying the request line.
|
| /Documentation/filesystems/ |
| D | fuse.txt | 151 If a process issuing a FUSE filesystem request is interrupted, the
154 1) If the request is not yet sent to userspace AND the signal is
155 fatal (SIGKILL or unhandled fatal signal), then the request is
158 2) If the request is not yet sent to userspace AND the signal is not
159 fatal, then an 'interrupted' flag is set for the request. When
160 the request has been successfully transferred to userspace and
161 this flag is set, an INTERRUPT request is queued.
163 3) If the request is already sent to userspace, then an INTERRUPT
164 request is queued.
170 or may honor them by sending a reply to the _original_ request, with
[all …]
|
| /Documentation/power/ |
| D | pm_qos_interface.rst | 33 changes to the request list or elements of the list. Typically the
34 aggregated target value is simply the max or min of the request values held
57 the request.
63 Returns if the request is still active, i.e. it has not been removed from a
76 Only processes can register a pm_qos request. To provide for automatic
84 request on the parameter.
91 To remove the user mode request for a target value simply close the device
101 Values are updated in response to changes of the request list.
104 simply the minimum of the request values held in the parameter list elements.
129 removing the request.
[all …]
|
| /Documentation/media/uapi/cec/ |
| D | cec-func-ioctl.rst | 29 .. c:function:: int ioctl( int fd, int request, void *argp )
38 ``request``
39 CEC ioctl request code as defined in the cec.h header file, for
43 Pointer to a request-specific structure.
52 The ioctl ``request`` code specifies the cec function to be called. It
69 Request-specific error codes are listed in the individual requests
|
12345678910>>...23