| /Documentation/devicetree/bindings/net/ | 
| D | micrel-ksz90x1.txt | 25   corresponding pad skew register: 27   Device Tree Value	Delay	Pad Skew Register Value 48     - rxc-skew-ps : Skew control of RXC pad 49     - rxdv-skew-ps : Skew control of RX CTL pad 50     - txc-skew-ps : Skew control of TXC pad 51     - txen-skew-ps : Skew control of TX CTL pad 52     - rxd0-skew-ps : Skew control of RX data 0 pad 53     - rxd1-skew-ps : Skew control of RX data 1 pad 54     - rxd2-skew-ps : Skew control of RX data 2 pad 55     - rxd3-skew-ps : Skew control of RX data 3 pad [all …] 
 | 
| /Documentation/userspace-api/media/v4l/ | 
| D | pixfmt-sdr-pcu16be.rst | 37       -  I'\ :sub:`0[5:0]; B1[1:0]=pad` 38       -  pad 39       -  pad 42       -  I'\ :sub:`1[5:0]; B1[1:0]=pad` 43       -  pad 44       -  pad 48       -  Q'\ :sub:`0[5:0]; B1[1:0]=pad` 49       -  pad 50       -  pad 53       -  Q'\ :sub:`1[5:0]; B1[1:0]=pad` [all …] 
 | 
| D | dev-subdev.rst | 79 Pad-level Formats 84     Pad-level formats are only applicable to very complex devices that 126 can expose pad-level image format configuration to applications. When 130 negotiate formats on a per-pad basis. 138 Pad-level image format configuration support can be tested by calling 139 the :ref:`VIDIOC_SUBDEV_G_FMT` ioctl on pad 140 0. If the driver returns an ``EINVAL`` error code pad-level format 186 or active format is set on a pad, corresponding formats on other pads of 192    a format on a source pad should not modify the format on any sink 193    pad. [all …] 
 | 
| D | pixfmt-sdr-pcu18be.rst | 38       -  I'\ :sub:`0[1:0]; B2[5:0]=pad` 39       -  pad 43       -  I'\ :sub:`1[1:0]; B2[5:0]=pad` 44       -  pad 49       -  Q'\ :sub:`0[1:0]; B2[5:0]=pad` 50       -  pad 54       -  Q'\ :sub:`1[1:0]; B2[5:0]=pad` 55       -  pad
  | 
| D | pixfmt-sdr-pcu20be.rst | 38       -  I'\ :sub:`0[3:0]; B2[3:0]=pad` 39       -  pad 43       -  I'\ :sub:`1[3:0]; B2[3:0]=pad` 44       -  pad 49       -  Q'\ :sub:`0[3:0]; B2[3:0]=pad` 50       -  pad 54       -  Q'\ :sub:`1[3:0]; B2[3:0]=pad` 55       -  pad
  | 
| D | vidioc-subdev-g-frame-interval.rst | 13 …V_G_FRAME_INTERVAL - VIDIOC_SUBDEV_S_FRAME_INTERVAL - Get or set the frame interval on a subdev pad 44 To retrieve the current frame interval applications set the ``pad`` 47 the desired pad number as reported by the media controller API. When 51 To change the current frame interval applications set both the ``pad`` 75 on a single pad only. Their behaviour when supported on multiple pads of 88       - ``pad`` 89       - Pad number as reported by the media controller API. 113     The frame interval can't be changed because the pad is currently 115     the pad. The ioctl must not be retried without performing another 120     The struct :c:type:`v4l2_subdev_frame_interval` ``pad`` references a [all …] 
 | 
| D | vidioc-subdev-g-crop.rst | 13 VIDIOC_SUBDEV_G_CROP - VIDIOC_SUBDEV_S_CROP - Get or set the crop rectangle on a subdev pad 44 To retrieve the current crop rectangle applications set the ``pad`` 46 desired pad number as reported by the media API and the ``which`` field 51 on the given pad. 53 To change the current crop rectangle applications set both the ``pad`` 89       - ``pad`` 90       - Pad number as reported by the media framework. 114     The crop rectangle can't be changed because the pad is currently 116     the pad. The ioctl must not be retried without performing another 121     The struct :c:type:`v4l2_subdev_crop` ``pad`` references a non-existing pad, [all …] 
 | 
| D | vidioc-subdev-g-fmt.rst | 13 VIDIOC_SUBDEV_G_FMT - VIDIOC_SUBDEV_S_FMT - Get or set the data format on a subdev pad 41 To retrieve the current format applications set the ``pad`` field of a 43 pad number as reported by the media API and the ``which`` field to 48 To change the current format applications set both the ``pad`` and 62 For instance, to try a format at the output pad of a sub-device, 65 default format at the output pad with the ``VIDIOC_SUBDEV_G_FMT`` ioctl, 66 or set the desired output pad format with the ``VIDIOC_SUBDEV_S_FMT`` 94       - ``pad`` 95       - Pad number as reported by the media controller API. 137     The format can't be changed because the pad is currently busy. This [all …] 
 | 
| D | vidioc-subdev-enum-frame-interval.rst | 35 given sub-device pad. Frame intervals only makes sense for sub-devices 40 on the sub-device output pad depend on the frame format and size on the 41 same pad. Applications must thus specify the desired format and size 45 ``pad``, ``which``, ``code``, ``width`` and ``height`` fields of struct 59 implemented it on a single pad only. Its behaviour when supported on 75       - ``pad`` 76       - Pad number as reported by the media controller API. 110     The struct :c:type:`v4l2_subdev_frame_interval_enum` ``pad`` references a 111     non-existing pad, the ``which`` field has an unsupported value, one of the 112     ``code``, ``width`` or ``height`` fields are invalid for the given pad, or
  | 
| D | ext-ctrls-dv.rst | 29 bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 45     output pad on the transmitter. If an output pad does not have an 46     associated hotplug pin, then the bit for that pad will be 0. This 54     Each bit corresponds to an output pad on the transmitter. If an 55     output pad does not have an associated Rx Sense, then the bit for 56     that pad will be 0. This read-only control is applicable to DVI-D 63     output pad on the transmitter. If an output pad does not support 64     EDIDs, then the bit for that pad will be 0. This read-only control 130     corresponds to an input pad on the receiver. If an input pad 131     cannot detect whether power is present, then the bit for that pad
  | 
| D | vidioc-subdev-enum-frame-size.rst | 35 supported by a sub-device on the specified pad 43 Each pair of ``pad`` and ``code`` correspond to a separate enumeration. 47 Therefore, to enumerate frame sizes allowed on the specified pad 49 ``pad``, ``which``, and ``code`` fields to desired values, 87       - Index of the frame size in the enumeration belonging to the given pad 90       - ``pad`` 91       - Pad number as reported by the media controller API. 129     The struct :c:type:`v4l2_subdev_frame_size_enum` ``pad`` references a 130     non-existing pad, the ``which`` field has an unsupported value, the ``code`` 131     is invalid for the given pad, or the ``index`` field is out of bounds.
  | 
| D | vidioc-subdev-enum-mbus-code.rst | 35 of media bus formats for the selected pad. 42 Therefore, to enumerate media bus formats available at a given sub-device pad, 43 initialize the ``pad``, and ``which`` fields to desired values, 51 ``EINVAL`` means that either ``pad`` is invalid, 52 or that there are no more codes available at this pad. 55 at the same pad. 72       - ``pad`` 73       - Pad number as reported by the media controller API. Filled in by the 77       - Index of the mbus code in the enumeration belonging to the given pad. 161     The struct :c:type:`v4l2_subdev_mbus_code_enum` ``pad`` references a [all …] 
 | 
| D | vidioc-subdev-g-selection.rst | 13 …OC_SUBDEV_G_SELECTION - VIDIOC_SUBDEV_S_SELECTION - Get or set selection rectangles on a subdev pad 85       - ``pad`` 86       - Pad number as reported by the media framework. 112     The selection rectangle can't be changed because the pad is 114     stream on the pad. The ioctl must not be retried without performing 119     The struct :c:type:`v4l2_subdev_selection` ``pad`` references a 120     non-existing pad, the ``which`` field has an unsupported value, or the 121     selection target is not supported on the given subdev pad.
  | 
| D | vidioc-enum-dv-timings.rst | 46 field, set the ``pad`` field to 0, zero the reserved array of struct 63 pad number in the struct 64 :c:type:`v4l2_enum_dv_timings` ``pad`` field. 65 Attempts to enumerate timings on a pad that doesn't support them will 81       - ``pad`` 82       - Pad number as reported by the media controller API. This field is 102     ``index`` is out of bounds or the ``pad`` number is invalid.
  | 
| /Documentation/userspace-api/media/mediactl/ | 
| D | media-types.rst | 145 	  pad, and composes input video frames onto output video 152 	  must have at least one sink pad and one source pad. Read 161 	  encoding conversion must have at least one sink pad and one 162 	  source pad, and convert the encoding of pixels received on 163 	  its sink pad(s) to a different encoding output on its source 164 	  pad(s). Pixel encoding conversion includes but isn't limited 170 	  processing must have one sink pad and one source pad. It uses 171 	  the values of the pixels received on its sink pad to look up 172 	  entries in internal tables and output them on its source pad. 179 	  at least one sink pad and one source pad, and scale the [all …] 
 | 
| /Documentation/input/ | 
| D | gamepad.rst | 24     /       ||      __  |MO|  __     _       _ \        | Main Pad 35          D-Pad    Left       Right   Action Pad 39                       Menu Pad 43   - Action-Pad 47   - D-Pad (Direction-pad) 49   - Menu-Pad 59     Triggers are located on the upper-side of the pad in vertical direction. 99 - Action-Pad: 109     - 2-Button Pad: 115     - 3-Button Pad: [all …] 
 | 
| /Documentation/admin-guide/media/ | 
| D | vimc.rst | 54 	* 1 Pad source 65 	- entity 28: Lens A (0 pad, 0 link) 68 	- entity 29: Lens B (0 pad, 0 link) 79 	* 1 Pad sink 80 	* 1 Pad source 83 	Re-size the image to meet the source pad resolution. E.g.: if the sync 84 	pad is configured to 360x480 and the source to 1280x720, the image will 89 	* 1 Pad sink 90 	* 1 Pad source 96 	* 1 Pad sink [all …] 
 | 
| D | imx.rst | 140 This is the MIPI CSI-2 receiver entity. It has one sink pad to receive 168 single source pad that routes to a CSI (ipuX_csiY entities). 186 These are the CSI entities. They have a single sink pad receiving from 190 This entity has two source pads. The first source pad can link directly 194 When the direct source pad is routed to the ipuX_ic_prp entity, frames 198 When the direct source pad is routed to the ipuX_vdic entity, the VDIC 202 The second source pad sends video frames directly to memory buffers 204 source pad is routed to a capture device node, with a node name of the 207 Note that since the IDMAC source pad makes use of an IDMAC channel, 209 IDMAC channel. For example, if the CSI sink pad is receiving in UYVY [all …] 
 | 
| D | rkisp1.rst | 77 YUV4:2:2 -> YUV4:2:0). They also have cropping capability on the sink pad. 86 This is the isp entity. It is connected to the sensor on sink pad 0 and 88 the CSI-2 protocol. It has a cropping capability on sink pad 0 that is 89 connected to the sensor and on source pad 2 connected to the resizer entities. 90 Cropping on sink pad 0 defines the image region from the sensor. 91 Cropping on source pad 2 defines the region for the Image Stabilizer (IS). 133 In the following example, the sensor connected to pad 0 of 'rkisp1_isp' is 168 `SRGGB10_1X10/1640x1232`. The rkisp1_isp:0 pad should be configured to the 171 In addition, the rkisp1_isp:0 pad is configured to cropping `(0,0)/1600x1200`. 174 isp source pad `rkisp1_isp:2`. Another cropping operation is configured on [all …] 
 | 
| /Documentation/devicetree/bindings/mmc/ | 
| D | nvidia,tegra20-sdhci.yaml | 112   nvidia,pad-autocal-pull-down-offset-1v8: 117   nvidia,pad-autocal-pull-down-offset-1v8-timeout: 122   nvidia,pad-autocal-pull-down-offset-3v3: 127   nvidia,pad-autocal-pull-down-offset-3v3-timeout: 132   nvidia,pad-autocal-pull-down-offset-sdr104: 136   nvidia,pad-autocal-pull-down-offset-hs400: 140   nvidia,pad-autocal-pull-up-offset-1v8: 145   nvidia,pad-autocal-pull-up-offset-1v8-timeout: 150   nvidia,pad-autocal-pull-up-offset-3v3: 162   nvidia,pad-autocal-pull-up-offset-3v3-timeout: [all …] 
 | 
| /Documentation/devicetree/bindings/pinctrl/ | 
| D | fsl,imx-pinctrl.txt | 4 to share one PAD to several functional blocks. The sharing is done by 5 multiplexing the PAD input/output signals. For each PAD there are up to 7 different PAD settings (like pull up, keeper, etc) the IOMUXC controls 8 also the PAD settings parameters. 17 mode) this pin can work on and the 'config' configures various pad settings 29   the pad setting value like pull-up on this pin. And that's why fsl,pins entry 40 Other bits are used for PAD setting.
  | 
| /Documentation/input/devices/ | 
| D | xpad.rst | 26 - if you are using a known dance pad 28   module configuration for "Map D-PAD to buttons rather than axes for unknown 32 the driver will map the directional pad to axes (X/Y). 33 If you said Y it will map the d-pad to buttons, which is needed for dance 45 With a normal controller, the directional pad is mapped to its own X/Y axes. 60 play first person shooters with a pad. Your mileage may vary. 66 When using a known dance pad, jstest will report 6 axes and 14 buttons. 68 For dance style pads (like the redoctane pad) several changes 69 have been made.  The old driver would map the d-pad to axes, resulting 73 Known dance pads automatically map the d-pad to buttons and will work [all …] 
 | 
| /Documentation/driver-api/media/ | 
| D | mc-core.rst | 27 A pad is a connection endpoint through which an entity can interact with 34 pad to a sink pad. 101 Pads have flags that describe the pad capabilities and state. 103 ``MEDIA_PAD_FL_SINK`` indicates that the pad supports sinking data. 104 ``MEDIA_PAD_FL_SOURCE`` indicates that the pad supports sourcing data. 109   be set for each pad. 117 **1. pad to pad links**: 124 Drivers create pad to pad links by calling: 163 Helper functions can be used to find a link between two given pads, or a pad 164 connected to another pad through an enabled link [all …] 
 | 
| /Documentation/devicetree/bindings/arm/tegra/ | 
| D | nvidia,tegra186-pmc.yaml | 88         These are pad configuration nodes. On Tegra SoCs a pad is a set of 90         attribute of the hardware. The PMC can be used to set pad power 91         state and signaling voltage. A pad can be either in active or 93         configuration varies depending on the pad in question. 3.3 V and 97         Pad configurations are described with pin configuration nodes 125           description: Must contain the name of the pad(s) to be 129           description: Configure the pad into power down mode. 133           description: Configure the pad into active mode. 145               include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h 176     #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
  | 
| /Documentation/devicetree/bindings/phy/ | 
| D | fsl,imx8-pcie-phy.yaml | 43   fsl,refclk-pad-mode: 45       Specifies the mode of the refclk pad used. It can be UNUSED(PHY 47       is provided externally via the refclk pad) or OUTPUT(PHY refclock 48       is derived from SoC internal source and provided on the refclk pad). 79   - fsl,refclk-pad-mode 99             fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
  |