diff options
author | Dustin Byford <dustin@cumulusnetworks.com> | 2015-10-23 21:27:07 +0200 |
---|---|---|
committer | Wolfram Sang <wsa@the-dreams.de> | 2015-10-25 15:49:46 +0100 |
commit | 8eb5c87a92c065aaca39ac3e841b07906a4959a2 (patch) | |
tree | 326cf581c599660996c4ddb59a5ffc6898ad0ebd /Documentation/acpi/i2c-muxes.txt | |
parent | acpi: add acpi_preset_companion() stub (diff) | |
download | linux-8eb5c87a92c065aaca39ac3e841b07906a4959a2.tar.xz linux-8eb5c87a92c065aaca39ac3e841b07906a4959a2.zip |
i2c: add ACPI support for I2C mux ports
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs a little extra work.
This change implements a method for describing an I2C device hierarchy that
includes mux devices by using an ACPI Device() for each mux channel along
with an _ADR to set the channel number for the device. See
Documentation/acpi/i2c-muxes.txt for a simple example.
To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF. This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Diffstat (limited to 'Documentation/acpi/i2c-muxes.txt')
-rw-r--r-- | Documentation/acpi/i2c-muxes.txt | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt new file mode 100644 index 000000000000..9fcc4f0b885e --- /dev/null +++ b/Documentation/acpi/i2c-muxes.txt @@ -0,0 +1,58 @@ +ACPI I2C Muxes +-------------- + +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI +Device () scope per mux channel. + +Consider this topology: + ++------+ +------+ +| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) +| | | 0x70 |--CH01--> i2c client B (0x50) ++------+ +------+ + +which corresponds to the following ASL: + +Device (SMB1) +{ + Name (_HID, ...) + Device (MUX0) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^SMB1", 0x00, + ResourceConsumer,,) + } + + Device (CH00) + { + Name (_ADR, 0) + + Device (CLIA) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH00", 0x00, + ResourceConsumer,,) + } + } + } + + Device (CH01) + { + Name (_ADR, 1) + + Device (CLIB) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH01", 0x00, + ResourceConsumer,,) + } + } + } + } +} |