Home
last modified time | relevance | path

Searched +full:hardware +full:- +full:driven (Results 1 – 25 of 230) sorted by relevance

12345678910

/linux/drivers/gpio/
H A Dgpio-stp-xway.c1 // 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 Drenesas,rza1-ports.yaml1 # 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 Dintro.rst17 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 Ddriver.rst24 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 Dparport.rst4 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 Dleds-class.rst8 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 Dst,stm32-timers.yaml1 # 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 DKconfig1 # 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 Dnouveau_thermal.rst12 -----------
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 Dipmi_si_sm.h1 /* 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 Dspi-lm70llp.rst2 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 Dnvmem.yaml1 # 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 DKconfig10 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 Darm-acpi.rst12 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 Dpinconf-generic.h1 /* 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 Damdgpu_irq.c32 * 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 Dcoresight-trbe.rst1 .. 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 Dqemu_e500.c1 // 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 DKconfig1 # 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 Dqcom,rpm-common.yaml1 # 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 Ddsi-controller.yaml1 # 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 Dedma.h1 /* 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 Dhighres.rst8 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 Dimx8mm-venice-gw72xx-0x-rs232-rts.dtso1 // 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 Dimx8mm-venice-gw73xx-0x-rs232-rts.dtso1 // 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 …]

12345678910