Searched +full:platform +full:- +full:specific (Results 1 – 25 of 305) sorted by relevance
12345678910>>...13
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 17 others. U-Boot is typically found on embedded PowerPC hardware, but there 28 U-Boot (for versions that don't understand the device 31 are all embedded inside the U-Boot uImage file format 37 bd_info structure used in the old U-Boot interfaces, 38 cuImages are platform specific. Each specific 39 U-Boot platform has a different platform init file 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 50 binary depending on the platform. [all …]
|
| /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 9 platform. 15 - #hwlock-cells: Specifies the number of cells needed to represent a 16 specific lock. 21 Consumers that require specific hwlock(s) should specify them using the 22 property "hwlocks", and an optional "hwlock-names" property. 25 - hwlocks: List of phandle to a hwlock provider node and an 27 #hwlock-cells. The list can have just a single hwlock [all …]
|
| /Documentation/driver-api/ |
| D | sm501.rst | 15 ---- 18 drivers which manage the specific hardware blocks. These services 23 chips via the platform device and driver system. 26 be specified by the platform data) and then exports the selected 27 peripheral set as platform devices for the specific drivers. 29 The core re-uses the platform device system as the platform device 31 need to create a new bus-type and the associated code to go with it. 35 --------- 38 the specific set of resources that peripheral requires in order to 43 as this is by-far the most resource-sensitive of the on-chip functions. [all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-removable | 6 platform by the user. This is determined by its subsystem in a 7 bus / platform-specific way. This attribute is only present for 11 "removable" device can be removed from the platform by the user 12 "fixed" device is fixed to the platform / cannot be removed 19 platform-specific data such as ACPI) and PCI (which gets this
|
| D | sysfs-platform-hidma-mgmt | 1 What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority 2 /sys/devices/platform/QCOM8060:*/chanops/chan*/priority 10 What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight 11 /sys/devices/platform/QCOM8060:*/chanops/chan*/weight 19 What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles 20 /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles 25 Contains the platform specific cycle value to wait after a 28 is platform specific and should not be changed without 31 What: /sys/devices/platform/hidma-mgmt*/dma_channels 32 /sys/devices/platform/QCOM8060:*/dma_channels [all …]
|
| D | sysfs-bus-event_source-devices-caps | 4 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> 8 expose information specific to a PMU, say pmu_name, so that 10 platform specific PMU supports. 12 One of the example available capability in supported platform 20 The "branch_counter_nr" in the supported platform exposes the
|
| D | sysfs-devices-platform-ipmi | 1 What: /sys/devices/platform/ipmi_bmc.*/firmware_revision 4 Contact: openipmi-developer@lists.sourceforge.net 9 What: /sys/devices/platform/ipmi_bmc.*/aux_firmware_revision 12 Contact: openipmi-developer@lists.sourceforge.net 16 The meanings of the numbers are specific to the vendor 20 What: /sys/devices/platform/ipmi_bmc.*/revision 23 Contact: openipmi-developer@lists.sourceforge.net 30 What: /sys/devices/platform/ipmi_bmc.*/provides_device_sdrs 33 Contact: openipmi-developer@lists.sourceforge.net 39 What: /sys/devices/platform/ipmi_bmc.*/device_id [all …]
|
| D | sysfs-driver-chromeos-acpi | 1 What: /sys/bus/platform/devices/GGL0001:*/BINF.2 2 /sys/bus/platform/devices/GOOG0016:*/BINF.2 13 What: /sys/bus/platform/devices/GGL0001:*/BINF.3 14 /sys/bus/platform/devices/GOOG0016:*/BINF.3 27 What: /sys/bus/platform/devices/GGL0001:*/CHSW 28 /sys/bus/platform/devices/GOOG0016:*/CHSW 32 Returns switch position for Chrome OS specific hardware 43 What: /sys/bus/platform/devices/GGL0001:*/FMAP 44 /sys/bus/platform/devices/GOOG0016:*/FMAP 51 What: /sys/bus/platform/devices/GGL0001:*/FRID [all …]
|
| /Documentation/admin-guide/media/ |
| D | cardlist.rst | 1 .. SPDX-License-Identifier: GPL-2.0 8 platform-specific drivers. It also contains several ancillary I²C drivers. 10 The platform-specific drivers are usually present on embedded systems, 24 usb-cardlist 25 pci-cardlist 26 platform-cardlist 27 radio-cardlist 28 i2c-cardlist 29 misc-cardlist
|
| /Documentation/driver-api/backlight/ |
| D | lp855x-driver.rst | 15 ----------- 36 Platform data for lp855x 37 ------------------------ 39 For supporting platform specific data, the lp855x platform data can be used. 48 Platform specific PWM period value. unit is nano. 58 1) lp8552 platform data: i2c register mode with new eeprom data:: 68 .name = "lcd-bl", 75 2) lp8556 platform data: pwm input mode with default rom data::
|
| /Documentation/process/ |
| D | maintainer-soc.rst | 1 .. SPDX-License-Identifier: GPL-2.0 8 -------- 10 The SoC subsystem is a place of aggregation for SoC-specific code. 13 * devicetrees for 32- & 64-bit ARM and RISC-V 14 * 32-bit ARM board files (arch/arm/mach*) 15 * 32- & 64-bit ARM defconfigs 16 * SoC-specific drivers across architectures, in particular for 32- & 64-bit 17 ARM, RISC-V and Loongarch 19 These "SoC-specific drivers" do not include clock, GPIO etc drivers that have 20 other top-level maintainers. The drivers/soc/ directory is generally meant [all …]
|
| /Documentation/admin-guide/pm/ |
| D | suspend-flows.rst | 1 .. SPDX-License-Identifier: GPL-2.0 12 At least one global system-wide transition needs to be carried out for the 14 :doc:`sleep states <sleep-states>`. Hibernation requires more than one 16 referred to as *system-wide suspend* (or simply *system suspend*) states, need 27 significant differences between the :ref:`suspend-to-idle <s2idle>` code flows 28 and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and 31 The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states 32 cannot be implemented without platform support and the difference between them 33 boils down to the platform-specific actions carried out by the suspend and 34 resume hooks that need to be provided by the platform driver to make them [all …]
|
| /Documentation/driver-api/xilinx/ |
| D | eemi.rst | 6 ------------------------------------- 7 The zynqmp-firmware node describes the interface to platform firmware. 10 used by any driver to communicate with PMC(Platform Management Controller). 13 ---------------------------------------------- 23 ------ 26 any device specific configuration. IOCTL definitions can be platform 27 specific. This API also manage shared device configuration. 30 - IOCTL_SET_PLL_FRAC_MODE 8 31 - IOCTL_GET_PLL_FRAC_MODE 9 32 - IOCTL_SET_PLL_FRAC_DATA 10 [all …]
|
| /Documentation/staging/ |
| D | remoteproc.rst | 10 of operating system, whether it's Linux or any other flavor of real-time OS. 12 OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP. 13 In a typical configuration, the dual cortex-A9 is running Linux in a SMP 22 platform-specific remoteproc drivers only need to provide a few low-level 24 (for more information about the virtio-based rpmsg bus and its drivers, 118 name of this remote processor, platform-specific ops handlers, 154 This is called by the platform-specific rproc implementation, whenever 172 This function should be called when the platform specific rproc 180 Returns 0 on success and -EINVAL if @rproc isn't valid. 189 platform specific rproc implementation. This should not be called from a [all …]
|
| /Documentation/devicetree/bindings/tpm/ |
| D | tcg,tpm-tis-i2c.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/tpm/tcg,tpm-tis-i2c.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: I²C-attached Trusted Platform Module conforming to TCG TIS specification 10 - Lukas Wunner <lukas@wunner.de> 13 The Trusted Computing Group (TCG) has defined a multi-vendor standard 16 TCG PC Client Specific TPM Interface Specification (TIS) 17 …tps://trustedcomputinggroup.org/resource/pc-client-work-group-pc-client-specific-tpm-interface-spe… 21 TCG PC Client Platform TPM Profile Specification for TPM 2.0 (PTP) [all …]
|
| /Documentation/driver-api/driver-model/ |
| D | platform.rst | 2 Platform Devices and Drivers 6 platform bus: platform_device, and platform_driver. This pseudo-bus 8 like those used to integrate peripherals on many system-on-chip 13 Platform devices 15 Platform devices are devices that typically appear as autonomous 16 entities in the system. This includes legacy port-based devices and 18 into system-on-chip platforms. What they usually have in common 23 Platform devices are given a name, used in driver binding, and a 35 Platform drivers 37 Platform drivers follow the standard driver model convention, where [all …]
|
| /Documentation/sound/soc/ |
| D | overview.rst | 6 provide better ALSA support for embedded system-on-chip processors (e.g. 9 had some limitations:- 12 CPU. This is not ideal and leads to code duplication - for example, 18 machine specific code to re-route audio, enable amps, etc., after such an 31 features :- 50 * Machine specific controls: Allow machines to add controls to the sound card 54 multiple re-usable component drivers :- 56 * Codec class drivers: The codec class driver is platform independent and 62 * Platform class drivers: The platform class driver includes the audio DMA 64 and any audio DSP drivers for that platform. [all …]
|
| /Documentation/arch/arm/samsung/ |
| D | overview.rst | 6 ------------ 15 - S3C64XX: S3C6400 and S3C6410 16 - S5PC110 / S5PV210 20 ------------- 26 - S5PC110 specific default configuration 28 - S5PV210 specific default configuration 32 ------ 35 several platform directories and then the machine specific directories 38 plat-samsung provides the base for all the implementations, and is the 40 specific information. It contains the base clock, GPIO and device definitions [all …]
|
| /Documentation/devicetree/bindings/perf/ |
| D | riscv,pmu.yaml | 1 # SPDX-License-Identifier: BSD-2-Clause 3 --- 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: RISC-V SBI PMU events 10 - Atish Patra <atishp@rivosinc.com> 18 The platform must provide information about PMU event to counter mappings 19 either via device tree or another way, specific to the platform. 24 MHPMCOUNTERx for that specific event. The can either be done via device tree 25 or another way, specific to the platform. 27 platform. [all …]
|
| /Documentation/arch/arm/spear/ |
| D | overview.rst | 6 ------------ 11 The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are 12 supported by the 'spear' platform of ARM Linux. Currently SPEAr1310, 17 SPEAr (Platform) 19 - SPEAr3XX (3XX SOC series, based on ARM9) 20 - SPEAr300 (SOC) 21 - SPEAr300 Evaluation Board 22 - SPEAr310 (SOC) 23 - SPEAr310 Evaluation Board 24 - SPEAr320 (SOC) [all …]
|
| /Documentation/devicetree/bindings/pci/ |
| D | snps,dw-pcie-ep.yaml | 1 # SPDX-License-Identifier: GPL-2.0 3 --- 4 $id: http://devicetree.org/schemas/pci/snps,dw-pcie-ep.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Jingoo Han <jingoohan1@gmail.com> 11 - Gustavo Pimentel <gustavo.pimentel@synopsys.com> 16 # Please create a separate DT-schema for your DWC PCIe Endpoint controller 17 # and make sure it's assigned with the vendor-specific compatible string. 21 const: snps,dw-pcie-ep 23 - compatible [all …]
|
| D | snps,dw-pcie.yaml | 1 # SPDX-License-Identifier: GPL-2.0 3 --- 4 $id: http://devicetree.org/schemas/pci/snps,dw-pcie.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Jingoo Han <jingoohan1@gmail.com> 11 - Gustavo Pimentel <gustavo.pimentel@synopsys.com> 16 # Please create a separate DT-schema for your DWC PCIe Root Port controller 17 # and make sure it's assigned with the vendor-specific compatible string. 21 const: snps,dw-pcie 23 - compatible [all …]
|
| /Documentation/driver-api/usb/ |
| D | writing_musb_glue_layer.rst | 15 Instead, these embedded UDC rely on the USB On-the-Go (OTG) 18 Dual-Role Controller (MUSB HDRC) found in the Mentor Graphics Inventra™ 21 As a self-taught exercise I have written an MUSB glue layer for the 28 .. _musb-basics: 33 To get started on the topic, please read USB On-the-Go Basics (see 37 albeit focused on some specific devices provided by these companies. 46 ------------------------ 47 | | <------- drivers/usb/gadget 48 | Linux USB Core Stack | <------- drivers/usb/host 49 | | <------- drivers/usb/core [all …]
|
| /Documentation/hwmon/ |
| D | oxp-sensors.rst | 1 .. SPDX-License-Identifier: GPL-2.0-or-later 3 Kernel driver oxp-sensors 7 - Derek John Clark <derekjohn.clark@gmail.com> 8 - Joaquín Ignacio Aramendía <samsagax@gmail.com> 11 ------------ 27 ----------------- 31 - AOKZOE A1 32 - AOKZOE A1 PRO 33 - AYANEO 2 34 - AYANEO 2S [all …]
|
| /Documentation/userspace-api/ |
| D | sysfs-platform_profile.rst | 2 Platform Profile Selection (e.g. /sys/firmware/acpi/platform_profile) 5 On modern systems the platform performance, temperature, fan and other 7 platform configuration is often automatically adjusted to the current 11 These auto platform adjustment mechanisms often can be configured with 12 one of several platform profiles, with either a bias towards low power 16 API for selecting the platform profile of these automatic mechanisms. 18 Note that this API is only for selecting the platform profile, it is 21 specific tools such as e.g. turbostat. 27 about any sub-optimal conditions which are impeding reaching the requested 33 gets a consistent experience the sysfs-platform_profile ABI document defines [all …]
|
12345678910>>...13