| /openbmc/u-boot/drivers/pinctrl/renesas/ |
| H A D | Kconfig | 16 the GPIO definitions and pin control functions for each available
26 the GPIO definitions and pin control functions for each available
36 the GPIO definitions and pin control functions for each available
46 the GPIO definitions and pin control functions for each available
56 the GPIO definitions and pin control functions for each available
66 the GPIO definitions and pin control functions for each available
76 the GPIO definitions and pin control functions for each available
86 the GPIO definitions and pin control functions for each available
96 the GPIO definitions and pin control functions for each available
106 the GPIO definitions and pin control functions for each available
|
| /openbmc/u-boot/doc/device-tree-bindings/gpio/ |
| H A D | nvidia,tegra186-gpio.txt | 26 address space, each of which access the same underlying state. See the hardware
31 implemented by the SoC. Each GPIO is assigned to a port, and a port may control
32 a number of GPIOs. Thus, each GPIO is named according to an alphabetical port
36 The number of ports implemented by each GPIO controller varies. The number of
37 implemented GPIOs within each port varies. GPIO registers within a controller
48 Each GPIO controller can generate a number of interrupt signals. Each signal
54 Each GPIO controller in fact generates multiple interrupts signals for each set
55 of ports. Each GPIO may be configured to feed into a specific one of the
56 interrupt signals generated by a set-of-ports. The intent is for each generated
57 signal to be routed to a different CPU, thus allowing different CPUs to each
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/src/ |
| H A D | system.cpp | 30 // Add devices and rails in each chassis to the map in buildIDMap()
39 // Clear any cached data in each chassis in clearCache()
48 // Clear error history in each chassis in clearErrorHistory()
57 // Close devices in each chassis in closeDevices()
66 // Configure devices in each chassis in configure()
75 // Detect phase faults in regulator devices in each chassis in detectPhaseFaults()
84 // Monitor sensors in each chassis in monitorSensors()
|
| /openbmc/phosphor-pid-control/ |
| H A D | README.md | 11 application will use thermal control, such that each defined zone is kept within
16 configuration files or dbus. Each zone will contain at least one fan and at
21 The system will run a control loop for each zone with the attempt to maintain
31 each zone, and has a master thread which listens for dbus messages. Each zone
42 A configuration file will need to exist for each board.
44 Each zone must have at least one fan that it exclusively controls. Each zone
78 The plan is to listen for fan_tach updates for each fan in a background thread.
79 This will receive an update from phosphor-hwmon each time it updates any sensor
82 By default phosphor-hwmon reads each sensor in turn and then sleeps for 1
89 Each zone will require a control loop that monitors the associated thermals and
|
| /openbmc/u-boot/drivers/pinctrl/ |
| H A D | Kconfig | 27 It is totally up to the implementation of each low-level driver.
52 allows the required function to be selected for each pin.
115 both the GPIO definitions and pin control functions for each
126 pin-config module. Each I/O pin may be dedicated as a general-purpose
127 I/O or be assigned to a function of an embedded peripheral. Each I/O
132 feature on each I/O pin.
146 Supports individual pin selection and configuration for each
158 the GPIO definitions and pin control functions for each available
168 both the GPIO definitions and pin control functions for each
199 the GPIO definitions and pin control functions for each available
[all …]
|
| /openbmc/u-boot/doc/device-tree-bindings/gpu/ |
| H A D | nvidia,tegra20-host1x.txt | 14 - resets: Must contain an entry for each entry in reset-names.
19 The host1x top-level node defines a number of children, each representing one
30 - resets: Must contain an entry for each entry in reset-names.
43 - resets: Must contain an entry for each entry in reset-names.
56 - resets: Must contain an entry for each entry in reset-names.
69 - resets: Must contain an entry for each entry in reset-names.
82 - resets: Must contain an entry for each entry in reset-names.
92 - clocks: Must contain an entry for each entry in clock-names.
99 - resets: Must contain an entry for each entry in reset-names.
111 - clocks: Must contain an entry for each entry in clock-names.
[all …]
|
| /openbmc/u-boot/doc/device-tree-bindings/pinctrl/ |
| H A D | pinctrl-bindings.txt | 5 controllers. Each pin controller must be represented as a node in device tree,
9 designated client devices. Again, each client device must be represented as a
16 device is inactive. Hence, each client device can define a set of named
35 For each client device individually, every pin state is assigned an integer
36 ID. These numbers start at 0, and are contiguous. For each state ID, a unique
37 property exists to define the pin configuration. Each state may also be
41 Each client device's own binding determines the set of states that must be
47 pinctrl-0: List of phandles, each pointing at a pin configuration
52 from multiple nodes for a single pin controller, each
65 pinctrl-1: List of phandles, each pointing at a pin configuration
[all …]
|
| /openbmc/pldm/libpldmresponder/test/pdr_jsons/state_sensor/malformed/ |
| H A D | sensor_pdr.json | 1 // This JSON is tied with BMC's PDRs. Each entry is used to identify a group of
7 // Each sensor in each group of composite sensors has a separate entry and the
11 // for each corresponding entry in the "states".
|
| /openbmc/phosphor-pid-control/pid/ |
| H A D | zone_interface.hpp | 17 * In a Zone you have a set of PIDs which feed each other. Fan PIDs are fed set
42 /** For each fan input in the zone, read each to update the cachedValue and
46 /** For each thermal input in the zone, read each to update the cachedValue
51 /** For each fan and thermal input in the zone, set the cachedValue to 0 and
87 * used by each fan PID.
125 /** For each fan pid, do processing. */
127 /** For each thermal pid, do processing. */
|
| /openbmc/openbmc/poky/meta/files/common-licenses/ |
| H A D | LPL-1.02 | 10 in the case of each Contributor,
28 Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, w…
29 Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, w…
30 …each Contributor grants the licenses to its Contributions set forth herein, no assurances are prov…
31 Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contrib…
37 …of this Agreement or Distributor`s own license agreement is included with each copy of the Program…
42 B. Each Distributor must include the following in a conspicuous location in the Program:
45 …each Contributor must identify itself as the originator of its Contribution in a manner that reaso…
55 …E, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely…
73 LUCENT may publish new versions (including revisions) of this Agreement from time to time. Each new…
[all …]
|
| H A D | IPL-1.0 | 12 in the case of each Contributor,
40 Subject to the terms of this Agreement, each Contributor hereby
46 Subject to the terms of this Agreement, each Contributor hereby
58 Recipient understands that although each Contributor grants the
62 Each Contributor disclaims any liability to Recipient for claims
65 rights and licenses granted hereunder, each Recipient hereby assumes
71 Each Contributor represents that to its knowledge it has
97 a copy of this Agreement must be included with each copy of the
99 Each Contributor must include the following in a conspicuous location in the Program:
103 In addition, each Contributor must identify itself as the originator
[all …]
|
| H A D | LPL-1.0 | 10 b. in the case of each Contributor,
31 …a. Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusiv…
33 …b. Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusiv…
35 …each Contributor grants the licenses to its Contributions set forth herein, no assurances are prov…
37 …d. Each Contributor represents that to its knowledge it has sufficient copyright rights in its Co…
44 …of this Agreement or Distributor's own license agreement is included with each copy of the Program…
51 B. Each Distributor must include the following in a conspicuous location in the Program:
55 …C. In addition, each Contributor must identify itself as the originator of its Contribution, if an…
65 …E, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely…
79 <OWNER> may publish new versions (including revisions) of this Agreement from time to time. Each ne…
[all …]
|
| H A D | CPL-1.0 | 15 b) in the case of each subsequent Contributor:
42 a) Subject to the terms of this Agreement, each Contributor hereby grants
48 b) Subject to the terms of this Agreement, each Contributor hereby grants
58 c) Recipient understands that although each Contributor grants the licenses
61 property rights of any other entity. Each Contributor disclaims any liability to
64 rights and licenses granted hereunder, each Recipient hereby assumes sole
70 d) Each Contributor represents that to its knowledge it has sufficient
103 b) a copy of this Agreement must be included with each copy of the Program.
108 Each Contributor must identify itself as the originator of its Contribution, if
149 NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each
[all …]
|
| H A D | EPL-1.0 | 11 b) in the case of each subsequent Contributor:
25 a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive…
26 b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive…
27 …each Contributor grants the licenses to its Contributions set forth herein, no assurances are prov…
28 d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Cont…
42 b) a copy of this Agreement must be included with each copy of the Program.
45 Each Contributor must identify itself as the originator of its Contribution, if any, in a manner th…
55 …E, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely…
69 …sibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the …
71 … under this Agreement more than one year after the cause of action arose. Each party waives its ri…
|
| H A D | APL-1.0 | 16 (b) In the case of each Subsequent Contributor, the Subsequent Work originating from and distribute…
36 1.11. "LICENSED WORK" means the Initial Work and/or any Subsequent Work, in each case including por…
68 (a) Subject to the terms of this License, the Initial Contributor hereby grants each Recipient a wo…
76 (b) Subject to the terms of this License, each Subsequent Contributor hereby grants each Recipient …
95 …each Subsequent Contributor grants the licenses to its Contributions set forth herein, no represen…
107 …g without limitation Exhibit A and the accompanying Supplement File) with each copy of the License…
121 …lable under this License and a copy of this License must be included with each copy of the Source …
125 Each Subsequent Contributor must ensure that the notice set out in Part 5 of Exhibit A is included …
141 …Each Subsequent Contributor (including the Initial Contributor where the Initial Contributor also …
143 …ements (in each case, the "EARLIER DESCRIPTION REQUIREMENTS") for documenting changes resulting in…
[all …]
|
| /openbmc/openbmc/poky/meta/conf/machine/include/ |
| H A D | README | 17 with the machine configuration, or each other in a multilib
18 configuration. Each tuning file can add to this list using "+=", but
22 Each tune should specify a reasonable default, which can be overriden by
32 tuning ends up with features which conflict with each other.
38 specific tune. This is a list of features that a tune support, each
59 See each architecture's README for details for that CPU family.
64 each architecture. See each architectures README for details for that
|
| /openbmc/pldm/tools/fw-update/ |
| H A D | README.md | 37 in JSON format. Typically it is not necessary to write this file each time the
75 is of type List. Each List entry corresponds to an firmware device ID record.
80 Records. Each such record can have the following properties:
84 - add each bit that is to be set to 1 to the list "DeviceUpdateOptionFlags"
95 is of type List. Each List entry corresponds to a descriptor. The first
128 of type List. Each List entry corresponds to an Individual Component Image
133 Information records. Each such record can have the following properties:
141 - add each bit that is to be set to 1 to the list "ComponentOptions"
145 - add each bit that is to be set to 1 to the list
|
| /openbmc/pldm/libpldmresponder/examples/pdr/ |
| H A D | sensor_pdr.json | 1 // This JSON is tied with BMC's PDRs. Each entry is used to identify a group of
7 // Each sensor in each group of composite sensors has a separate entry and the
11 // for each corresponding entry in the "states".
|
| /openbmc/u-boot/doc/ |
| H A D | README.bloblist | 10 a central structure. Each record of information is assigned a tag so that its
11 owner can find it and update it. Each record is generally described by a C
19 sometimes TPL). It is passed through to each successive part of the boot and
31 While each blob in the bloblist can be of any length, bloblists are designed to
33 change the length of a blob once it has been written. Each blob is normally
40 Each blob has a tag which is a 32-bit number. This uniquely identifies the
|
| /openbmc/phosphor-fan-presence/docs/control/ |
| H A D | events.md | 3 This file defines the events that dictate how fan control operates. Each event
61 property on each D-Bus object in the group, update the new value in the object
65 the Present property on each member of the group and set the fan target hold to
99 for each.
119 2. `name_has_owner` - Populates the service owned state from D-Bus for each
124 Signal triggers subscribe to certain D-Bus signals for each member of its
137 D-Bus interface and property specified in the group definition for each group
142 interface specified in the group definition for each group member. When the
147 D-Bus interface specified in the group definition for each group member. When
153 each group member. When the signal occurs, the service owned state will be
[all …]
|
| /openbmc/phosphor-webui/app/common/components/table/ |
| H A D | table.js | 11 * It will render each item as a <tr> in the table.
12 * Each row object in the data array should also have a 'uiData'
14 * as each table cell <td>.
15 * Each row object in the data array can optionally have an
18 * Each row object can optionally have an 'expandContent' property
21 * Each row object can optionally have a 'selectable' property. Defaults
31 * table. Each object in the header array should have a 'label' property
50 * The 'expandable' attribute should be a boolean value. If true each
97 // property for each item in header array
115 // Check for undefined 'uiData' property for each item in data
[all …]
|
| /openbmc/u-boot/drivers/pinctrl/nxp/ |
| H A D | pinctrl-imx.h | 12 * @flags: flags specific for each soc
37 * Each pin represented in fsl,pins consists of 5 u32 PIN_FUNC_ID and
38 * 1 u32 CONFIG, so 24 types in total for each pin.
43 /* Each pin on imx8qm/qxp consists of 2 u32 PIN_FUNC_ID and 1 u32 CONFIG */
|
| /openbmc/openbmc-test-automation/lib/ |
| H A D | boot_utils.robot | 2 Documentation This module provides one wrapper keyword for each kind of boot
13 # stack_mode If stack_mode is set to "skip", each test
39 # stack_mode If stack_mode is set to "skip", each test
65 # stack_mode If stack_mode is set to "skip", each test
91 # stack_mode If stack_mode is set to "skip", each test
117 # stack_mode If stack_mode is set to "skip", each test
143 # stack_mode If stack_mode is set to "skip", each test
169 # stack_mode If stack_mode is set to "skip", each test
196 # stack_mode If stack_mode is set to "skip", each test
222 # stack_mode If stack_mode is set to "skip", each test
[all …]
|
| /openbmc/u-boot/arch/x86/include/asm/ |
| H A D | mp.h | 17 * along with the BSP to coordinate sequencing. Each flight record either
18 * provides a barrier for each AP before calling the callback or the APs
19 * are allowed to perform the callback without waiting. Regardless, each
20 * record has the cpus_entered field incremented for each record. When
70 * mp_params. Each flight record will be executed according to the plan. Note
|
| /openbmc/qemu/include/hw/ppc/ |
| H A D | spapr_ovec.h | 4 * Each architecture option is organized/documented by the following
11 * where each vector entry can be one or more bytes.
14 * structure, where each entry is stored in little-endian so that the
15 * byte ordering reflects that of the documentation, but where each bit
17 * a byte value where the MSB is the left-most bit. Thus, each
|