| /linux/Documentation/arch/sh/ |
| H A D | new-machine.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 Adding a new board to LinuxSH
7 Paul Mundt <lethal@linux-sh.org>
18 of the board-specific code (with the exception of stboards) ended up
19 in arch/sh/kernel/ directly, with board-specific headers ending up in
20 include/asm-sh/. For the new kernel, things are broken out by board type,
24 Board-specific code::
27 |-- arch
28 | `-- sh
29 | `-- boards
[all …]
|
| /linux/Documentation/arch/arm/google/ |
| H A D | chromebook-boot-flow.rst | 1 .. SPDX-License-Identifier: GPL-2.0
16 - Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
17 - Board revision number, determined at runtime (perhaps by reading GPIO
19 - SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
23 - google,$(BOARD)-rev$(REV)-sku$(SKU)
24 - google,$(BOARD)-rev$(REV)
25 - google,$(BOARD)-sku$(SKU)
26 - google,$(BOARD)
31 Note that for some boards there may be extra board-specific logic to inject
35 find one that matches the most specific compatible. It will then look
[all …]
|
| /linux/drivers/video/fbdev/ |
| H A D | hecubafb.c | 2 * linux/drivers/video/hecubafb.c -- FB driver for Hecuba/Apollo controller
12 * This work was possible because of apollo display code from E-Ink's website
15 * available by E-Ink on its support site. Some commands such as 0xA4
24 * It is intended to be architecture independent. A board specific driver
46 /* Display specific information */
75 par->board->set_data(par, data); in apollo_send_data()
78 par->board->set_ctl(par, HCB_DS_BIT, 0); in apollo_send_data()
81 par->board->wait_for_ack(par, 0); in apollo_send_data()
84 par->board->set_ctl(par, HCB_DS_BIT, 1); in apollo_send_data()
87 par->board->wait_for_ack(par, 1); in apollo_send_data()
[all …]
|
| /linux/include/video/ |
| H A D | hecubafb.h | 2 * hecubafb.h - definitions for the hecuba framebuffer driver
15 /* Apollo controller specific defines */
22 /* Hecuba interface specific defines */
29 /* struct used by hecuba. board specific stuff comes from *board */
32 struct hecuba_board *board; member
37 /* board specific routines
38 board drivers can implement wait_for_ack with interrupts if desired. if
|
| H A D | broadsheetfb.h | 2 * broadsheetfb.h - definitions for the broadsheet framebuffer driver
36 /* Broadsheet pin interface specific defines */
41 /* Broadsheet IO interface specific defines */
45 /* struct used by broadsheet. board specific stuff comes from *board */
48 struct broadsheet_board *board; member
56 /* board specific routines */
|
| H A D | metronomefb.h | 2 * metronomefb.h - definitions for the metronome framebuffer driver
18 u16 args[((64-2)/2)];
22 /* struct used by metronome. board specific stuff comes from *board */
31 struct metronome_board *board; member
38 /* board specific routines and data */
|
| /linux/Documentation/devicetree/ |
| H A D | usage-model.rst | 1 .. SPDX-License-Identifier: GPL-2.0
44 ----------
56 In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
57 and 64-bit support, the decision was made to require DT support on all
61 blob without requiring a real Open Firmware implementation. U-Boot,
66 existing non-DT aware firmware.
74 -------------
79 -------------------
84 hardware configuration from the board and device driver support in the
86 it allows board and device support to become data driven; to make
[all …]
|
| /linux/arch/mips/include/asm/octeon/ |
| H A D | cvmx-helper-board.h | 7 * Copyright (c) 2003-2008 Cavium Networks
14 * AS-IS and WITHOUT ANY WARRANTY; without even the implied warranty
21 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
30 * Helper functions to abstract board specific data about
31 * network ports from the rest of the cvmx-helper files.
37 #include <asm/octeon/cvmx-helper.h>
58 #define CVMX_HELPER_BOARD_MGMT_IPD_PORT -10
62 * port. A result of -1 means there isn't a MII capable PHY
66 * This function must be modified for every new Octeon board.
68 * data to determine board types and revisions. It relies on the
[all …]
|
| /linux/Documentation/devicetree/bindings/arm/ |
| H A D | ste-nomadik.txt | 1 ST-Ericsson Nomadik Device Tree Bindings
3 For various board the "board" node may contain specific properties
4 that pertain to this particular board, such as board-specific GPIOs.
7 - Nomadik System and reset controller used for basic chip control, clock
9 - compatible: must be "stericsson,nomadik,src"
13 Nomadik NHK-15 board manufactured by ST Microelectronics:
17 compatible="st,nomadik-nhk-15";
23 compatible="calaosystems,usb-s8815";
25 Required node: usb-s8815
29 usb-s8815 {
[all …]
|
| /linux/Documentation/arch/arm/spear/ |
| H A D | overview.rst | 6 ------------
11 The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are
19 - SPEAr3XX (3XX SOC series, based on ARM9)
20 - SPEAr300 (SOC)
21 - SPEAr300 Evaluation Board
22 - SPEAr310 (SOC)
23 - SPEAr310 Evaluation Board
24 - SPEAr320 (SOC)
25 - SPEAr320 Evaluation Board
26 - SPEAr6XX (6XX SOC series, based on ARM9)
[all …]
|
| /linux/Documentation/process/ |
| H A D | maintainer-soc.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 --------
10 The SoC subsystem is a place of aggregation for SoC-specific code.
13 * devicetrees for 32- & 64-bit ARM and RISC-V
14 * 32-bit ARM board files (arch/arm/mach*)
15 * 32- & 64-bit ARM defconfigs
16 * SoC-specific drivers across architectures, in particular for 32- & 64-bit
17 ARM, RISC-V and Loongarch
19 These "SoC-specific drivers" do not include clock, GPIO etc drivers that have
20 other top-level maintainers. The drivers/soc/ directory is generally meant
[all …]
|
| /linux/include/linux/usb/ |
| H A D | musb.h | 1 /* SPDX-License-Identifier: GPL-2.0 */
4 * Inventra (Multidrop) Highspeed Dual-Role Controllers: (M)HDRC.
6 * Board initialization should put one of these into dev->platform_data,
7 * probably on some platform_device named "musb-hdrc". It encapsulates
14 /* The USB role is defined by the connector used on the board, so long as
19 MUSB_HOST, /* A or Mini-A connector */
20 MUSB_PERIPHERAL, /* B or Mini-B connector */
21 MUSB_OTG /* Mini-AB connector */
64 struct musb_fifo_cfg *fifo_cfg; /* board fifo configuration */
67 /* MUSB configuration-specific details */
[all …]
|
| /linux/arch/arm/mach-omap1/ |
| H A D | devices.c | 1 // SPDX-License-Identifier: GPL-2.0-or-later
3 * linux/arch/arm/mach-omap1/devices.c
8 #include <linux/dma-mapping.h>
15 #include <linux/platform_data/omap-wd-timer.h>
16 #include <linux/soc/ti/omap1-io.h>
51 .id = -1,
64 /*-------------------------------------------------------------------------*/
81 if (mmc_controller->slots[0].wires == 4) { in omap1_mmc_mux()
84 if (!mmc_controller->slots[0].nomux) in omap1_mmc_mux()
92 if (!mmc_controller->slots[1].nomux) { in omap1_mmc_mux()
[all …]
|
| /linux/Documentation/networking/devlink/ |
| H A D | devlink-info.rst | 1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
7 The ``devlink-info`` mechanism enables device drivers to report device
10 The original motivation for the ``devlink-info`` API was twofold:
12 - making it possible to automate device and firmware management in a fleet
13 of machines in a vendor-independent fashion (see also
14 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
15 - name the per component FW versions (as opposed to the crowded ethtool
18 ``devlink-info`` supports reporting multiple types of objects. Reporting driver
19 versions is generally discouraged - here, and via any other Linux API.
21 .. list-table:: List of top level info objects
[all …]
|
| H A D | bnxt.rst | 1 .. SPDX-License-Identifier: GPL-2.0
13 .. list-table:: Generic parameters implemented
15 * - Name
16 - Mode
17 * - ``enable_sriov``
18 - Permanent
19 * - ``ignore_ari``
20 - Permanent
21 * - ``msix_vec_per_pf_max``
22 - Permanent
[all …]
|
| /linux/arch/mips/cavium-octeon/executive/ |
| H A D | cvmx-helper-board.c | 7 * Copyright (c) 2003-2008 Cavium Networks
14 * AS-IS and WITHOUT ANY WARRANTY; without even the implied warranty
21 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
30 * Helper functions to abstract board specific data about
31 * network ports from the rest of the cvmx-helper files.
36 #include <asm/octeon/cvmx-bootinfo.h>
38 #include <asm/octeon/cvmx-config.h>
40 #include <asm/octeon/cvmx-helper.h>
41 #include <asm/octeon/cvmx-helper-util.h>
42 #include <asm/octeon/cvmx-helper-board.h>
[all …]
|
| /linux/arch/arm64/boot/dts/qcom/ |
| H A D | msm8916-ufi.dtsi | 1 // SPDX-License-Identifier: GPL-2.0-only
3 #include "msm8916-pm8916.dtsi"
5 #include <dt-bindings/gpio/gpio.h>
6 #include <dt-bindings/leds/common.h>
9 chassis-type = "embedded";
17 stdout-path = "serial0";
20 gpio-keys {
21 compatible = "gpio-keys";
23 pinctrl-0 = <&button_default>;
24 pinctrl-names = "default";
[all …]
|
| /linux/arch/m68k/include/uapi/asm/ |
| H A D | bootinfo-vme.h | 1 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
3 ** asm/bootinfo-vme.h -- VME-specific boot information definitions
14 * VME-specific tags
17 #define BI_VME_TYPE 0x8000 /* VME sub-architecture (__be32) */
18 #define BI_VME_BRDINFO 0x8001 /* VME board information (struct) */
39 * Board ID data structure - pointer to this retrieved from Bug by head.S
42 * Motorola VME boards. Contains board number, Bug version, board
45 * Note, bytes 12 and 13 are board no in BCD (0162,0166,0167,0177,etc)
|
| /linux/arch/arm/mach-pxa/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only
3 bool "PXA2xx/PXA3xx-based"
57 comment "Legacy board files"
64 Basix, Connex, ws-200ax, ws-400ax systems
67 prompt "Gumstix Carrier/Expansion Board"
71 bool "Enable AM200EPD board support"
74 bool "Enable AM300EPD board support"
79 bool "SHARP Zaurus SL-5600, SL-C7xx and SL-Cxx00 Models"
84 Sharp Zaurus SL-5600 (Poodle), SL-C700 (Corgi),
85 SL-C750 (Shepherd), SL-C760 (Husky), SL-C1000 (Akita),
[all …]
|
| /linux/drivers/comedi/drivers/ni_routing/ |
| H A D | README | 15 increasingly hard to find and the NI-MHDDK (comments in in example code).
22 varying purposes, but the end-user had to gain a knowledge of register
26 programming manuals and vendor-provided documentation are _not_ even
27 close to the same names that are in the end-user documentation.
32 NIDAQmx(-base) c-libraries, nor with register level programming, _nor_
34 information is through the proprietary NI-MAX software, which currently only
36 cannot be exported from NI-MAX, except by screenshot.
41 of signal routing capabilities of National Instruments data-acquisition and
42 control hardware. In order to facilitate the transfer of register-level
43 information _and_ the knowledge of valid routes per device, a few specific
[all …]
|
| /linux/Documentation/spi/ |
| H A D | spi-summary.rst | 5 02-Feb-2012
8 ------------
17 clocking modes through which data is exchanged; mode-0 and mode-3 are most
32 - SPI may be used for request/response style device protocols, as with
35 - It may also be used to stream data in either direction (half duplex),
38 - Some devices may use eight bit words. Others may use different word
39 lengths, such as streams of 12-bit or 20-bit digital samples.
41 - Words are usually sent with their most significant bit (MSB) first,
44 - Sometimes SPI is used to daisy-chain devices, like shift registers.
51 SPI is only one of the names used by such four-wire protocols, and
[all …]
|
| /linux/Documentation/devicetree/bindings/display/hisilicon/ |
| H A D | dw-dsi.txt | 1 Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
7 - compatible: value should be "hisilicon,hi6220-dsi".
8 - reg: physical base address and length of dsi controller's registers.
9 - clocks: contains APB clock phandle + clock-specifier pair.
10 - clock-names: should be "pclk".
11 - ports: contains DSI controller input and output sub port.
17 A example of HiKey board hi6220 SoC and board specific DT entry:
20 SoC specific:
22 compatible = "hisilicon,hi6220-dsi";
25 clock-names = "pclk";
[all …]
|
| /linux/Documentation/arch/powerpc/ |
| H A D | bootwrapper.rst | 17 others. U-Boot is typically found on embedded PowerPC hardware, but there
28 U-Boot (for versions that don't understand the device
31 are all embedded inside the U-Boot uImage file format
37 bd_info structure used in the old U-Boot interfaces,
38 cuImages are platform specific. Each specific
39 U-Boot platform has a different platform init file
41 from the platform specific bd_info file. The platform
42 specific cuImage platform init code can be found in
44 cuImage init code for a specific board can be found in
55 dtbImages have platform specific code for extracting
[all …]
|
| /linux/include/linux/ |
| H A D | fsl_devices.h | 1 /* SPDX-License-Identifier: GPL-2.0-or-later */
17 PHY CLK to become stable - 10ms*/
30 * Each sub-arch has its own master list of unique devices and
31 * enumerates them by enum fsl_devices in a sub-arch specific header
34 * first is device specific information that help identify any
36 * information that may be defined by the board or how the device
40 * - platform data structures: <driver>_platform_data
41 * - platform data device flags: FSL_<driver>_DEV_<FLAG>
42 * - platform data board flags: FSL_<driver>_BRD_<FLAG>
47 FSL_USB_VER_NONE = -1,
[all …]
|
| /linux/Documentation/devicetree/bindings/input/ |
| H A D | brcm,bcm-keypad.txt | 3 Broadcom Keypad controller is used to interface a SoC with a matrix-type
6 The keypad controller can sense a key-press and key-release and report the
9 This binding is based on the matrix-keymap binding with the following
12 keypad,num-rows and keypad,num-columns are required.
14 Required SoC Specific Properties:
15 - compatible: should be "brcm,bcm-keypad"
17 - reg: physical base address of the controller and length of memory mapped
20 - interrupts: The interrupt number to the cpu.
22 Board Specific Properties:
23 - keypad,num-rows: Number of row lines connected to the keypad
[all …]
|