/linux-4.1.27/drivers/staging/media/lirc/ |
D | lirc_serial.c | 129 static struct lirc_serial hardware[] = { variable 131 .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_HOMEBREW].lock), 148 .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_IRDEO].lock), 160 .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_IRDEO_REMOTE].lock), 172 .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_ANIMAX].lock), 183 .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_IGOR].lock), 289 soutp(UART_MCR, hardware[type].off); in on() 291 soutp(UART_MCR, hardware[type].on); in on() 297 soutp(UART_MCR, hardware[type].on); in off() 299 soutp(UART_MCR, hardware[type].off); in off() [all …]
|
D | Kconfig | 16 tristate "BT829 based hardware" 19 Driver for the IR interface on BT829-based hardware
|
/linux-4.1.27/sound/isa/sb/ |
D | sb_common.c | 132 switch (chip->hardware) { in snd_sbdsp_probe() 136 chip->hardware = SB_HW_10; in snd_sbdsp_probe() 141 chip->hardware = SB_HW_201; in snd_sbdsp_probe() 144 chip->hardware = SB_HW_20; in snd_sbdsp_probe() 149 chip->hardware = SB_HW_PRO; in snd_sbdsp_probe() 153 chip->hardware = SB_HW_16; in snd_sbdsp_probe() 216 unsigned short hardware, in snd_sbdsp_create() argument 241 (hardware == SB_HW_ALS4000 || in snd_sbdsp_create() 242 hardware == SB_HW_CS5530) ? in snd_sbdsp_create() 251 if (hardware == SB_HW_ALS4000) in snd_sbdsp_create() [all …]
|
D | sb8_midi.c | 70 valid_open_flags = chip->hardware >= SB_HW_20 in snd_sb8dsp_midi_input_open() 82 if (chip->hardware >= SB_HW_20) in snd_sb8dsp_midi_input_open() 97 valid_open_flags = chip->hardware >= SB_HW_20 in snd_sb8dsp_midi_output_open() 109 if (chip->hardware >= SB_HW_20) in snd_sb8dsp_midi_output_open() 162 if (chip->hardware < SB_HW_20) in snd_sb8dsp_midi_input_trigger() 168 if (chip->hardware < SB_HW_20) in snd_sb8dsp_midi_input_trigger() 193 if (chip->hardware >= SB_HW_20) { in snd_sb8dsp_midi_output_write() 275 if (chip->hardware >= SB_HW_20) in snd_sb8dsp_midi()
|
D | sb8.c | 149 if (chip->hardware >= SB_HW_16) { in snd_sb8_probe() 150 if (chip->hardware == SB_HW_ALS100) in snd_sb8_probe() 166 if (chip->hardware == SB_HW_10 || chip->hardware == SB_HW_20) { in snd_sb8_probe() 188 strcpy(card->driver, chip->hardware == SB_HW_PRO ? "SB Pro" : "SB8"); in snd_sb8_probe()
|
D | sb16_main.c | 55 if (chip->hardware == SB_HW_16CSP) { in snd_sb16_csp_playback_prepare() 103 if (chip->hardware == SB_HW_16CSP) { in snd_sb16_csp_capture_prepare() 141 if (chip->hardware == SB_HW_16CSP) { in snd_sb16_csp_update() 155 if (chip->hardware == SB_HW_16CSP) { in snd_sb16_csp_playback_open() 173 if ((chip->hardware == SB_HW_16CSP) && (chip->open == SNDRV_SB_CSP_MODE_DSP_WRITE)) { in snd_sb16_csp_playback_close() 186 if (chip->hardware == SB_HW_16CSP) { in snd_sb16_csp_capture_open() 204 if ((chip->hardware == SB_HW_16CSP) && (chip->open == SNDRV_SB_CSP_MODE_DSP_READ)) { in snd_sb16_csp_capture_close() 564 if (chip->hardware == SB_HW_ALS100) in snd_sb16_playback_open() 566 if (chip->hardware == SB_HW_CS5530) { in snd_sb16_playback_open() 639 if (chip->hardware == SB_HW_ALS100) in snd_sb16_capture_open() [all …]
|
D | sb8_main.c | 115 switch (chip->hardware) { in snd_sb8_playback_prepare() 161 if (chip->hardware == SB_HW_JAZZ16) in snd_sb8_playback_prepare() 265 switch (chip->hardware) { in snd_sb8_capture_prepare() 312 if (chip->hardware == SB_HW_JAZZ16) in snd_sb8_capture_prepare() 389 if (chip->hardware != SB_HW_JAZZ16) in snd_sb8dsp_interrupt() 400 if (chip->hardware != SB_HW_JAZZ16) in snd_sb8dsp_interrupt() 512 switch (chip->hardware) { in snd_sb8_open()
|
/linux-4.1.27/sound/isa/wss/ |
D | wss_lib.c | 423 if ((timeout & CS4231_MCE) == 0 || !(chip->hardware & hw_mask)) in snd_wss_mce_down() 603 if (!(chip->hardware & WSS_HW_AD1848_MASK)) { in snd_wss_calibrate_mute() 611 if (chip->hardware == WSS_HW_INTERWAVE) { in snd_wss_calibrate_mute() 633 if (chip->hardware == WSS_HW_CS4231A || in snd_wss_playback_format() 634 (chip->hardware & WSS_HW_CS4232_MASK)) { in snd_wss_playback_format() 648 } else if (chip->hardware == WSS_HW_AD1845) { in snd_wss_playback_format() 670 if (chip->hardware != WSS_HW_INTERWAVE && !chip->single_dma) { in snd_wss_playback_format() 679 if (chip->hardware == WSS_HW_OPL3SA2) in snd_wss_playback_format() 694 if (chip->hardware == WSS_HW_CS4231A || in snd_wss_capture_format() 695 (chip->hardware & WSS_HW_CS4232_MASK)) { in snd_wss_capture_format() [all …]
|
/linux-4.1.27/arch/tile/gxio/ |
D | Kconfig | 1 # Support direct access to TILE-Gx hardware from user space, via the 8 # TILE-Gx mPIPE and Trio hardware from kernel space. 13 # Support direct access to the TILE-Gx mPIPE hardware from kernel space. 19 # Support direct access to the TILE-Gx TRIO hardware from kernel space. 25 # Support direct access to the TILE-Gx USB hardware from kernel space. 30 # Support direct access to the TILE-Gx UART hardware from kernel space.
|
/linux-4.1.27/drivers/isdn/hardware/ |
D | Kconfig | 2 # ISDN hardware drivers 4 comment "CAPI hardware drivers" 6 source "drivers/isdn/hardware/avm/Kconfig" 8 source "drivers/isdn/hardware/eicon/Kconfig"
|
/linux-4.1.27/drivers/tty/ipwireless/ |
D | tty.c | 48 struct ipw_hardware *hardware; member 217 ret = ipwireless_send_packet(tty->hardware, IPW_CHANNEL_RAS, in ipw_write() 313 ret = ipwireless_set_RTS(tty->hardware, tty->channel_idx, 1); in set_control_lines() 317 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines() 324 ret = ipwireless_set_DTR(tty->hardware, tty->channel_idx, 1); in set_control_lines() 328 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines() 335 ret = ipwireless_set_RTS(tty->hardware, tty->channel_idx, 0); in set_control_lines() 337 ret = ipwireless_set_RTS(tty->hardware, in set_control_lines() 344 ret = ipwireless_set_DTR(tty->hardware, tty->channel_idx, 0); in set_control_lines() 346 ret = ipwireless_set_DTR(tty->hardware, in set_control_lines() [all …]
|
D | main.c | 175 ipwireless_init_hardware_v1(ipw->hardware, link->resource[0]->start, in config_ipwireless() 195 ipw->network = ipwireless_network_create(ipw->hardware); in config_ipwireless() 199 ipw->tty = ipwireless_tty_create(ipw->hardware, ipw->network); in config_ipwireless() 203 ipwireless_init_hardware_v2_v3(ipw->hardware); in config_ipwireless() 268 ipw->hardware = ipwireless_hardware_create(); in ipwireless_attach() 269 if (!ipw->hardware) { in ipwireless_attach() 301 if (ipw->hardware != NULL) in ipwireless_detach() 302 ipwireless_hardware_free(ipw->hardware); in ipwireless_detach()
|
D | network.c | 39 struct ipw_hardware *hardware; member 114 ret = ipwireless_send_packet(network->hardware, in ipwireless_ppp_start_xmit() 130 ret = ipwireless_send_packet(network->hardware, in ipwireless_ppp_start_xmit() 426 network->hardware = hw; in ipwireless_network_create() 444 ipwireless_stop_interrupts(network->hardware); in ipwireless_network_free() 445 ipwireless_associate_network(network->hardware, NULL); in ipwireless_network_free()
|
D | Makefile | 7 ipwireless-y := hardware.o main.o network.o tty.o
|
D | main.h | 55 struct ipw_hardware *hardware; member
|
/linux-4.1.27/drivers/char/hw_random/ |
D | Kconfig | 14 of possibly several hardware random number generators. 16 These hardware random number generators do not feed directly 45 Generator hardware found on Intel i8xx-based motherboards. 58 Generator hardware found on AMD 76x-based motherboards. 71 Generator hardware found on Atmel AT91 devices. 84 Generator hardware found on the Broadcom BCM63xx SoCs. 97 Generator hardware found on the Broadcom BCM2835 SoCs. 110 hardware found on the Broadcom iProc SoCs. 123 Generator hardware found on the AMD Geode LX. 136 Generator hardware found on Niagara2 cpus. [all …]
|
/linux-4.1.27/drivers/isdn/mISDN/ |
D | dsp_dtmf.c | 52 int hardware = 1; in dsp_dtmf_hardware() local 58 hardware = 0; in dsp_dtmf_hardware() 66 hardware = 0; in dsp_dtmf_hardware() 73 hardware = 0; in dsp_dtmf_hardware() 81 hardware = 0; in dsp_dtmf_hardware() 89 hardware = 0; in dsp_dtmf_hardware() 92 dsp->dtmf.hardware = hardware; in dsp_dtmf_hardware() 93 dsp->dtmf.software = !hardware; in dsp_dtmf_hardware()
|
D | dsp.h | 106 int hardware; /* conf is processed by hardware */ member 124 int hardware; /* dtmf uses hardware decoding */ member 149 int hardware; /* tones are generated by hardware */ member 163 int hardware; /* echo is generated by hardware */ member
|
D | dsp_cmx.c | 168 odsp->name, odsp->echo.hardware, odsp->echo.software, in dsp_cmx_debug() 416 if (!dsp->echo.software && !dsp->echo.hardware) { in dsp_cmx_hardware() 436 dsp->echo.hardware = 0; in dsp_cmx_hardware() 440 dsp->echo.hardware = 1; in dsp_cmx_hardware() 455 dsp->echo.hardware = 1; in dsp_cmx_hardware() 499 dsp->echo.hardware = 1; in dsp_cmx_hardware() 564 conf->hardware = 0; in dsp_cmx_hardware() 569 if (member->dsp->echo.hardware || member->dsp->echo.software) { in dsp_cmx_hardware() 670 conf->hardware = 0; in dsp_cmx_hardware() 745 conf->hardware = 1; in dsp_cmx_hardware() [all …]
|
D | Kconfig | 21 decryption. It may use hardware features if available. 44 source "drivers/isdn/hardware/mISDN/Kconfig"
|
/linux-4.1.27/Documentation/powerpc/ |
D | ptrace.txt | 1 GDB intends to support the following hardware debug features of BookE 4 4 hardware breakpoints (IAC) 5 2 hardware watchpoints (read, write and read-write) (DAC) 6 2 value conditions for the hardware watchpoints (DVC) 16 Query for GDB to discover the hardware debug features. The main info to 17 be returned here is the minimum alignment for the hardware watchpoints. 19 an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid 23 GDB: this query will return the number of hardware breakpoints, hardware 47 Sets a hardware breakpoint or watchpoint, according to the provided structure: 80 With this GDB can ask for all kinds of hardware breakpoints and watchpoints [all …]
|
/linux-4.1.27/Documentation/hwmon/ |
D | hwmon-kernel-api.txt | 9 This document describes the API that can be used by hardware monitoring 10 drivers that want to use the hardware monitoring framework. 12 This document does not describe what a hardware monitoring (hwmon) Driver or 14 to communicate with a hardware monitoring device. If you want to know this 22 Each hardware monitoring driver must #include <linux/hwmon.h> and, in most 40 hwmon_device_register registers a hardware monitoring device. The parameter 42 This function returns a pointer to the newly created hardware monitoring device 43 or PTR_ERR for failure. If this registration function is used, hardware 63 hwmon_device_unregister deregisters a registered hardware monitoring device. 64 The parameter of this function is the pointer to the registered hardware [all …]
|
D | sch5627 | 16 SMSC SCH5627 Super I/O chips include complete hardware monitoring 19 The SMSC SCH5627 hardware monitoring part also contains an integrated 24 The hardware monitoring part of the SMSC SCH5627 is accessed by talking
|
D | via686a | 35 The Via 686a southbridge has integrated hardware monitor functionality. 36 It also has an I2C bus, but this driver only supports the hardware monitor. 58 If an alarm triggers, it will remain triggered until the hardware register 61 hardware registers are read whenever any data is read (unless it is less 73 product design but was not interested in its hardware monitoring features, 78 not wired for hardware monitoring.
|
D | smsc47m1 | 36 The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware 38 hardware monitoring block is not supported by this driver, use the 53 If an alarm triggers, it will remain triggered until the hardware register 56 hardware registers are read whenever any data is read (unless it is less
|
D | lm87 | 50 If an alarm triggers, it will remain triggered until the hardware register 53 hardware registers are read whenever any data is read (unless it is less 65 depending on the hardware configuration. 68 time. Which are depends on the hardware setup. This driver normally
|
D | sis5595 | 53 The SiS5595 southbridge has integrated hardware monitor functions. It also 54 has an I2C bus, but this driver only supports the hardware monitor. For the 92 If an alarm triggers, it will remain triggered until the hardware register 94 have disappeared! Note that in the current implementation, all hardware
|
D | it87 | 104 SMBus interface to the hardware monitoring functions. This driver no 119 joysticks and other miscellaneous stuff. For hardware monitoring, they 146 The IT8726F is just bit enhanced IT8716F with additional hardware 153 The IT8603E/IT8623E is a custom design, hardware monitoring part is similar to 157 The IT8620E is another custom design, hardware monitoring part is similar to 193 If an alarm triggers, it will remain triggered until the hardware register 195 have disappeared! Note that in the current implementation, all hardware
|
/linux-4.1.27/drivers/acpi/apei/ |
D | Kconfig | 27 platform hardware errors (such as that from chipset). It 28 works in so called "Firmware First" mode, that is, hardware 30 Linux by firmware. This way, some non-standard hardware 31 error registers or non-standard hardware link can be checked 32 by firmware to produce more valuable hardware error 53 EINJ provides a hardware error injection mechanism, it is 61 ERST is a way provided by APEI to save and retrieve hardware
|
/linux-4.1.27/Documentation/ABI/testing/ |
D | sysfs-ptp | 7 features of PTP hardware clocks. 14 hardware clock registered into the PTP class driver 21 This file contains the name of the PTP hardware clock 32 This file contains the PTP hardware clock's maximum 41 alarms offer by the PTP hardware clock. 48 channels offered by the PTP hardware clock. 55 output channels offered by the PTP hardware clock. 62 offered by the PTP hardware clock. 69 pin offered by the PTP hardware clock. The file name 70 is the hardware dependent pin name. Reading from this [all …]
|
D | debugfs-pfo-nx-crypto | 33 - The total number of AES operations submitted to the hardware. 36 - The total number of bytes hashed by the hardware using SHA-256. 39 - The total number of SHA-256 operations submitted to the hardware. 42 - The total number of bytes hashed by the hardware using SHA-512. 45 - The total number of SHA-512 operations submitted to the hardware.
|
D | sysfs-class-iommu-intel-iommu | 15 The cached hardware capability register value 23 The cached hardware extended capability register
|
D | sysfs-class-rc | 44 If the hardware supports it then scancodes which do not match 59 If the hardware supports it then scancodes which do not match 81 the hardware. 92 If the hardware supports it and wakeup_filter_mask is not 0 then 107 If the hardware supports it and wakeup_filter_mask is not 0 then
|
D | sysfs-module | 34 hardware designers, and the hardware can malfunction when this
|
D | sysfs-bus-usb | 50 This may allow the driver to support more hardware than 109 test; if the test is passed and host supports USB2 hardware LPM 110 (xHCI 1.0 feature), USB2 hardware LPM will be enabled for the 113 or disable) indicating whether or not USB2 hardware LPM is 160 USB 2.0 devices may support hardware link power management (LPM) 171 USB 2.0 devices that support hardware link power management (LPM)
|
D | sysfs-bus-iio | 15 based on hardware generated events (e.g. data ready) or 16 provided by a separate driver for other hardware (e.g. 45 effects data ready triggers, hardware buffers and the sysfs 271 adjusted by using some hardware supported calibration procedure. 509 Configuration of which hardware generated events are passed up 1246 Activates a device feature that runs in firmware/hardware. 1301 A read-only boolean value that indicates if the hardware fifo is 1303 hardware fifo this entry is not present. 1304 The hardware fifo is enabled when the buffer is enabled if the 1305 current hardware fifo watermark level is set and other current [all …]
|
D | sysfs-bus-acpi | 9 fixed ACPI hardware features (like power and sleep 24 This attribute indicates the hardware ID (_HID) of the
|
/linux-4.1.27/drivers/hwmon/pmbus/ |
D | Kconfig | 21 If you say yes here you get hardware monitoring support for generic 32 If you say yes here you get hardware monitoring support for Analog 43 If you say yes here you get hardware monitoring support for National 53 If you say yes here you get hardware monitoring support for Linear 70 If you say yes here you get hardware monitoring support for Maxim 80 If you say yes here you get hardware monitoring support for Maxim 90 If you say yes here you get hardware monitoring support for Maxim 100 If you say yes here you get hardware monitoring support for TI 110 If you say yes here you get hardware monitoring support for TI 121 If you say yes here you get hardware monitoring support for TI [all …]
|
/linux-4.1.27/sound/isa/opti9xx/ |
D | opti92x-ad1848.c | 130 unsigned short hardware; member 186 unsigned short hardware) in snd_opti9xx_init() argument 190 chip->hardware = hardware; in snd_opti9xx_init() 191 strcpy(chip->name, snd_opti9xx_names[hardware]); in snd_opti9xx_init() 206 chip->mc_base_size = opti9xx_mc_size[hardware]; in snd_opti9xx_init() 209 chip->mc_base_size = opti9xx_mc_size[hardware]; in snd_opti9xx_init() 212 switch (hardware) { in snd_opti9xx_init() 216 chip->password = (hardware == OPTi9XX_HW_82C928) ? 0xe2 : 0xe3; in snd_opti9xx_init() 230 chip->mc_base = (hardware == OPTi9XX_HW_82C930) ? 0xf8f : 0xf8d; in snd_opti9xx_init() 239 snd_printk(KERN_ERR "chip %d not supported\n", hardware); in snd_opti9xx_init() [all …]
|
D | miro.c | 108 unsigned short hardware; member 725 switch (miro->hardware) { in snd_miro_mixer() 775 unsigned short hardware) in snd_miro_init() argument 779 chip->hardware = hardware; in snd_miro_init() 780 strcpy(chip->name, snd_opti9xx_names[hardware]); in snd_miro_init() 782 chip->mc_base_size = opti9xx_mc_size[hardware]; in snd_miro_init() 803 switch (hardware) { in snd_miro_init() 813 snd_printk(KERN_ERR "sorry, no support for %d\n", hardware); in snd_miro_init() 829 switch (chip->hardware) { in snd_miro_read() 843 snd_printk(KERN_ERR "sorry, no support for %d\n", chip->hardware); in snd_miro_read() [all …]
|
/linux-4.1.27/Documentation/arm/Samsung-S3C24XX/ |
D | S3C2412.txt | 41 The UART hardware is similar to the S3C2440, and is supported by the 48 The NAND hardware is similar to the S3C2440, and is supported by the 55 The USB hardware is similar to the S3C2410, with extended clock source 76 The RTC hardware is similar to the S3C2410, and is supported by the 83 The watchdog hardware is the same as the S3C2410, and is supported by 95 The IIC hardware is the same as the S3C2410, and is supported by the
|
/linux-4.1.27/sound/drivers/opl3/ |
D | opl3_lib.c | 132 if (opl3->hardware != OPL3_HW_AUTO) in snd_opl3_detect() 137 opl3->hardware = OPL3_HW_OPL2; in snd_opl3_detect() 145 opl3->hardware = OPL3_HW_OPL3; in snd_opl3_detect() 347 unsigned short hardware, in snd_opl3_new() argument 364 opl3->hardware = hardware; in snd_opl3_new() 390 switch (opl3->hardware & OPL3_HW_MASK) { in snd_opl3_init() 408 unsigned short hardware, in snd_opl3_create() argument 416 if ((err = snd_opl3_new(card, hardware, &opl3)) < 0) in snd_opl3_create() 434 switch (opl3->hardware) { in snd_opl3_create() 450 switch (opl3->hardware & OPL3_HW_MASK) { in snd_opl3_create() [all …]
|
D | opl3_seq.c | 74 if (opl3->hardware >= OPL3_HW_OPL3) { in snd_opl3_synth_setup() 179 voices = (opl3->hardware < OPL3_HW_OPL3) ? in snd_opl3_synth_create_port() 194 opl_ver = (opl3->hardware & OPL3_HW_MASK) >> 8; in snd_opl3_synth_create_port() 236 opl_ver = (opl3->hardware & OPL3_HW_MASK) >> 8; in snd_opl3_seq_probe()
|
D | opl3_oss.c | 82 voices = (opl3->hardware < OPL3_HW_OPL3) ? in snd_opl3_oss_create_port() 95 opl_ver = (opl3->hardware & OPL3_HW_MASK) >> 8; in snd_opl3_oss_create_port() 132 if (opl3->hardware < OPL3_HW_OPL3) { in snd_opl3_init_seq_oss()
|
/linux-4.1.27/drivers/crypto/ |
D | Kconfig | 6 Say Y here to get to see options for hardware crypto devices and 84 This is the s390 hardware accelerated implementation of the 94 This is the s390 hardware accelerated implementation of the 104 This is the s390 hardware accelerated implementation of the 116 This is the s390 hardware accelerated implementation of the 119 As of z990 the ECB and CBC mode are hardware accelerated. 120 As of z196 the CTR mode is hardware accelerated. 128 This is the s390 hardware accelerated implementation of the 131 As of z9 the ECB and CBC modes are hardware accelerated 133 As of z10 the ECB and CBC modes are hardware accelerated [all …]
|
/linux-4.1.27/Documentation/ptp/ |
D | ptp.txt | 2 * PTP hardware clock infrastructure for Linux 8 ancillary features of PTP hardware clocks. 12 complete set of PTP hardware clock functionality. 26 ** PTP hardware clock kernel API 31 programming the clock hardware. The clock driver notifies the class 40 ** PTP hardware clock user space API 65 reentrant. Since most hardware implementations treat the time value 72 ** Supported hardware
|
/linux-4.1.27/Documentation/networking/ |
D | spider_net.txt | 28 to receive data from the hardware. A "full" descriptor has data in it, 36 ring is handed off to the hardware, which sequentially fills in the 41 and "tail" pointers, managed by the OS, and a hardware current 43 currently being filled. When this descr is filled, the hardware 46 and everything in front of it should be "empty". If the hardware 50 The tail pointer tails or trails the hardware pointer. When the 51 hardware is ahead, the tail pointer will be pointing at a "full" 56 flowing, then the tail pointer can catch up to the hardware pointer. 64 dma-mapping it so as to make it visible to the hardware. The OS will 91 In the above, the hardware has filled in one descr, number 20. Both [all …]
|
D | multiqueue.txt | 33 default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue. 34 A new round-robin qdisc, sch_multiq also supports multiple hardware queues. The 39 sch_multiq has been added for hardware that wishes to avoid head-of-line 40 blocking. It will cycle though the bands and verify that the hardware queue 44 hardware. Once the association is made, any skb with skb->queue_mapping set, 45 will be queued to the band associated with the hardware queue.
|
D | gianfar.txt | 11 in hardware. The Linux kernel only offloads the TCP and UDP 20 configuring VLANs. The gianfar driver supports hardware insertion and 36 hardware.
|
D | timestamping.txt | 21 multiple timestamp sources, including hardware. Supports generating 119 Report hardware timestamps as generated by 266 ts[1] used to hold hardware timestamps converted to system time. 267 Instead, expose the hardware clock device on the NIC directly as 339 is again deprecated and ts[2] holds a hardware timestamp if set. 345 that is expected to do hardware time stamping. The parameter is defined in 362 A driver which supports hardware time stamping shall update the struct 379 * no outgoing packet will need hardware time stamping; 380 * should a packet arrive which asks for it, no hardware 386 * enables hardware time stamping for outgoing packets; [all …]
|
D | baycom.txt | 46 driver only supports standard serial hardware (8250, 16450, 16550) 111 hardware DCD, par96 implies software DCD). 122 the hardware (options=0). 126 as it is much faster than most hardware squelch circuitry. The 132 feeds the DCD input of the PAR96 modem, the use of the hardware 135 picpar: the picpar modem features a builtin DCD hardware, which is highly 143 for the same hardware resources. Of course only one driver can access a given
|
D | generic-hdlc.txt | 18 for your particular hardware. 24 Make sure the hdlc.o and the hardware driver are loaded. It should 54 loopback - activate hardware loopback (for testing only) 127 The hardware driver has to be build with #define DEBUG_RINGS.
|
D | scaling.txt | 36 IP addresses and TCP ports of a packet. The most common hardware 51 module parameter for specifying the number of hardware queues to 104 Whereas RSS selects the queue and hence CPU that will run the hardware 110 3) it does not increase hardware device interrupt rate (although it does 121 associated flow of the packet. The hash is either provided by hardware 122 or will be computed in the stack. Capable hardware can pass the hash in 128 Each receive hardware queue has an associated list of CPUs to which 160 For a multi-queue system, if RSS is configured so that a hardware 162 and unnecessary. If there are fewer hardware queues than CPUs, then 256 for each flow: rps_dev_flow_table is a table specific to each hardware [all …]
|
D | netdev-features.txt | 33 hardware or software. 78 This callback should not modify hardware nor driver state (should be 91 should update netdev->features to match resulting hardware state. 113 NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit 132 * LLTX driver (deprecated for hardware drivers)
|
/linux-4.1.27/Documentation/devicetree/bindings/misc/ |
D | fsl,qoriq-mc.txt | 3 The Freescale Management Complex (fsl-mc) is a hardware resource 4 manager that manages specialized hardware objects used in 6 block is enabled, pools of hardware resources are available, such as 8 blocks that can be used to create functional hardware objects/devices
|
/linux-4.1.27/Documentation/devicetree/bindings/arm/msm/ |
D | qcom,saw2.txt | 4 Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable 5 power-controller that transitions a piece of hardware (like a processor or 10 Multiple revisions of the SAW hardware are supported using these Device Nodes. 13 data due the the differences in hardware capabilities. Hence the SoC name, the 14 version of the SAW hardware in that SoC and the distinction between cpu (big
|
/linux-4.1.27/drivers/staging/fsl-mc/bus/ |
D | Kconfig | 14 QorIQ Management Complex (fsl-mc). The fsl-mc is a hardware 16 for hardware building-blocks in the SoC that can be used 17 to dynamically create networking hardware objects such as
|
/linux-4.1.27/Documentation/ |
D | clk.txt | 24 The second half of the interface is comprised of the hardware-specific 26 hardware-specific structures needed to model a particular clock. For 28 clk_ops, such as .enable or .set_rate, implies the hardware-specific 31 hardware-specific bits for the hypothetical "foo" hardware. 60 clk_ops pointer in struct clk to perform the hardware-specific parts of 96 Part 3 - hardware clk implementations 99 which abstract the details of struct clk from the hardware-specific bits, and 110 struct clk_gate contains struct clk_hw hw as well as hardware-specific 148 This pattern of abstraction is used for every clock hardware 151 Part 4 - supporting your own clk hardware [all …]
|
D | hw_random.txt | 4 special hardware feature on your CPU or motherboard, 7 sysfs support, plus a hardware-specific driver that plugs 25 the hardware RNG device. This data is NOT CHECKED by any 27 hardware is faulty or has been tampered with). Data is only 28 output if the hardware "has-data" flag is set, but nevertheless 39 "rng_available" attribute lists the hardware-specific drivers 52 About the Intel RNG hardware, from the firmware hub datasheet:
|
D | IRQ-domain.txt | 17 hardware interrupt numbers: whereas in the past, IRQ numbers could 18 be chosen so they matched the hardware IRQ line into the root 23 interrupt numbers, called hardware irq's, from Linux IRQ numbers. 52 required hardware setup. 104 programmable in the hardware. In this case it is best to program the 105 Linux IRQ number into the hardware itself so that no mapping is 108 Linux IRQ number into the hardware. 166 To support such a hardware topology and make software architecture match 167 hardware architecture, an irq_domain data structure is built for each 185 3) irq_domain_activate_irq(): activate interrupt controller hardware to [all …]
|
D | cputopology.txt | 13 the CPU core ID of cpuX. Typically it is the hardware platform's 19 the book ID of cpuX. Typically it is the hardware platform's 25 internal kernel map of cpuX's hardware threads within the same 30 internal kernel map of cpuX's hardware threads within the same 35 internal kernel map of cpuX's hardware threads within the same
|
D | parport.txt | 6 detection of your hardware. This is particularly useful if you want 32 Amiga, Atari, and MFC3 hardware is supported. 151 modes Parallel port's hardware modes, comma-separated, 237 o interrupt-driven, protocol in hardware using PIO 238 o interrupt-driven, protocol in hardware using DMA 246 To turn off the 'protocol in hardware' code paths, disable 248 necessarily _used_; it depends on whether the hardware is available, 256 hardware), to make it use interrupt-driven in-software protocol. 258 If _that_ works fine, then one of the hardware modes isn't working
|
D | IRQ.txt | 8 An IRQ number is a kernel identifier used to talk about a hardware 21 of the hardware involved. The ISA IRQs are a classic example of
|
D | init.txt | 19 required drivers such as storage hardware (such as SCSI or USB!) 29 E) make sure the binary's architecture matches your hardware. 30 E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware.
|
D | rfkill.txt | 42 the system know about hardware-disabled states that may be implemented on 54 use the return value of rfkill_set_hw_state() unless the hardware actually 64 that, a button. If that button influences the hardware then you need to 68 For some platforms, it is possible that the hardware state changes during
|
/linux-4.1.27/drivers/ptp/ |
D | Kconfig | 17 microseconds. In addition, with the help of special hardware 36 getting hardware time stamps on the PTP Ethernet packets 50 getting hardware time stamps on the PTP Ethernet packets 69 getting hardware time stamps on the PTP Ethernet packets 82 clock. The hardware supports time stamping of PTP packets 87 hardware time stamps on the PTP Ethernet packets using the
|
/linux-4.1.27/Documentation/x86/x86_64/ |
D | kernel-stacks | 18 Used for external hardware interrupts. If this is the first external 19 hardware interrupt (i.e. not a nested hardware interrupt) then the 29 hardware stacks cannot nest without races. 40 interrupt-gate descriptor. When an interrupt occurs and the hardware 41 loads such a descriptor, the hardware automatically sets the new stack 85 Used for hardware debug interrupts (interrupt 1) and for software 88 When debugging a kernel, debug interrupts (both hardware and
|
D | boot-options.txt | 15 not recommended, but it might be handy if your hardware 31 (e.g. BIOS or hardware monitoring applications), conflicting 124 Disadvantage is that not all hardware will be completely reinitialized 186 1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all 190 2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU. 194 e.g. if there is no hardware IOMMU in the system and it is need because 199 4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM 200 pSeries and xSeries servers. This hardware IOMMU supports DMA address 210 noforce Don't force hardware IOMMU usage when it is not needed. 212 force Force the use of the hardware IOMMU even when it is [all …]
|
/linux-4.1.27/drivers/parport/ |
D | Kconfig | 12 the architecture might have PC parallel port hardware. 43 tristate "PC-style hardware" 68 Many parallel port chipsets provide hardware that can speed up 106 Say Y here if you need support for the parallel port hardware on 120 tristate "Atari hardware" 124 Say Y here if you need support for the parallel port hardware on 134 tristate "Sparc hardware" 140 actually have pc style hardware instead. 146 Say Y here if you need support for the parallel port hardware on
|
/linux-4.1.27/sound/pci/oxygen/ |
D | xonar_hdmi.c | 80 struct snd_pcm_hardware *hardware) in xonar_hdmi_pcm_hardware_filter() argument 83 hardware->rates = SNDRV_PCM_RATE_44100 | in xonar_hdmi_pcm_hardware_filter() 87 hardware->rate_min = 44100; in xonar_hdmi_pcm_hardware_filter()
|
/linux-4.1.27/arch/xtensa/ |
D | Kconfig.debug | 31 Correct operation of this instruction requires some cooperation from hardware 33 It is easy to make wrong hardware configuration, this test should catch it early. 35 Say 'N' on stable hardware.
|
/linux-4.1.27/Documentation/w1/masters/ |
D | ds2490 | 24 - The hardware will detect when devices are attached to the bus on the 37 - The hardware supports normal, flexible, and overdrive bus 43 - The hardware supports detecting some error conditions, such as 48 available, the bulk read will return an error and the hardware will 59 the ds2490 hardware, but if the module was unloaded, then reloaded 64 show 0 bytes written. Detaching qemu from the ds2490 hardware and
|
/linux-4.1.27/Documentation/fb/ |
D | framebuffer.txt | 11 The frame buffer device provides an abstraction for the graphics hardware. It 12 represents the frame buffer of some video hardware and allows application 13 software to access the graphics hardware through a well-defined interface, so 14 the software doesn't need to know anything about the low-level (hardware 50 graphics card in addition to the built-in hardware. The corresponding frame 75 some video hardware. 78 the hardware can be queried and set. The color map handling works via ioctls, 82 - You can request unchangeable information about the hardware, like name, 86 - You can request and change variable information about the hardware, like 89 values to meet the hardware's capabilities (or return EINVAL if that isn't [all …]
|
D | arkfb.txt | 31 hardware). This limitation is not enforced by driver. Text mode supports 8bit 32 wide fonts only (hardware limitation) and 16bit tall fonts (driver 56 * hardware cursor
|
D | udlfb.txt | 8 pairing that with a hardware framebuffer (16MB) on the other end of the 9 USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI 13 result with a local shadow of the remote hardware framebuffer to identify 34 * The actual hardware functionality of DisplayLink chips matches nearly 44 * Fbdev's mmap interface assumes a real hardware framebuffer is mapped. 64 means that from a hardware and fbdev software perspective, everything is good. 147 hardware. Includes compression and protocol overhead
|
D | s3fb.txt | 40 hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This 42 (hardware limitation) and 16bit tall fonts (driver limitation). Text mode 66 * hardware cursor
|
D | vt8623fb.txt | 30 driver. Text mode supports 8bit wide fonts only (hardware limitation) and 51 * hardware cursor
|
/linux-4.1.27/Documentation/devicetree/bindings/reset/ |
D | st,sti-picophyreset.txt | 8 The actual action taken when softreset is asserted is hardware dependent. 9 However, when asserted it may not be possible to access the hardware's 10 registers and after an assert/deassert sequence the hardware's previous state
|
D | st,sti-softreset.txt | 9 The actual action taken when softreset is asserted is hardware dependent. 10 However, when asserted it may not be possible to access the hardware's 11 registers and after an assert/deassert sequence the hardware's previous state
|
D | st,sti-powerdown.txt | 10 The actual action taken when powerdown is asserted is hardware dependent. 11 However, when asserted it may not be possible to access the hardware's 12 registers and after an assert/deassert sequence the hardware's previous state
|
/linux-4.1.27/Documentation/devicetree/bindings/serial/ |
D | sirf-uart.txt | 9 - fifosize : Should define hardware rx/tx fifo size 13 - sirf,uart-has-rtscts: we have hardware flow controller pins in hardware
|
/linux-4.1.27/arch/openrisc/ |
D | Kconfig | 91 bool "Have instruction l.mul for hardware multiply" 94 Select this if your implementation has a hardware multiply instruction 97 bool "Have instruction l.div for hardware divide" 100 Select this if your implementation has a hardware divide instruction 116 in hardware and the OR1200 does not have it.
|
/linux-4.1.27/Documentation/s390/ |
D | zfcpdump.txt | 3 System z machines (z900 or higher) provide hardware support for creating system 7 hardware saves some memory plus the register sets of the boot CPU before the 8 dump tool is loaded. There exists an SCLP hardware interface to obtain the saved 25 memory, which has been saved by hardware is read by the driver via the SCLP 26 hardware interface. The second part is just copied from the non overwritten real
|
D | qeth.txt | 11 When run on HiperSockets Bridge Capable Port hardware, and the state 23 When run on HiperSockets Bridge Capable Port hardware with host address
|
/linux-4.1.27/drivers/clocksource/ |
D | Kconfig | 126 This must be disabled for hardware validation purposes to detect any 127 hardware anomalies of missing events. 204 the Compare Match Timer (CMT) hardware available in 16/32/48-bit 214 Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas. 215 This hardware comes with 16 bit-timer registers. 224 the 32-bit Timer Unit (TMU) hardware available on a wide range 233 the 48-bit System Timer (STI) hardware available on a SoCs
|
/linux-4.1.27/Documentation/devicetree/bindings/gpio/ |
D | gpio-altera.txt | 12 - #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware. 16 hardware is synthesized. This field is required if the Altera GPIO controller 18 but hardware synthesized. Required if GPIO is used as an interrupt
|
/linux-4.1.27/Documentation/devicetree/bindings/mfd/ |
D | mfd.txt | 3 These devices comprise a nexus for heterogeneous hardware blocks containing 4 more than one non-unique yet varying hardware functionality. 16 mix of unrelated hardware devices.
|
/linux-4.1.27/Documentation/devicetree/bindings/sound/ |
D | ti,tas5086.txt | 12 assert a hardware reset at probe time. 16 split-capacitor charge period. The hardware chip 20 When not specified, the hardware default of 1300ms
|
D | adi,adau1701.txt | 7 and ADDR1, as wired in hardware. 13 assert a hardware reset at probe time.
|
/linux-4.1.27/drivers/hsi/controllers/ |
D | Kconfig | 7 tristate "OMAP SSI hardware driver" 12 If you say Y here, you will enable the OMAP SSI hardware driver.
|
/linux-4.1.27/arch/arm/vfp/ |
D | vfphw.S | 72 @ VFP hardware support entry point. 102 @ sufficient to determine that the hardware state is valid. 106 @ thread wants ownership of the VFP hardware, save the old 136 @ This thread has ownership of the current hardware context. 138 @ case the saved state is newer than the hardware context.
|
/linux-4.1.27/Documentation/sound/alsa/ |
D | timestamping.txt | 5 general case, but specific hardware may have synchronization 38 of time as measured by different components of audio hardware. In 58 supported in hardware by sample counters or wallclocks (e.g. with 68 The application can query what the hardware supports, define which 74 time with dedicated hardware, possibly synchronized with system time, 79 in hardware/low-level driver, the type is overridden as DEFAULT and the 102 hardware, the absolute link time could also be used to define a 108 hardware components the delay is typically not known with precision. 124 timestamps from hardware registers or from IPC takes time, the more 131 In some hardware-specific configuration, the system timestamp is [all …]
|
D | hdspm.txt | 13 hardware functionality: 87 hardware pointer used. 101 one, I decided to export the hardware structure, so that of 124 !!!! This is a hardware-function but is in conflict with the 145 !!!! This is no pure hardware function but was implemented by 180 automatically from hardware sending MADI.
|
/linux-4.1.27/Documentation/devicetree/ |
D | 00-INDEX | 2 hardware layout to Linux in a device-independent manner, simplifying hardware
|
/linux-4.1.27/drivers/media/usb/cx231xx/ |
D | Kconfig | 24 cx231xx hardware has a builtin RX/TX support. However, a few 25 designs opted to not use it, but, instead, some other hardware. 26 This module enables the usage of those other hardware, like the
|
/linux-4.1.27/Documentation/usb/ |
D | ohci.txt | 9 hardware register protocols used to talk to USB 1.1 host controllers. As 11 Intel, it pushes more intelligence into the hardware. USB 1.1 controllers 27 risks can be minimized by making sure the hardware always has transfers to
|
D | rio.txt | 72 (Compaq and others) hardware port should work. 80 'lspci' which is only needed to determine the type of USB hardware 85 Using `lspci -v`, determine the type of USB hardware available. 105 hardware (determined from the steps above), 'USB Diamond Rio500 support', and
|
/linux-4.1.27/Documentation/video4linux/bttv/ |
D | README.freeze | 5 It might be a bttv driver bug. It also might be bad hardware. It also 41 hardware bugs 44 Some hardware can't deal with PCI-PCI transfers (i.e. grabber => vga). 58 greatest workarounds for hardware bugs might fix these problems. 70 it share the IRQ with some other piece of hardware. IRQ sharing with
|
D | README.WINVIEW | 17 hardware. The driver was written by visual inspection of the card. If you 19 continue buying their hardware unless they support Linux.
|
/linux-4.1.27/sound/drivers/mpu401/ |
D | mpu401_uart.c | 232 if (mpu->hardware != MPU401_HW_TRID4DWAVE) { in snd_mpu401_uart_cmd() 237 if (mpu->hardware != MPU401_HW_SB) { in snd_mpu401_uart_cmd() 526 unsigned short hardware, in snd_mpu401_uart_new() argument 557 mpu->hardware = hardware; in snd_mpu401_uart_new() 560 int res_size = hardware == MPU401_HW_PC98II ? 4 : 2; in snd_mpu401_uart_new() 578 if (hardware == MPU401_HW_PC98II) in snd_mpu401_uart_new()
|
/linux-4.1.27/Documentation/devicetree/bindings/thermal/ |
D | rockchip-thermal.txt | 16 - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. 17 - rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO. 18 - rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW
|
/linux-4.1.27/Documentation/ABI/stable/ |
D | sysfs-class-backlight | 27 Show the actual brightness by querying the hardware. 46 "raw": The driver controls hardware registers directly 53 the hardware and the OS independently updating the
|
/linux-4.1.27/drivers/isdn/ |
D | Kconfig | 49 access ISDN hardware in a device independent way. (For details see 53 three-party conferences (if supported by the specific hardware 56 Select this option and the appropriate hardware driver below if 63 source "drivers/isdn/hardware/Kconfig"
|
D | Makefile | 8 obj-$(CONFIG_ISDN) += hardware/
|
/linux-4.1.27/Documentation/devicetree/bindings/mtd/ |
D | gpmc-nand.txt | 20 - nand-bus-width: Set this numeric value to 16 if the hardware 43 ELM is an on-chip hardware engine on TI SoC which is used for 45 ELM hardware engines should specify this device node in .dtsi 101 (1) support of built in hardware engines. 103 support ecc-schemes with hardware error-correction (BCHx_HW). However 106 library remains equivalent to their hardware counter-part, but there is
|
D | atmel-nand.txt | 6 and hardware ECC controller if available. 7 If the hardware ECC is PMECC, it should contain address and size for 24 - atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware.
|
/linux-4.1.27/include/sound/ |
D | es1688.h | 42 unsigned short hardware; /* see to ES1688_HW_XXXX */ member 117 unsigned short hardware);
|
D | opl3.h | 306 unsigned short hardware; member 357 int snd_opl3_new(struct snd_card *card, unsigned short hardware, 362 unsigned short hardware,
|
D | mpu401.h | 74 unsigned short hardware; /* MPU401_HW_XXXX */ member 132 unsigned short hardware,
|
D | wss.h | 89 unsigned short hardware; /* see to WSS_HW_XXXX */ member 154 unsigned short hardware, 167 unsigned short hardware,
|
/linux-4.1.27/tools/perf/ |
D | design.txt | 5 Performance counters are special hardware registers available on most modern 13 hardware capabilities. It provides per task and per CPU counters, counter 16 underlying hardware counters. 78 If 'raw_type' is 1, then the counter will count a hardware event 91 A counter of PERF_TYPE_HARDWARE will count the hardware event 100 * Common hardware events, generalized by the kernel: 127 * Special "software" counters provided by the kernel, even if the hardware 206 on the CPU if at all possible. It only applies to hardware counters 208 CPU (e.g. because there are not enough hardware counters or because of 218 not otherwise accessible and that might disrupt other hardware [all …]
|
/linux-4.1.27/Documentation/devicetree/bindings/clock/ti/ |
D | gate.txt | 21 "ti,dss-gate-clock" - gate clock with DSS specific hardware handling 22 "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling 26 "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, 27 required for a hardware errata
|
D | interface.txt | 9 clock) and hardware autoidle enable / disable. 17 "ti,omap3-no-wait-interface-clock" - interface clock which has no hardware
|
/linux-4.1.27/arch/powerpc/kvm/ |
D | Kconfig | 56 This module provides access to the hardware capabilities through 71 This module provides access to the hardware capabilities through 87 If you say Y here, KVM will use the hardware virtualization 89 guest operating systems will run at full hardware speed 151 This module provides access to the hardware capabilities through 167 This module provides access to the hardware capabilities through
|
/linux-4.1.27/Documentation/input/ |
D | elantech.txt | 6 Extra information for hardware version 1 found and 9 Version 2 (EeePC) hardware support based on patches 19 3. Differentiating hardware versions 52 hardware versions unimaginatively called version 1,version 2, version 3 65 The driver tries to support both hardware versions and should be compatible 78 Currently only the registers for hardware version 1 are somewhat understood. 85 driver always puts the hardware into absolute mode not all information 107 "2" will turn on packet debugging. For hardware version 1 the default is 119 non-zero value will turn it ON. For hardware version 1 the default is ON. 138 verification is done by the driver on hardware version 3 and 4. The [all …]
|
D | gameport-programming.txt | 18 If your hardware supports more than one io address, and your driver can 19 choose which one to program the hardware to, starting from the more exotic 26 If your hardware supports a gameport address that is not mapped to ISA io 160 Function for calibrating the ADC hardware. When called, axes[0..3] should be 163 sensitivity of the ADC hardware so that the maximums fit in its range and 165 the hardware so that they give valid values.
|
/linux-4.1.27/drivers/media/platform/vivid/ |
D | Kconfig | 13 TV, S-Video and HDMI capture hardware, including VBI support for 19 to reproduce in real hardware.
|
/linux-4.1.27/Documentation/devicetree/bindings/crypto/ |
D | img-hash.txt | 1 Imagination Technologies hardware hash accelerator 3 The hash accelerator provides hardware hashing acceleration for
|
/linux-4.1.27/net/mpls/ |
D | Kconfig | 11 hardware speeds (before hardware was capable of routing ipv4 packets),
|
/linux-4.1.27/Documentation/arm/ |
D | cluster-pm-race-avoidance.txt | 5 cluster setup and teardown operations and to manage hardware coherency 35 writing some hardware registers and invalidating large caches), other 70 UP: The CPU or cluster is active and coherent at the hardware 119 or hardware event 144 a) an explicit hardware power-up operation, resulting 147 b) a hardware event, such as an interrupt. 152 A CPU cannot start participating in hardware coherency until the 292 a) an explicit hardware power-up operation, resulting 295 b) a hardware event, such as an interrupt. 301 enabling of hardware coherency at the cluster level and any [all …]
|
D | Interrupts | 61 * Mask the IRQ in hardware. 65 * Unmask the IRQ in hardware. 84 the hardware IRQ if possible. If not, may call the handler 105 need to leave the hardware IRQ enabled while processing it, and queueing 107 "simple" handler is very basic, and does not perform any hardware 164 hardware based. Mixing level-based and edge-based IRQs on the same
|
/linux-4.1.27/Documentation/devicetree/bindings/watchdog/ |
D | atmel-wdt.txt | 19 - atmel,watchdog-type : Should be "hardware" or "software". Hardware watchdog 25 This is valid only when using "hardware" watchdog. 43 atmel,watchdog-type = "hardware";
|
/linux-4.1.27/arch/arm/ |
D | Kconfig-nommu | 40 The kernel needs to change the hardware exception vectors. 41 In nommu mode, the hardware exception vectors are normally 51 external support to redirect the hardware exception vectors to
|
/linux-4.1.27/Documentation/arm64/ |
D | legacy_instructions.txt | 5 the instruction execution in hardware. 26 enabling/disabling of hardware support for the execution of these 27 instructions. Using hardware execution generally provides better
|
D | arm-acpi.txt | 9 The ARMv8 kernel implements the reduced hardware model of ACPI version 17 specifications, then ACPI may not be a good fit for the hardware. 30 exist in Linux for describing non-enumerable hardware, after all. In this 37 -- ACPI’s bytecode (AML) allows the platform to encode hardware behavior, 38 while DT explicitly does not support this. For hardware vendors, being 40 system releases on new hardware. 44 flexibility in hardware design. 59 table as hardware vendors and other OS vendors. In fact, there is no 67 responsibility for hardware behaviour cannot solely be the domain of the 70 to understand all the minute details of the hardware so that the OS doesn’t [all …]
|
/linux-4.1.27/kernel/irq/ |
D | Kconfig | 24 # Facility to allocate a hardware interrupt. This is legacy support 77 bool "Expose hardware/virtual IRQ mapping via debugfs" 80 This option will show the mapping relationship between hardware irq
|
/linux-4.1.27/sound/drivers/opl4/ |
D | opl4_lib.c | 133 opl4->hardware = OPL3_HW_OPL4; in snd_opl4_detect() 136 opl4->hardware = OPL3_HW_OPL4_ML; in snd_opl4_detect() 242 err = snd_opl3_create(card, fm_port, fm_port + 2, opl4->hardware, 1, &opl3); in snd_opl4_create() 258 if (opl4->hardware < OPL3_HW_OPL4_ML) in snd_opl4_create()
|
/linux-4.1.27/drivers/crypto/ux500/ |
D | Kconfig | 12 This selects the crypto driver for the UX500_CRYP hardware. It supports 21 This selects the hash driver for the UX500_HASH hardware.
|
/linux-4.1.27/Documentation/devicetree/bindings/soc/fsl/ |
D | qman-portals.txt | 22 Definition: Must include "fsl,qman-portal-<hardware revision>" 53 Definition: The hardware index of the channel. This can also be 82 Definition: The phandle to the particular hardware device that this 100 Definition: The hardware index of the channel. This can also be
|
D | bman.txt | 14 BMan supports hardware allocation and deallocation of buffers belonging to pools 85 The size of the FBPR must be chosen by observing the hardware features configured 88 etc.). The size configured in the DT must reflect the hardware capabilities and
|
/linux-4.1.27/Documentation/devicetree/bindings/i2c/ |
D | i2c-mux-pinctrl.txt | 48 state will be programmed into hardware. 51 on a child bus, the idle pinctrl state will be programmed into hardware. 54 left programmed into hardware whenever no access is being made of a device on
|
/linux-4.1.27/drivers/mailbox/ |
D | Kconfig | 4 Mailbox is a framework to control hardware communication between 6 signals. Say Y if your platform supports hardware mailboxes. 32 Mailbox implementation for OMAP family chips with hardware for
|
/linux-4.1.27/drivers/infiniband/ |
D | Kconfig | 11 InfiniBand hardware. 32 hardware for fast-path operations. You will also need 33 libibverbs, libibcm and a hardware driver library from
|
/linux-4.1.27/Documentation/devicetree/bindings/dma/xilinx/ |
D | xilinx_vdma.txt | 17 the hardware. 32 - xlnx,include-dre: Tells hardware is configured for Data 35 enabled/disabled in hardware.
|
D | xilinx_dma.txt | 16 the hardware. 26 - xlnx,include-dre: Tells whether hardware is configured for Data
|
/linux-4.1.27/drivers/staging/iio/ |
D | Kconfig | 24 tristate "An example driver with no hardware requirements" 28 without hardware.
|
/linux-4.1.27/Documentation/devicetree/bindings/mmc/ |
D | mmc-pwrseq-emmc.txt | 1 * The simple eMMC hardware reset provider 9 doesn't have hardware reset logic connected to emmc card and (limited or
|
/linux-4.1.27/drivers/sh/intc/ |
D | Kconfig | 13 This enables support for hardware-assisted userspace hardirq 29 taken care of automatically by hardware for distributed
|
/linux-4.1.27/Documentation/devicetree/bindings/video/ |
D | simple-framebuffer.txt | 4 the bootloader, with the assumption that the display hardware has already 10 If the devicetree contains nodes for the display hardware used by a simplefb, 14 real hardware. The bindings for the hw nodes must specify which node is 54 - display : phandle pointing to the primary display hardware node
|
/linux-4.1.27/Documentation/dvb/ |
D | ci.txt | 12 hardware handling.This module is loaded automatically if a CI 71 The disadvantage is that the driver/hardware has to manage the rest. For 109 application. The driver/hardware will take care of all that. 114 as simple as that. The driver/hardware has to take care of that. 163 features of the hardware that cannot be implemented by the API are achieved 165 used to exchange the data to maintain compatibility with other hardware.
|
D | readme.txt | 32 contains a list of supported hardware. 50 TT DEC2000/DEC3000 USB DVB hardware.
|
/linux-4.1.27/drivers/s390/char/ |
D | Kconfig | 86 This option enables the hardware console interface for system 137 hardware options in order to access a tape device. 140 hardware drivers. 142 comment "S/390 tape hardware support" 147 prompt "Support for 3480/3490 tape hardware" 156 prompt "Support for 3590 tape hardware"
|
/linux-4.1.27/Documentation/devicetree/bindings/gpu/ |
D | st,stih4xx.txt | 15 - clocks: from common clock binding: handle hardware IP needed clocks, the 33 - clocks: from common clock binding: handle hardware IP needed clocks, the 44 - sti-tvout: video out hardware block 67 - clocks: from common clock binding: handle hardware IP needed clocks, the 80 - clocks: from common clock binding: handle hardware IP needed clocks, the 93 - clocks: from common clock binding: handle hardware IP needed clocks, the 107 - clocks: from common clock binding: handle hardware IP needed clocks, the
|
/linux-4.1.27/sound/isa/cs423x/ |
D | cs4236_lib.c | 277 unsigned short hardware, in snd_cs4236_create() argument 287 if (hardware == WSS_HW_DETECT) in snd_cs4236_create() 288 hardware = WSS_HW_DETECT3; in snd_cs4236_create() 291 irq, dma1, dma2, hardware, hwshare, &chip); in snd_cs4236_create() 295 if ((chip->hardware & WSS_HW_CS4236B_MASK) == 0) { in snd_cs4236_create() 297 chip->hardware); in snd_cs4236_create() 367 switch (chip->hardware) { in snd_cs4236_create() 1044 if (chip->hardware == WSS_HW_CS4235 || in snd_cs4236_mixer() 1045 chip->hardware == WSS_HW_CS4239) { in snd_cs4236_mixer() 1056 switch (chip->hardware) { in snd_cs4236_mixer() [all …]
|
/linux-4.1.27/drivers/watchdog/ |
D | Kconfig | 16 reboot the machine) and a driver for hardware watchdog boards, which 61 from some situations that the hardware watchdog will recover 186 boards have hardware problems that will cause the machine to simply 422 This is the driver for the hardware watchdog 549 This is the driver for the hardware watchdog on Single Board 572 This is the driver for the hardware watchdog on the ALi M1535 PMU. 583 This is the driver for the hardware watchdog on the ALi M7101 PMU 596 This is the driver for the hardware watchdog on the Fintek 631 This is the driver for the hardware watchdog built in to the 674 This is the driver for the hardware watchdog on the IB700 Single [all …]
|
/linux-4.1.27/drivers/media/rc/img-ir/ |
D | Kconfig | 17 processing power than using hardware decode, but can be useful for 24 Say Y here to enable the hardware decode driver which decodes the IR 25 signals in hardware. This is more reliable, consumes less processing
|
/linux-4.1.27/Documentation/isdn/ |
D | README.concap | 24 Thus, a device driver for a certain type of hardware must support 34 protocol which is unique to the hardware type of the interface. The LAN 38 method in the device structure) using some hardware type specific support 69 several different interfaces of even different hardware type, e.g. the 73 from the hardware specific interface stuff such code could be shared 99 - receive data from lower (hardware) layer 100 - process connect indication from lower (hardware) layer 101 - process disconnect indication from lower (hardware) layer 148 - request data being submitted by lower layer (device hardware)
|
/linux-4.1.27/drivers/usb/wusbcore/ |
D | Kconfig | 16 select even if you don't have the hardware. 30 hardware.
|
/linux-4.1.27/Documentation/power/regulator/ |
D | design.txt | 11 for the system, potentially including lasting hardware damage. 17 => The API should make no changes to the hardware state unless it has
|
/linux-4.1.27/arch/arm/boot/dts/ |
D | s5pv210-smdkc110.dts | 12 * available in Linux 3.15 and intends to provide equivalent level of hardware 13 * support. Due to lack of hardware, _no_ testing has been performed.
|
D | s5pv210-torbreck.dts | 12 * available in Linux 3.15 and intends to provide equivalent level of hardware 13 * support. Due to lack of hardware, _no_ testing has been performed.
|
/linux-4.1.27/Documentation/devicetree/bindings/ |
D | marvell.txt | 174 Represent DMA hardware associated with the MPSC (multiprotocol 197 Represent baud rate generator hardware associated with the MPSC 224 Represent the Serial Communications Unit device hardware. 237 Represent the Discovery's MPSC routing hardware 250 Represent the Discovery's MPSC DMA interrupt hardware registers 275 - cell-index : the hardware index of this cell in the MPSC core 301 Represent the Discovery's watchdog timer hardware 316 Represent the Discovery's I2C hardware 337 Represent the Discovery's PIC hardware 358 Represent the Discovery's MPP hardware [all …]
|
D | common-properties.txt | 3 The ePAPR specification does not define any properties related to hardware 18 will ever be performed. Use this if the hardware "self-adjusts"
|
/linux-4.1.27/Documentation/cpu-freq/ |
D | core.txt | 62 hardware limitations. 65 hardware failure. 68 - if two hardware drivers failed to agree on a new policy before this 69 stage, the incompatible hardware shall be shut down, and the user
|
D | amd-powernow.txt | 3 management capabilities in AMD processors. As the hardware 7 Note that the driver's will not load on the "wrong" hardware,
|
/linux-4.1.27/Documentation/devicetree/bindings/powerpc/fsl/ |
D | fman.txt | 151 The Frame Manager (FMan) supports several types of hardware ports: 173 Definition: Specifies the hardware port id. 174 Each hardware port on the FMan has its own hardware PortID. 175 Super set of all hardware Port IDs available at FMan Reference 178 Each hardware port is assigned a 4KB, port-specific page in 179 the FMan hardware port memory region (which is part of the 180 FMan memory map). The first 4 KB in the FMan hardware ports 182 The subsequent 63 4KB pages are allocated to the hardware 389 due to a hardware problem), or to advertise that all relevant
|
/linux-4.1.27/Documentation/devicetree/bindings/timer/ |
D | renesas,mtu2.txt | 6 Channels share hardware resources but their counter and compare match value 7 are independent. The MTU2 hardware supports five channels indexed from 0 to 4.
|
D | renesas,tmu.txt | 6 Channels share hardware resources but their counter and compare match value 7 are independent. The TMU hardware supports up to three channels.
|
D | renesas,cmt.txt | 6 Channels share hardware resources but their counter and compare match value 8 channels supported by the CMT model. Channel indices represent the hardware 67 CMT0 on R8A7790 implements hardware channels 5 and 6 only and names
|
/linux-4.1.27/drivers/gpu/drm/i915/ |
D | Kconfig | 33 hardware in older X.org releases. 64 bool "Enable preliminary support for prerelease Intel hardware by default" 68 Choose this option if you have prerelease Intel hardware and want the
|
/linux-4.1.27/drivers/uwb/ |
D | Kconfig | 40 is safe to select any even if you do not have the hardware. 56 is safe to select any even if you do not have the hardware. 68 is safe to select any even if you do not have the hardware.
|
/linux-4.1.27/Documentation/devicetree/bindings/interrupt-controller/ |
D | brcm,bcm7120-l2-intc.txt | 3 This interrupt controller hardware is a second level interrupt controller that 7 Such an interrupt controller has the following hardware design: 22 The typical hardware layout for this controller is represented below:
|
D | brcm,bcm7038-l1-intc.txt | 5 since BCM7038 has contained this hardware. 7 Key elements of the hardware design include:
|
/linux-4.1.27/drivers/isdn/hisax/ |
D | tei.c | 170 cs = (struct IsdnCardState *) st->l1.hardware; in tei_id_assign() 244 cs = (struct IsdnCardState *) st->l1.hardware; in tei_id_remove() 280 cs = (struct IsdnCardState *) st->l1.hardware; in tei_id_req_tout() 303 cs = (struct IsdnCardState *) st->l1.hardware; in tei_id_ver_tout() 376 cs = (struct IsdnCardState *) st->l1.hardware; in tei_l2tei() 400 VHiSax_putstatus(st->l1.hardware, "tei ", fmt, args); in tei_debug()
|
D | isdnl1.c | 146 struct IsdnCardState *cs = st->l1.hardware; in l1m_debug() 552 L1deactivated(st->l1.hardware); in l1_timer3() 570 L1activated(st->l1.hardware); in l1_timer_act() 580 L1deactivated(st->l1.hardware); in l1_timer_deact() 599 L1deactivated(st->l1.hardware); in l1_activate_no() 803 struct IsdnCardState *cs = (struct IsdnCardState *) st->l1.hardware; in dch_l2l1() 892 st->l1.hardware = cs; in setstack_HiSax() 920 struct IsdnCardState *cs = st->l1.hardware; in setstack_l1_B()
|
D | lmgr.c | 36 HiSax_putstatus(st->l1.hardware, "manager: MDL_ERROR", in hisax_manager()
|
/linux-4.1.27/arch/arm/kvm/ |
D | interrupts.S | 115 @ Store hardware CP15 state and load guest state 194 @ Let host read hardware MIDR 198 @ Back to hardware MPIDR 486 @ Switch VFP/NEON hardware state to the guest's
|
/linux-4.1.27/arch/powerpc/platforms/ |
D | Kconfig | 46 Support for running natively on the hardware, i.e. without 88 The MPIC global timer is a hardware timer inside the 90 specified interval times out, the hardware timer generates 253 However, on some cpus it appears that the TAU interrupt hardware 257 Unless you are extending the TAU driver, or enjoy kernel/hardware 264 The TAU hardware can compare the temperature to an upper and lower 267 either changing a lot, or the TAU hardware is broken (likely on some 291 Say Y here if you're going to use hardware that connects to the
|
/linux-4.1.27/drivers/staging/android/ |
D | Kconfig | 38 drivers. Sync implementations can take advantage of hardware 47 syncrhronization. Useful when there is no hardware primitive backing
|
/linux-4.1.27/drivers/net/wireless/ath/carl9170/ |
D | Kconfig | 49 Provides a hardware random number generator to the kernel. 53 usbmon [software] or special usb sniffer hardware.
|
/linux-4.1.27/arch/mips/sgi-ip27/ |
D | Kconfig | 11 for more memory. Your hardware is almost certainly running in 19 for more memory. Your hardware is almost certainly running in
|
/linux-4.1.27/Documentation/networking/mac80211_hwsim/ |
D | README | 15 the normal case of using real WLAN hardware. From the mac80211 view 16 point, mac80211_hwsim is yet another hardware driver, i.e., no changes 22 of real hardware, so it is easy to generate an arbitrary test setup
|
/linux-4.1.27/Documentation/infiniband/ |
D | user_verbs.txt | 4 enables direct userspace access to IB hardware via "verbs," as 11 userspace driver for your InfiniBand hardware. For example, to use 20 directly to hardware registers mmap()ed into userspace, with no
|
/linux-4.1.27/arch/blackfin/ |
D | Kconfig.debug | 32 When enabled, the hardware error interrupt is never disabled, and 35 hardware error interrupts and need to know where they are coming 42 By default, the Blackfin hardware errors are not exact - the error 162 By selecting this option, every time the 16 hardware entries in 189 quickly fill up the hardware trace buffer. When debugging crashes, 190 the hardware trace may indicate that the problem lies in kernel 193 Say Y here to disable hardware tracing in some known "jumpy" pieces
|
/linux-4.1.27/Documentation/timers/ |
D | hpet.txt | 3 The High Precision Event Timer (HPET) hardware follows a specification 11 additional hardware to support periodic interrupts. The comparators are
|
D | highres.txt | 48 specific portion is reduced to the low level hardware details of the clock 50 decision. The low level code provides hardware setup and readout routines and 85 hardware related handling and to allow easy addition and utilization of new 88 service handler, which is almost inherently hardware dependent. 111 from the hardware level handler. This removes a lot of duplicated code from the 149 which inform hrtimers about availability of new hardware. hrtimers validates 153 necessary hardware support. 156 global clock event devices. The support of such hardware would involve IPI
|
/linux-4.1.27/Documentation/devicetree/bindings/arm/tegra/ |
D | nvidia,tegra20-pmc.txt | 56 hardware-triggered thermal reset will be enabled. 58 Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): 66 Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'): 67 - nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
|
/linux-4.1.27/Documentation/acpi/ |
D | scan_handlers.txt | 8 of hardware. This causes a struct acpi_device object to be created and 17 During ACPI-based device hot-remove device nodes representing pieces of hardware 30 Those additional configuration tasks usually depend on the type of the hardware 32 basis of the device node's hardware ID (HID). They are performed by objects
|
/linux-4.1.27/Documentation/power/ |
D | pm_qos_interface.txt | 190 This device PM QoS type is used to support systems in which hardware may switch 192 mode chosen by the hardware attempts to save energy in an overly aggressive way, 200 hardware. 206 to switch the underlying hardware latency tolerance control mechanism to an 208 the hardware supports a special "no requirement" setting, the callback is 209 expected to use it. That allows software to prevent the hardware from 218 but do not let the hardware control latency tolerance" and writing "auto" to it 219 allows the hardware to be switched to the autonomous mode if there are no other
|
/linux-4.1.27/Documentation/devicetree/bindings/dma/ |
D | snps-dma.txt | 7 - dma-channels: Number of channels supported by hardware 16 - data_width: Maximum data width supported by hardware per AHB master
|
D | img-mdc-dma.txt | 14 The maximum burst size is this value multiplied by the hardware-reported bus 24 the number reported by the hardware is used.
|
/linux-4.1.27/drivers/memory/tegra/ |
D | Kconfig | 6 This driver supports the Memory Controller (MC) hardware found on
|
/linux-4.1.27/drivers/usb/gadget/ |
D | Kconfig | 22 The USB hardware is asymmetric, which makes it easier to set up: 34 a USB peripheral device. Configure one hardware driver for your 40 don't have this kind of hardware (except maybe inside Linux PDAs). 211 the peripheral hardware. 213 Gadget drivers are hardware-neutral, or "platform independent", 221 # this first set of drivers all depend on bulk-capable hardware. 284 favor of simpler vendor-specific hardware, but is widely 294 On hardware that can't implement the full protocol, 321 and therefore can be supported by more hardware. Technically ECM and 359 test software, like the "usbtest" driver, to put your hardware
|
/linux-4.1.27/Documentation/virtual/kvm/ |
D | timekeeping.txt | 22 First, we will describe the various timekeeping hardware available, then 28 information relevant to KVM and hardware-based virtualization. 34 First we discuss the basic hardware devices available. TSC and the related 267 the APIC CPU-local memory-mapped hardware. Beware that CPU errata may affect 283 the de facto standard of PC hardware is to emulate these older devices. Some 284 systems designated as legacy free may support only the HPET as a hardware timer 287 The HPET spec is rather loose and vague, requiring at least 3 hardware timers, 320 RDMSR, RDTSC, or RDTSCP (when available) instructions. In the past, hardware 321 limitations made it possible to write the TSC, but generally on old hardware it 338 Both VMX and SVM provide extension fields in the virtualization hardware which [all …]
|
/linux-4.1.27/Documentation/devicetree/bindings/pinctrl/ |
D | pinctrl-bindings.txt | 6 just like any other hardware module. 10 node in device tree, just like any other hardware module. 91 * but in use on an SoC that doesn't have any pin control hardware 164 for all hardware or binding structures. Each individual binding document 224 binding for the hardware defines: 227 - bias-pull-up, -down and -pin-default take as optional argument on hardware
|
/linux-4.1.27/Documentation/wimax/ |
D | README.i2400m | 65 been supplied with your hardware. 74 * BUSTYPE will be usb or sdio, depending on the hardware you have. 75 Each hardware type comes with its own firmware and will not work 96 hardware-glue. The OS-glue interfaces with Linux. The hardware-glue 99 easily reuse the hardware-glue to write drivers for other OSes; note 100 the hardware glue part is written as a native Linux driver; no
|
/linux-4.1.27/Documentation/devicetree/bindings/regulator/ |
D | regulator.txt | 15 For hardware which supports disabling ramp rate, it should be explicitly 35 every hardware so the valid modes are documented on each regulator 38 modes depends on the capabilities of every hardware so each device binding
|
/linux-4.1.27/Documentation/watchdog/ |
D | watchdog-kernel-api.txt | 129 Some watchdog timer hardware can only be started and not be stopped. The 130 driver supporting this hardware needs to make sure that a start and stop 132 that regularly sends a keepalive ping to the watchdog timer hardware. 134 Not all watchdog timer hardware supports the same functionality. That's why 138 hardware. 141 Most hardware that does not support this as a separate function uses the 142 start function to restart the watchdog timer hardware. And that's also what 144 timer hardware it will either use the ping operation (when available) or the
|
/linux-4.1.27/drivers/staging/octeon-usb/ |
D | TODO | 9 - possibly eliminate the extra "hardware abstraction layer"
|
/linux-4.1.27/drivers/platform/chrome/ |
D | Kconfig | 2 # Platform support for Chrome OS hardware (Chromebooks and Chromeboxes) 6 bool "Platform support for Chrome hardware"
|
/linux-4.1.27/samples/ |
D | Kconfig | 36 tristate "Build kernel hardware breakpoint examples -- loadable module only" 39 This builds kernel hardware breakpoint example modules.
|
/linux-4.1.27/drivers/hwmon/ |
D | Kconfig | 10 Hardware monitoring devices let you monitor the hardware health 245 ADT7473, ADT7475, ADT7476 and ADT7490 hardware monitoring 408 If you say yes here you get support for hardware monitoring 419 If you say yes here you get support for hardware monitoring 441 If you say yes here you get support for hardware monitoring 536 power sensors and capping hardware in various IBM System X 638 If you say yes here you get access to the hardware monitoring 750 If you say yes here you get support for hardware monitoring 858 hardware monitoring. 1076 If you say yes here you get access to the hardware monitoring [all …]
|
/linux-4.1.27/drivers/soc/mediatek/ |
D | Kconfig | 12 hardware to connect the PMIC.
|
/linux-4.1.27/Documentation/platform/ |
D | x86-laptop-drivers.txt | 3 List of supported hardware:
|
/linux-4.1.27/drivers/crypto/vmx/ |
D | Kconfig | 7 This module supports acceleration for AES and GHASH in hardware. If you
|
/linux-4.1.27/drivers/iommu/ |
D | Kconfig | 91 With this option you can enable support for AMD IOMMU hardware in 92 your system. An IOMMU is a hardware component which provides 95 system from misbehaving device drivers or hardware. 117 hardware. Select this option if you want to use devices that support 212 hardware included on Tegra SoCs. 221 This driver supports the IOMMU hardware (SMMU) found on NVIDIA Tegra
|
/linux-4.1.27/tools/perf/Documentation/ |
D | perf-record.txt | 48 - a hardware breakpoint event in the form of '\mem:addr[/len][:access]' 133 will produce call graphs from the hardware LBR registers. The 200 underlying hardware, the type of branches of interest, and the executed code. 211 - in_tx: only when the target is in a hardware transaction 212 - no_tx: only when the target is not in a hardware transaction 213 - abort_tx: only when the target is a hardware transaction abort
|
/linux-4.1.27/Documentation/vm/ |
D | numa | 6 hardware view and the Linux software view. 8 From the hardware perspective, a NUMA system is a computer platform that 11 disambiguate the hardware view of these physical components/assemblies 26 is handled in hardware by the processor caches and/or the system interconnect. 44 Linux divides the system's hardware resources into multiple software 46 of the hardware platform, abstracting away some of the details for some
|
/linux-4.1.27/Documentation/devicetree/bindings/arm/mrvl/ |
D | tauros2.txt | 11 arch/arm/include/asm/hardware/cache-tauros2.h
|
/linux-4.1.27/drivers/thunderbolt/ |
D | Kconfig | 8 Apple hardware.
|