Searched full:specific (Results 1 – 25 of 1248) sorted by relevance
12345678910>>...50
| /Documentation/devicetree/bindings/hwlock/ |
| D | hwlock.txt | 4 Generic bindings that are common to all the hwlock platform specific driver
7 Please also look through the individual platform specific hwlock binding
8 documentations for identifying any additional properties specific to that
16 specific lock.
21 Consumers that require specific hwlock(s) should specify them using the
34 use the hwlock-names to match and get a specific hwlock.
37 1. Example of a node using a single specific hwlock:
49 2. Example of a node using multiple specific hwlocks:
|
| /Documentation/devicetree/bindings/mmc/ |
| D | samsung-sdhci.txt | 8 Required SoC Specific Properties:
15 Required Board Specific Properties:
30 Note: This example shows both SoC specific and board specific properties
32 into SoC specific node and board specific node.
|
| D | exynos-dw-mshc.txt | 1 * Samsung Exynos specific extensions to the Synopsys Designware Mobile
7 by synopsys-dw-mshc.txt and the properties used by the Samsung Exynos specific
14 specific extensions.
16 specific extensions.
18 specific extensions.
20 specific extensions.
22 specific extensions.
24 specific extensions having an SMU.
69 The MSHC controller node can be split into two portions, SoC specific and
70 board specific portions as listed below.
|
| D | k3-dw-mshc.txt | 1 * Hisilicon specific extensions to the Synopsys Designware Mobile
9 by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
15 - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions.
17 with hi3670 specific extensions.
18 - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
19 - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions.
|
| D | bluefield-dw-mshc.txt | 1 * Mellanox Bluefield SoC specific extensions to the Synopsys Designware
10 specific extensions to the Synopsys Designware Mobile Storage Host Controller.
16 specific extensions.
|
| /Documentation/arm/samsung/ |
| D | overview.rst | 24 deals with the architecture and drivers specific to these devices.
27 on the implementation details and specific support.
37 - S5PC110 specific default configuration
39 - S5PV210 specific default configuration
46 several platform directories and then the machine specific directories
51 specific information. It contains the base clock, GPIO and device definitions
54 plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
56 plat-s5p is for s5p specific builds, and contains common support for the
57 S5P specific systems. Not all S5Ps use all the features in this directory
|
| D | gpio.rst | 9 specific calls provided alongside the drivers/gpio core.
24 specific calls for the items that require Samsung specific handling, such
33 Pin configuration is specific to the Samsung architecture, with each SoC
|
| /Documentation/sh/ |
| D | new-machine.txt | 16 of the board-specific code (with the exception of stboards) ended up
17 in arch/sh/kernel/ directly, with board-specific headers ending up in
22 Board-specific code:
29 | | `-- board-specific files
31 | | `-- board-specific files
38 | `-- board-specific headers
40 | `-- board-specific headers
51 `-- cchip-specific files
54 board-specific headers. Thus, include/asm-sh/hd64461 is home to all of the
55 hd64461-specific headers.
[all …]
|
| /Documentation/devicetree/bindings/sifive/ |
| D | sifive-blocks-ip-versioning.txt | 9 IP block-specific DT compatible strings are contained within the HDL,
26 match on these IP block-specific compatible strings.
29 continue to specify an SoC-specific compatible string value, such as
30 "sifive,fu540-c000-uart". This way, if SoC-specific
31 integration-specific bug fixes or workarounds are needed, the kernel
33 IP block-specific compatible string (such as "sifive,uart0") should
|
| /Documentation/hwmon/ |
| D | pmbus-core.rst | 29 device specific extensions in addition to the core PMBus driver, since it is
30 simply unknown what new device specific functionality PMBus device developers
33 To make device specific extensions as scalable as possible, and to avoid having
35 split into core, generic, and device specific code. The core code (in
37 provides support for generic PMBus devices. Device specific code is responsible
38 for device specific initialization and, if needed, maps device specific
52 For this reason, it often makes sense to provide a device specific driver if not
65 The API between core and device specific PMBus code is defined in
84 than 0xff). Support for virtual PMBus commands is device specific and thus has
85 to be implemented in device specific code.
[all …]
|
| /Documentation/media/uapi/v4l/ |
| D | ext-ctrls-fm-tx.rst | 34 step are driver-specific.
114 useconds. Step and range are driver-specific.
118 are driver-specific.
128 range and step are driver-specific.
132 value. The range and step are driver-specific.
136 value. The range and step are driver-specific.
140 useconds value. The range and step are driver-specific.
147 range and step are driver-specific.
151 step are driver-specific.
180 dBuV. Range and step are driver-specific.
[all …]
|
| /Documentation/driver-api/usb/ |
| D | typec_bus.rst | 10 The communication is SVID (Standard or Vendor ID) specific, i.e. specific for
29 specific commands from the alternate mode drivers to the partner, and from the
30 partners to the alternate mode drivers. No direct SVID specific communication is
47 will be used to deliver all the SVID specific commands from the partner to the
49 the SVID specific commands to each other using :c:func:`typec_altmode_vdm()`.
51 If the communication with the partner using the SVID specific commands results
54 passes the negotiated SVID specific pin configuration value to the function as
60 NOTE: The SVID specific pin configuration values must always start from
69 An example of working definitions for SVID specific pin configurations would
|
| /Documentation/devicetree/bindings/arm/freescale/ |
| D | fsl,layerscape-scfg.txt | 3 SCFG is the supplemental configuration unit, that provides SoC specific
8 - compatible: Should contain a chip-specific compatible string,
9 Chip-specific strings are of the form "fsl,<chip>-scfg",
|
| /Documentation/devicetree/bindings/clock/ti/ |
| D | interface.txt | 19 "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW
21 "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling
22 "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling
23 "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling
24 "ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW
|
| /Documentation/devicetree/bindings/usb/ |
| D | omap-usb.txt | 1 OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
7 multipoint. This is a MUSB configuration-specific setting.
9 MUSB configuration-specific setting. Should be set to "16"
11 - interface-type : This is a board specific setting to describe the type of
27 SOC specific device node entry
39 Board specific device node entry
|
| /Documentation/media/v4l-drivers/ |
| D | davinci-vpbe.rst | 49 board specific settings (specified in board-xxx-evm.c). This allows
52 API to set timings in VENC for a specific display resolution. As of this
60 is connected, the timings for a specific standard/preset is retrieved from
61 the board specific table and the values are used to set the timings in
67 add the available outputs as a board specific entry (i.e add the "LogicPD"
69 supported can be maintained in the board specific setup file to support
75 OSD module implements all OSD layer management and hardware specific
|
| /Documentation/driver-api/driver-model/ |
| D | driver.rst | 43 model because the bus they belong to has a bus-specific structure with
44 bus-specific fields that cannot be generalized.
49 completely bus-specific. Defining them as bus-specific entities would
50 sacrifice type-safety, so we keep bus-specific structures around.
52 Bus-specific drivers should include a generic struct device_driver in
53 the definition of the bus-specific driver. Like this::
60 A definition that included bus-specific fields would look like
86 no bus-specific fields (i.e. don't have a bus-specific driver
90 Most drivers, however, will have a bus-specific structure and will
106 define generic callbacks that forward the call to the bus-specific
[all …]
|
| /Documentation/driver-api/rapidio/ |
| D | rapidio.rst | 17 into the kernel similarly to other buses by defining RapidIO-specific device and
21 architecture-specific interfaces that provide support for common RapidIO
38 by a rio_mport data structure. This structure contains master port specific
43 RapidIO master ports are serviced by subsystem specific mport device drivers
46 includes rio_ops data structure which contains pointers to hardware specific
64 data structure, which contains switch specific information such as copy of the
65 routing table and pointers to switch specific functions.
68 specific switch drivers that are designed to provide hardware-specific
83 RapidIO device-specific drivers follow Linux Kernel Driver Model and are
84 intended to support specific RapidIO devices attached to the RapidIO network.
[all …]
|
| /Documentation/powerpc/ |
| D | bootwrapper.rst | 38 cuImages are platform specific. Each specific
41 from the platform specific bd_info file. The platform
42 specific cuImage platform init code can be found in
44 cuImage init code for a specific board can be found in
55 dtbImages have platform specific code for extracting
61 specific initialization code is typically found in a
82 specific initialization code to the start of the bootup
85 is enabled. Platform specific initialization code is
150 middle of the script. This is also the place where platform specific fixups
154 wrapper bits are very board specific and care should be taken to make sure
|
| /Documentation/devicetree/bindings/powerpc/fsl/ |
| D | mpic.txt | 39 specifiers do not contain the interrupt-type or type-specific
110 type-specific cell is undefined. The
123 the error interrupt. The type-specific
124 cell identifies the specific error
130 the MPIC IPI number. The type-specific
136 the MPIC timer number. The type-specific
139 <4th-cell> type-specific information
141 The type-specific cell is encoded as follows:
144 the type-specific cell contains the
223 * SoC interrupt number is 16 and the specific error
|
| /Documentation/networking/ |
| D | xfrm_proc.txt | 27 Transformation protocol specific error
30 Transformation mode specific error
67 Transformation protocol specific error
69 Transformation mode specific error
|
| /Documentation/devicetree/bindings/spi/ |
| D | spi-samsung.txt | 6 Required SoC Specific Properties:
36 Required Board Specific Properties:
41 Optional Board Specific Properties:
56 SPI Controller specific data in SPI slave nodes:
78 - SoC Specific Portion:
91 - Board Specific Portion:
|
| /Documentation/devicetree/bindings/mfd/ |
| D | syscon.txt | 5 represent as any specific type of device. The typical use-case is for
6 some other node's driver, or platform-specific code, to acquire a
8 using a specific compatible value), interrogate the node (or associated
|
| /Documentation/devicetree/bindings/arm/ |
| D | ste-u300.txt | 3 For various board the "board" node may contain specific properties
4 that pertain to this particular board, such as board-specific GPIOs
21 This contains the board-specific information.
|
| /Documentation/devicetree/bindings/ |
| D | writing-bindings.txt | 29 - DON'T use 'syscon' alone without a specific compatible string. A 'syscon'
36 - DO make 'compatible' properties specific. DON'T use wildcards in compatible
41 - DO use a vendor prefix on device specific property names. Consider if
46 constraints specific to the device.
|
12345678910>>...50