From patchwork Sat Oct 10 00:41:47 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dustin Byford X-Patchwork-Id: 528473 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CD157140E49 for ; Sat, 10 Oct 2015 11:42:26 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b=SprHrszL; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750987AbbJJAmX (ORCPT ); Fri, 9 Oct 2015 20:42:23 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:33621 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751343AbbJJAmS (ORCPT ); Fri, 9 Oct 2015 20:42:18 -0400 Received: by pacex6 with SMTP id ex6so100641837pac.0 for ; Fri, 09 Oct 2015 17:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=wFNSXukjh+XHiY/x75d43CnUw7SNJUZqevvtIcaJM6Q=; b=SprHrszLk41YlhWbcjV6UpG9TlRYkwWSXVLMXtYzsLKLZS+bFyk9K+Rt3lGNXxpEU+ UCqU0Ka2iSjxzhk3Ts0jklFShszW+6ofRnwLGMCCEx376TqqQhrVjgSher09gt4FOHA8 EeFpem3qIJprxKVLxK3yPRndryN+MGRREHVRQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=wFNSXukjh+XHiY/x75d43CnUw7SNJUZqevvtIcaJM6Q=; b=mLMLqeJ4zG4Cb8+abvXDbXBrxialKhHZUWZhlHefXH7AOA10h8lIduQ44sYMQ1f08M /sc1ZJ/OEdFVWenX8lfqdrBqBJhowU7FF9v4O6fpXUKFUpRWDDvKO0zFtDBfns/Gf6SF wLWtzSMr+3jAsHwKiV/P/rVqoRkYDi16tOYmz1IyRT2g4TpOMuDZgx/4hRWO39sIvcz5 sZhwnsbAV2t6lBkoLffutu+9sqyMi4WHi8xDTO/dp5znoYfzTJhLzv9mJ5FsGcvC8QK7 k+x/aRg1/FqKVD988yNu+MBNL3r2bDGtRHytkeL9IK1AGe1/HRClDdekbnjurnMxRmtb Czvg== X-Gm-Message-State: ALoCoQkBwGX1CLuViOWAu8gbVUlLtOpGgib808cmLtqnJionx/KAESgZ5pqccBJVjIMdjEFYe0Ko X-Received: by 10.66.144.40 with SMTP id sj8mr18982491pab.72.1444437737410; Fri, 09 Oct 2015 17:42:17 -0700 (PDT) Received: from magnum.cumulusnetworks.com ([216.129.126.126]) by smtp.gmail.com with ESMTPSA id eg5sm4717402pac.30.2015.10.09.17.42.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2015 17:42:17 -0700 (PDT) Received: by magnum.cumulusnetworks.com (Postfix, from userid 1016) id 728268A1BC1; Fri, 9 Oct 2015 17:42:16 -0700 (PDT) From: Dustin Byford To: Wolfram Sang , Mika Westerberg Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net Subject: [PATCH 2/2] i2c: add ACPI support for I2C mux ports Date: Fri, 9 Oct 2015 17:41:47 -0700 Message-Id: <1444437707-19027-3-git-send-email-dustin@cumulusnetworks.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1444437707-19027-1-git-send-email-dustin@cumulusnetworks.com> References: <1439580693-5538-1-git-send-email-dustin@cumulusnetworks.com> <1444437707-19027-1-git-send-email-dustin@cumulusnetworks.com> Sender: linux-i2c-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match) enumerating I2C client devices connected through a I2C mux device requires 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. Signed-off-by: Dustin Byford --- Documentation/acpi/i2c-muxes.txt | 58 ++++++++++++++++++++++++++++++++++++++++ drivers/i2c/i2c-core.c | 18 +++++++++++-- drivers/i2c/i2c-mux.c | 8 ++++++ 3 files changed, 82 insertions(+), 2 deletions(-) create mode 100644 Documentation/acpi/i2c-muxes.txt diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt new file mode 100644 index 0000000..efdcf0d --- /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,,) + } + } + } + } +} diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 3a4c54e..a2de010 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -156,7 +156,10 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle, u32 level, info.fwnode = acpi_fwnode_handle(adev); memset(&lookup, 0, sizeof(lookup)); - lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent); + if (i2c_parent_is_i2c_adapter(adapter)) + lookup.adapter_handle = ACPI_HANDLE(&adapter->dev); + else + lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent); lookup.device_handle = handle; lookup.info = &info; @@ -210,9 +213,20 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle, u32 level, */ static void acpi_i2c_register_devices(struct i2c_adapter *adap) { + struct device *dev; acpi_status status; - if (!adap->dev.parent || !has_acpi_companion(adap->dev.parent)) + /* + * Typically we look at the ACPI device's parent for an ACPI companion. + * However, in the case of an I2C-connected I2C mux, the "virtual" I2C + * adapter allocated for the mux channel has that association. + */ + if (i2c_parent_is_i2c_adapter(adap)) + dev = &adap->dev; + else + dev = adap->dev.parent; + + if (!has_acpi_companion(dev)) return; status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c index 2ba7c0f..00fc5b1 100644 --- a/drivers/i2c/i2c-mux.c +++ b/drivers/i2c/i2c-mux.c @@ -25,6 +25,7 @@ #include #include #include +#include /* multiplexer per channel data */ struct i2c_mux_priv { @@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent, } } + /* + * Associate the mux channel with an ACPI node. + */ + if (has_acpi_companion(mux_dev)) + acpi_preset_companion(&priv->adap.dev, ACPI_COMPANION(mux_dev), + chan_id); + if (force_nr) { priv->adap.nr = force_nr; ret = i2c_add_numbered_adapter(&priv->adap);