/linux/drivers/gpio/ |
H A D | gpio-stp-xway.c | 1 // SPDX-License-Identifier: GPL-2.0-only 22 * 3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem 37 /* software or hardware update select bit */ 58 /* 2 groups of 3 bits can be driven by the phys */ 85 u8 groups; /* we can drive 1-3 groups of 8bit each */ 86 u8 dsl; /* the 2 LSBs can be driven by the dsl core */ 87 u8 phy1; /* 3 bits can be driven by phy1 */ 88 u8 phy2; /* 3 bits can be driven by phy2 */ 89 u8 phy3; /* 3 bits can be driven by phy3 */ 90 u8 phy4; /* 3 bits can be driven by phy4 */ [all …]
|
/linux/Documentation/devicetree/bindings/pinctrl/ |
H A D | renesas,rza1-ports.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/pinctrl/renesas,rza1-ports.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Jacopo Mondi <jacopo+renesas@jmondi.org> 11 - Geert Uytterhoeven <geert+renesas@glider.be> 15 controller, named "Ports" in the hardware reference manual. 16 Pin multiplexing and GPIO configuration is performed on a per-pin basis 17 writing configuration values to per-port register sets. 25 - const: renesas,r7s72100-ports # RZ/A1H [all …]
|
/linux/Documentation/driver-api/gpio/ |
H A D | intro.rst | 17 A "General Purpose Input/Output" (GPIO) is a flexible software-controlled 19 to Linux developers working with embedded and custom hardware. Each GPIO 21 (BGA) packages. Board schematics show which external hardware connects to 25 System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every 26 non-dedicated pin can be configured as a GPIO; and most chips have at least 31 Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS 36 - Output values are writable (high=1, low=0). Some chips also have 37 options about how that value is driven, so that for example only one 38 value might be driven, supporting "wire-OR" and similar schemes for the 41 - Input values are likewise readable (1, 0). Some chips support readback [all …]
|
H A D | driver.rst | 24 Inside a GPIO driver, individual GPIO lines are identified by their hardware 26 between 0 and n-1, n being the number of GPIOs managed by the chip. 28 The hardware GPIO number should be something intuitive to the hardware, for 29 example if a system uses a memory-mapped set of I/O-registers where 32 GPIO 30 lines are handled by one bit per line in a 32-bit register, it makes sense to 31 use hardware offsets 0..31 for these, corresponding to bits 0..31 in the 34 This number is purely internal: the hardware number of a particular GPIO 40 assigned), and for each GPIO line the global number will be (base + hardware 44 So for example one platform could use global numbers 32-159 for GPIOs, with a 46 global numbers 0..63 with one set of GPIO controllers, 64-79 with another type [all …]
|
/linux/Documentation/admin-guide/ |
H A D | parport.rst | 4 The ``parport`` code provides parallel-port support under Linux. This 9 detection of your hardware. This is particularly useful if you want 16 port-sharing) and architecture-dependent (which deals with actually 28 architecture-dependent code with (for example):: 32 to tell the ``parport`` code that you want three PC-style ports, one at 34 auto-detected IRQ. Currently, PC-style (``parport_pc``), Sun ``bpp``, 35 Amiga, Atari, and MFC3 hardware is supported. 43 -------- 60 ------------------------ 68 parport0: Printer, BJC-210 (Canon) [all …]
|
/linux/Documentation/leds/ |
H A D | leds-class.rst | 8 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware 9 brightness support so will just be turned on for non-zero brightness settings. 14 existing subsystems with minimal additional code. Examples are the disk-activity, 15 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code 48 - devicename: 51 than to the hardware; the information related to the product and the bus 57 - color: 59 include/dt-bindings/leds/common.h. 61 - function: 63 include/dt-bindings/leds/common.h. [all …]
|
/linux/Documentation/devicetree/bindings/mfd/ |
H A D | st,stm32-timers.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/mfd/st,stm32-timers.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 This hardware block provides 3 types of timer along with PWM functionality: 11 - advanced-control timers consist of a 16-bit auto-reload counter driven 14 - general-purpose timers consist of a 16-bit or 32-bit auto-reload counter 15 driven by a programmable prescaler and PWM outputs. 16 - basic timers consist of a 16-bit auto-reload counter driven by a 20 - Fabrice Gasnier <fabrice.gasnier@foss.st.com> [all …]
|
/linux/drivers/leds/rgb/ |
H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0 6 tristate "LEDs group multi-color support" 11 different colors are physically grouped in a single multi-color LED 12 and driven by a controller that doesn't have multi-color support. 15 will be called leds-group-multicolor. 27 will be called leds-ktd202x. 38 will be called leds-ncp5623. 41 tristate "PWM driven multi-color LED Support" 44 This option enables support for PWM driven monochrome LEDs that are 48 will be called leds-pwm-multicolor. [all …]
|
/linux/Documentation/driver-api/thermal/ |
H A D | nouveau_thermal.rst | 12 ----------- 17 Currently, due to the absence of in-kernel API to access HWMON drivers, Nouveau 24 ---------------------- 26 Temperature is exposed under as a read-only HWMON attribute temp1_input. 56 -------------- 75 Your fan can be driven in different modes: 78 * 1: The fan can be driven in manual (use pwm1 to change the speed); 79 * 2; The fan is driven automatically depending on the temperature. 85 When operating in manual mode outside the vbios-defined 87 depending on your hardware. [all …]
|
/linux/drivers/char/ipmi/ |
H A D | ipmi_si_sm.h | 1 /* SPDX-License-Identifier: GPL-2.0+ */ 5 * State machine interface for low-level IPMI system management 8 * BT interface) and the actual low-level state machine. 35 SI_SM_HOSED, /* The hardware violated the state machine. */ 38 * The hardware is asserting attn and the state machine is 61 * return -2 if the state machine is not idle, -1 if the size 70 * -1 if the buffer is too small, zero if no transaction is 78 * receiving an interrupt (for a interrupt-driven interface). 79 * If interrupt driven, you should probably poll this
|
/linux/Documentation/spi/ |
H A D | spi-lm70llp.rst | 2 spi_lm70llp : LM70-LLP parport-to-SPI adapter 15 ----------- 22 into a SPI bus with a single device, which will be driven by the generic 26 Hardware Interfacing 27 -------------------- 28 The schematic for this particular board (the LM70EVAL-LLP) is 33 The hardware interfacing on the LM70 LLP eval board is as follows: 39 D0 2 - - 40 D1 3 --> V+ 5 41 D2 4 --> V+ 5 [all …]
|
/linux/Documentation/devicetree/bindings/nvmem/ |
H A D | nvmem.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 3 --- 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 13 This binding is intended to represent the location of hardware 23 "#address-cells": 26 "#size-cells": 29 read-only: 34 wp-gpios: 36 GPIO to which the write-protect pin of the chip is connected. [all …]
|
/linux/drivers/leds/blink/ |
H A D | Kconfig | 10 BCM63138 SoC. The same hardware block is known to be also used 13 If compiled as module it will be called leds-bcm63138. 22 gateway-on-a-chip SoC to be shipped on mid and high end home 25 These LEDs are driven by a Serial Shift Output (SSO) controller. 26 The driver supports hardware blinking and the LEDs can be configured 27 to be triggered by software/CPU or by hardware. 31 will be called leds-lgm-sso.
|
/linux/Documentation/arch/arm64/ |
H A D | arm-acpi.rst | 12 The Arm kernel implements the reduced hardware model of ACPI version 20 specifications, then ACPI may not be a good fit for the hardware. 23 industry-standard Arm systems, they also apply to more than one operating 25 ACPI and Linux only, on an Arm system -- that is, what Linux expects of 30 ---------------- 33 exist in Linux for describing non-enumerable hardware, after all. In this 40 - ACPI’s byte code (AML) allows the platform to encode hardware behavior, 41 while DT explicitly does not support this. For hardware vendors, being 43 system releases on new hardware. 45 - ACPI’s OSPM defines a power management model that constrains what the [all …]
|
/linux/include/linux/pinctrl/ |
H A D | pinconf-generic.h | 1 /* SPDX-License-Identifier: GPL-2.0-only */ 5 * Copyright (C) 2011 ST-Ericsson SA 6 * Written on behalf of Linaro for ST-Ericsson 24 * enum pin_config_param - possible pin configuration parameters 31 * transition from say pull-up to pull-down implies that you disable 32 * pull-up in the process, this setting disables all biasing. 34 * mode, also know as "third-state" (tristate) or "high-Z" or "floating". 40 * impedance to GROUND). If the argument is != 0 pull-down is enabled, 44 * on embedded knowledge of the controller hardware, like current mux 46 * be decided completely inside the hardware block and not be readable [all …]
|
/linux/drivers/gpu/drm/amd/amdgpu/ |
H A D | amdgpu_irq.c | 32 * Interrupts generated within GPU hardware raise interrupt requests that are 41 * For GPU interrupt sources that may be driven by another driver, IRQ domain 42 * support is used (with mapping between virtual and hardware IRQs). 118 * amdgpu_irq_disable_all - disable *all* interrupts 130 spin_lock_irqsave(&adev->irq.lock, irqflags); in amdgpu_irq_disable_all() 132 if (!adev->irq.client[i].sources) in amdgpu_irq_disable_all() 136 struct amdgpu_irq_src *src = adev->irq.client[i].sources[j]; in amdgpu_irq_disable_all() 138 if (!src || !src->funcs->set || !src->num_types) in amdgpu_irq_disable_all() 141 for (k = 0; k < src->num_types; ++k) { in amdgpu_irq_disable_all() 142 r = src->funcs->set(adev, src, k, in amdgpu_irq_disable_all() [all …]
|
/linux/Documentation/trace/coresight/ |
H A D | coresight-trbe.rst | 1 .. SPDX-License-Identifier: GPL-2.0 10 Hardware Description 11 -------------------- 13 Trace Buffer Extension (TRBE) is a percpu hardware which captures in system 19 driven via the CoreSight driver framework to support the ETE (which is 23 --------------------------- 36 *Key file items are:-*
|
/linux/arch/powerpc/platforms/85xx/ |
H A D | qemu_e500.c | 1 // SPDX-License-Identifier: GPL-2.0-or-later 5 * This is intended to be a flexible device-tree-driven platform, not fixed 6 * to a particular piece of hardware or a particular spec of virtual hardware, 7 * beyond the assumption of an e500-family CPU. Some things are still hardcoded 53 .compatible = "fsl,qemu-e500", in define_machine()
|
/linux/drivers/leds/ |
H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only 56 See Documentation/ABI/testing/sysfs-class-led for details. 65 This option enables support for on-chip LED drivers found on Marvell 72 This option enables support for the AN30259A 3-channel 76 will be called leds-an30259a. 86 If you're looking for APU2/3, use the pcengines-apu2 driver. 90 module will be called leds-apu. 112 - AW20036 (3x12) 36 LEDs 113 - AW20054 (6x9) 54 LEDs 114 - AW20072 (6x12) 72 LEDs [all …]
|
/linux/Documentation/devicetree/bindings/interconnect/ |
H A D | qcom,rpm-common.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: Qualcomm RPMh Network-On-Chip Interconnect 10 - Konrad Dybcio <konradybcio@kernel.org> 15 the bus monitor hardware. Each provider node represents a NoC bus master, 16 driven by a dedicated clock source. 19 '#interconnect-cells': 21 - const: 2 [all …]
|
/linux/Documentation/devicetree/bindings/display/ |
H A D | dsi-controller.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) 3 --- 4 $id: http://devicetree.org/schemas/display/dsi-controller.yaml# 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 10 - Linus Walleij <linus.walleij@linaro.org> 26 reg-property set to the virtual channel number, usually there is just 33 clock-master: 37 another DSI host to drive the same peripheral. Hardware supporting 39 to be driven by the same clock. Only the DSI host instance 42 "#address-cells": [all …]
|
/linux/include/linux/platform_data/ |
H A D | edma.h | 1 /* SPDX-License-Identifier: GPL-2.0-or-later */ 5 * Copyright (C) 2006-2013 Texas Instruments. 11 * Channel Triggers transfers, usually from a hardware event but 23 * is driven only from a channel, which performs the transfers specified 29 * Transfer Controller (TC) requests when the channel triggers (by hardware 33 * DaVinci hardware also has a "QDMA" mechanism which is not currently 45 EVENTQ_DEFAULT = -1 65 * Default queue is expected to be a low-priority queue. 74 /* List of channels allocated for memcpy, terminated with -1 */
|
/linux/Documentation/timers/ |
H A D | highres.rst | 8 https://www.kernel.org/doc/ols/2006/ols2006v1-pages-333-346.pdf 11 http://www.cs.columbia.edu/~nahum/w6998/papers/ols2006-hrtimers-slides.pdf 23 - hrtimer base infrastructure 24 - timeofday and clock source management 25 - clock event management 26 - high resolution timer functionality 27 - dynamic ticks 31 --------------------------- 40 - time ordered enqueueing into a rb-tree 41 - independent of ticks (the processing is based on nanoseconds) [all …]
|
/linux/arch/arm64/boot/dts/freescale/ |
H A D | imx8mm-venice-gw72xx-0x-rs232-rts.dtso | 1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) 5 * GW72xx RS232 with RTS/CTS hardware flow control: 6 * - GPIO4_0 rs485_en needs to be driven low (in-active) 7 * - UART4_TX becomes RTS 8 * - UART4_RX becomes CTS 11 #include <dt-bindings/gpio/gpio.h> 13 #include "imx8mm-pinfunc.h" 15 /dts-v1/; 19 rs485-en-hog { 20 gpio-hog; [all …]
|
H A D | imx8mm-venice-gw73xx-0x-rs232-rts.dtso | 1 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) 5 * GW73xx RS232 with RTS/CTS hardware flow control: 6 * - GPIO4_0 rs485_en needs to be driven low (in-active) 7 * - UART4_TX becomes RTS 8 * - UART4_RX becomes CTS 11 #include <dt-bindings/gpio/gpio.h> 13 #include "imx8mm-pinfunc.h" 15 /dts-v1/; 19 rs485-en-hog { 20 gpio-hog; [all …]
|