| /openbmc/linux/Documentation/driver-api/soundwire/ |
| H A D | locking.rst | 5 This document explains locking mechanism of the SoundWire Bus. Bus uses
6 following locks in order to avoid race conditions in Bus operations on
9 - Bus lock
13 Bus lock
16 SoundWire Bus lock is a mutex and is part of Bus data structure
17 (sdw_bus) which is used for every Bus instance. This lock is used to
18 serialize each of the following operations(s) within SoundWire Bus instance.
30 Bus data structure (sdw_bus). This lock is used to serialize the message
31 transfers (read/write) within a SoundWire Bus instance.
45 Bus in case of bank switch.
[all …]
|
| H A D | summary.rst | 26 interfaces share the common Bus containing data and clock line. Each of the
67 Bus:
68 Implements SoundWire Linux Bus which handles the SoundWire protocol.
70 Master. Multiple instances of Bus may be present in a system.
74 can register to a Bus instance.
78 directly by the Bus (and transmitted through the Master driver/interface).
86 SoundWire Bus supports programming interfaces for the SoundWire Master
90 Each of the SoundWire Master interfaces needs to be registered to the Bus.
91 Bus implements API to read standard Master MIPI properties and also provides
100 Following is the Bus API to register the SoundWire Bus:
[all …]
|
| H A D | stream.rst | 225 on Bus other than current stream. There can be multiple active streams
226 on the Bus.
228 SoundWire Bus manages stream operations for each stream getting
229 rendered/captured on the SoundWire Bus. This section explains Bus operations
230 done for each of the stream allocated/released on Bus. Following are the
231 stream states maintained by the Bus for each of the audio stream.
267 Below section explains the operations done by the Bus on Master(s) and
288 Bus implements below API for allocate a stream which needs to be called once
312 the port information to Bus which includes port numbers allocated by
318 Bus implements below APIs for CONFIG state which needs to be called by
[all …]
|
| /openbmc/linux/Documentation/scsi/ |
| H A D | advansys.rst | 8 RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow
10 buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit
21 - ABP-480 - Bus-Master CardBus (16 CDB)
24 - ABP510/5150 - Bus-Master ISA (240 CDB)
25 - ABP5140 - Bus-Master ISA PnP (16 CDB)
26 - ABP5142 - Bus-Master ISA PnP with floppy (16 CDB)
27 - ABP902/3902 - Bus-Master PCI (16 CDB)
28 - ABP3905 - Bus-Master PCI (16 CDB)
29 - ABP915 - Bus-Master PCI (16 CDB)
30 - ABP920 - Bus-Master PCI (16 CDB)
[all …]
|
| /openbmc/ipmitool/contrib/ |
| H A D | oem_ibm_sel_map | 13 "0xE0","0x00","0x00","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
14 "0xE0","0x00","0x01","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
15 "0xE0","0x00","0x02","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
16 "0xE0","0x00","0x03","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
17 "0xE0","0x00","0x04","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
18 "0xE0","0x00","0x05","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
19 "0xE0","0x00","0x06","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
20 "0xE0","0x00","0x07","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
21 "0xE0","0x00","0x08","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
22 "0xE0","0x00","0x09","Chassis Number","Slot Number","Bus Number","Device ID (MSB)","Device ID (LSB)…
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/MCTP/ |
| H A D | README.md | 3 MCTP D-Bus interfaces are implemented by the MCTP control process daemon alias
7 `xyz.openbmc_project.MCTP.Endpoint` D-Bus interface to discover MCTP endpoints.
12 the removal of the MCTP endpoints and removes the D-Bus objects corresponding to
13 those endpoints. MCTP bridges are not modelled in the D-Bus.
15 ## D-Bus object modelling
17 The root D-Bus object path for the mctpd is `/xyz/openbmc_project/mctp`. There
18 will be a D-Bus object for every endpoint that is discovered by the mctpd. The
19 lifetime of the D-Bus object is the lifetime of the connected MCTP device.
21 The D-Bus object path for MCTP endpoints are named
25 The D-Bus object implements the `xyz.openbmc_project.MCTP.Endpoint` interface.
[all …]
|
| /openbmc/phosphor-debug-collector/ |
| H A D | meson.options | 15 description: 'The D-Bus busname to own',
22 description: 'The dump manager D-Bus root',
29 description: 'The BMC dump manager D-Bus object path',
43 description: 'The BMC dump entry D-Bus object path',
136 description: 'The fault log dump manager D-Bus object path',
143 description: 'The fault log dump entry D-Bus object path',
154 description: 'The system dump manager D-Bus object path',
161 description: 'The system dump entry D-Bus object path',
170 description: 'The resource dump manager D-Bus object path',
177 description: 'The resource dump entry D-Bus object path',
|
| /openbmc/docs/architecture/ |
| H A D | LED-architecture.md | 8 ## D-Bus
41 All applicable Inventory D-Bus objects would have a forward association mapping
42 to LED Group D-Bus object, namely:
48 All applicable LED Group D-Bus objects would have an association mapping to
49 inventory D-Bus object, namely:
58 - Look for an association `identify_led_group` on the Inventory D-Bus object
59 - If found, read the `asserted` property from the D-Bus object that is pointed
65 - Look for an association `identify_led_group` on the Inventory D-Bus object
66 - If found, set the `asserted` property on the D-Bus object that is pointed to
72 used. All applicable Inventory D-Bus objects would have a forward association
[all …]
|
| /openbmc/docs/designs/ |
| H A D | redfish-pcie.md | 33 The proposed implementation will follow the standard D-Bus producer-consumer
35 from hardware. The consumer will retrieve and parse the D-Bus data to provide
38 The proposed D-Bus interface can be found here:
41 The proposed producer will be a new D-Bus daemon that will be responsible for
42 gathering and caching PCIe hardware data and maintaining the D-Bus interfaces
53 update its cache, and make the necessary changes to the D-Bus properties. This
58 PCIe resource data from the D-Bus properties and providing it to the user.
66 Possible performance impact on the hardware-scanning and D-Bus updates. The
69 D-Bus properties.
|
| H A D | boot-progress.md | 12 phosphor D-Bus properties, IPMI sensors, PLDM sensors, and Redfish properties to
18 [phosphor-state-manager][1] implements D-Bus properties which track the state of
28 phosphor-state-manager implements some other D-Bus properties that represent the
34 These two D-Bus properties are very IPMI-centric. They were defined based on two
75 it also does not preclude them. The `BootProgress` D-Bus property is associated
81 - Enhance the existing [BootProgress][3] D-Bus property to cover all supported
83 - Create a new `BootProgressLastUpdate` D-Bus property that will hold the date
88 `BootProgress` property on D-Bus
90 `BootProgressLastUpdate` property on D-Bus when it sees `BootProgress`
93 appropriate mappings to the `BootProgress` and `BootProgressLastUpdate D-Bus
[all …]
|
| H A D | redfish-spdm-attestation.md | 18 generic implementation for the SPDM D-Bus Daemon.
40 - New D-Bus interfaces for Redfish resources `ComponentIntegrity` and
43 - Design for SPDM Attestation D-Bus Daemon, demonstrating how to fetch the
44 attestation results over D-Bus.
48 ### Attestation related D-Bus Interfaces
51 D-Bus:
81 The proposed Phosphor D-Bus Interfaces is here:
84 ### TrustedComponent related D-Bus Interfaces
101 The proposed Phosphor D-Bus Interfaces for `TrustedComponent` is here:
104 ### SPDM Attestation D-Bus Daemon
[all …]
|
| H A D | telemetry.md | 28 relies on the [OpenBMC D-Bus sensors][2].
32 - [OpenBMC D-Bus sensors][2] support. This is also design limitation, since the
33 Telemetry service requires telemetry sources to be implemented as D-Bus
97 URIs for metric report creation. Those sensors are also used to get URI->D-Bus
100 D-Bus sensors and exposing them as D-Bus objects. Telemetry service supports
121 |User| |bmcweb| |Telemetry| | D-Bus |
134 | +--------------------> Invoke AddReport | Register for D-Bus | |
135 | | | method on D-Bus | sensors | |
143 | | code 201 with | Return created | |D-Bus object | |
144 | | Metric Report | Report D-Bus path <-+ | |
[all …]
|
| H A D | multi-host-postcode.md | 22 D-Bus objects).
24 Diagram Legend: |Label|Signifies| |-----|---------| |`I:` |D-Bus interface|
25 |`S:` |D-Bus service name (well-known bus name)| |`R:` |Repository name| |`U:`
152 writes value to appropriate D-Bus object hosted by phosphor-host-postd.
155 - phosphor-post-code-manager receives new POST codes via D-Bus signal and stores
167 - Sets `Value` property on appropriate D-Bus `Raw` object hosted by
178 - Display the latest postcode of the selected host read through D-Bus on a
181 **D-Bus interface**
183 The following D-Bus names need to be created for the multi-host post-code.
197 - Create D-Bus service names for single-host and multi-host system accordingly.
[all …]
|
| /openbmc/qemu/docs/interop/ |
| H A D | dbus-vmstate.rst | 2 D-Bus VMState
6 on a QEMU D-Bus bus. (refer to the :doc:`dbus` document for
7 some recommendations on D-Bus usage)
10 ``org.qemu.VMState1`` D-Bus name owners and query their ``Id``. It
18 1Mb. The state must be saved quickly (a fraction of a second). (D-Bus
33 Sphinx 4 is required to build D-Bus documentation.
|
| H A D | dbus-display.rst | 1 D-Bus display
4 QEMU can export the VM display through D-Bus (when started with ``-display
8 Various specialized D-Bus interfaces are available on different object paths
26 Sphinx 4 is required to build D-Bus documentation.
|
| /openbmc/phosphor-fan-presence/docs/control/ |
| H A D | groups.md | 4 to a group of D-Bus objects that all of the same D-Bus path and interface, and
5 are acted upon by actions and triggers in events.json. Only the D-Bus objects
25 An array of the D-Bus object paths that are in the group. Required.
33 If known, the D-Bus service name that provides these D-bus objects. All members
|
| /openbmc/linux/Documentation/PCI/ |
| H A D | pciebus-howto.rst | 5 The PCI Express Port Bus Driver Guide HOWTO
14 This guide describes the basics of the PCI Express Port Bus driver
16 register/unregister with the PCI Express Port Bus Driver.
19 What is the PCI Express Port Bus Driver
40 Why use the PCI Express Port Bus Driver?
57 having a PCI Express Port Bus driver, which manages all populated
60 advantages of using the PCI Express Port Bus driver are listed below:
74 Configuring the PCI Express Port Bus Driver vs. Service Drivers
77 Including the PCI Express Port Bus Driver Support into the Kernel
80 Including the PCI Express Port Bus driver depends on whether the PCI
[all …]
|
| /openbmc/phosphor-certificate-manager/ |
| H A D | README.md | 55 ## D-Bus Interface
57 `phosphor-certificate-manager` is an implementation of the D-Bus interface
61 D-Bus service name is constructed by
62 "xyz.openbmc_project.Certs.Manager.{Type}.{Endpoint}" and D-Bus object path is
72 D-Bus service name is "xyz.openbmc_project.Certs.Manager.Server.Https" and D-Bus
80 `phosphor-certificate-manager` via D-Bus.
|
| /openbmc/phosphor-power/phosphor-regulators/docs/config_file/ |
| H A D | pmbus_read_sensor.md | 53 ### D-Bus Sensor
56 [D-Bus sensor object](https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.…
60 D-Bus sensors have an object path with the following format:
66 The D-Bus sensors `<namespace>` is the general category of the sensor. The
67 following table shows how the sensor type is mapped to a D-Bus sensors
70 | Sensor Type | D-Bus `<namespace>` |
82 The D-Bus `<sensor_name>` must be unique across the entire system. It will be
90 the resulting D-Bus `<sensor_name>` will be "vdd0_vout_peak".
96 information, the D-Bus sensor will contain the highest peak/lowest valley value
98 off, the D-Bus peak/valley sensor values are cleared.
|
| /openbmc/phosphor-power/phosphor-regulators/docs/ |
| H A D | design.md | 27 - Implements the D-Bus `configure` and `monitor` methods.
56 D-Bus `configure` method on the `phosphor-regulators` application.
58 This D-Bus method is implemented by the Manager object. The Manager object calls
82 D-Bus `monitor` method on the `phosphor-regulators` application. The parameter
85 This D-Bus method is implemented by the Manager object. The Manager object
95 D-Bus `monitor` method on the `phosphor-regulators` application. The parameter
98 This D-Bus method is implemented by the Manager object. The Manager object stops
111 on D-Bus. On subsequent reads, the existing D-Bus sensor object is updated with
114 The D-Bus sensor object implements the following interfaces:
121 An existing D-Bus Sensor object is removed from D-Bus if no corresponding sensor
[all …]
|
| /openbmc/phosphor-host-ipmid/docs/ |
| H A D | configuration.md | 25 ## IPMI D-Bus Sensor Filtering
30 D-Bus. The D-Bus method is the default mode used by Redfish. Redfish does not
35 specification. Enabling IPMI to use D-Bus may cause the number of sensors
41 sensors via D-Bus. When dynamic sensors are active all of the sensors placed on
42 D-Bus by a service are added to the IPMI sensor list. In the event that too many
43 sensors are exposed on D-Bus, the list can be filtered by adding a list of
|
| /openbmc/google-misc/subprojects/acpi-power-state-daemon/ |
| H A D | acpi_power_state.cpp | 54 sdbusplus::bus_t& Bus; member
57 ACPIPowerStateInherit(bus, path), Bus(bus) in ACPIPowerState()
70 startSystemdUnit(Bus, hostS5Unit); in sysACPIStatus()
74 startSystemdUnit(Bus, hostS0Unit); in sysACPIStatus()
|
| /openbmc/linux/Documentation/devicetree/bindings/clock/ |
| H A D | mvebu-core-clock.txt | 8 0 = tclk (Internal Bus clock)
15 0 = tclk (Internal Bus clock)
21 0 = tclk (Internal Bus clock)
27 0 = tclk (Internal Bus clock)
35 0 = tclk (Internal Bus clock)
41 0 = tclk (Internal Bus clock)
47 0 = tclk (Internal Bus clock)
|
| /openbmc/hiomapd/Documentation/ |
| H A D | mboxd.md | 25 dbus.c - Contains the handlers for the D-Bus commands which the daemon can
68 D-Bus
70 D-Bus
71 ACTIVE_MAPS_MEM -> SUSPEND_MAPS_MEM - Suspend command received over D-Bus
72 SUSPEND_MAPS_MEM -> ACTIVE_MAPS_MEM - Resume command received over D-Bus
75 ACTIVE_MAPS_MEM -> ACTIVE_MAPS_FLASH - Reset D-Bus or mbox command received
137 the mbox, D-Bus or signal file descriptors.
148 #### Handling D-Bus Commands
150 When an event occurs on the D-Bus file descriptor the D-Bus request is read from
151 the D-Bus interface and processed.
[all …]
|
| /openbmc/phosphor-mboxd/Documentation/ |
| H A D | mboxd.md | 26 mboxd_dbus.c - Contains the handlers for the D-Bus commands which the daemon can
69 D-Bus
71 D-Bus
72 ACTIVE_MAPS_MEM -> SUSPEND_MAPS_MEM - Suspend command received over D-Bus
73 SUSPEND_MAPS_MEM -> ACTIVE_MAPS_MEM - Resume command received over D-Bus
76 ACTIVE_MAPS_MEM -> ACTIVE_MAPS_FLASH - Reset D-Bus or mbox command received
138 the mbox, D-Bus or signal file descriptors.
149 #### Handling D-Bus Commands
151 When an event occurs on the D-Bus file descriptor the D-Bus request is read from
152 the D-Bus interface and processed.
[all …]
|