From patchwork Wed Sep 21 08:41:09 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Phil Reid X-Patchwork-Id: 9343047 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 639B2607D4 for ; Wed, 21 Sep 2016 08:41:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5416C2A33E for ; Wed, 21 Sep 2016 08:41:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 48FFC2A342; Wed, 21 Sep 2016 08:41:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A46582A33E for ; Wed, 21 Sep 2016 08:41:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755249AbcIUIli (ORCPT ); Wed, 21 Sep 2016 04:41:38 -0400 Received: from 203-59-230-133.perm.iinet.net.au ([203.59.230.133]:37048 "EHLO preid-centos7.electromag.com.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753994AbcIUIl2 (ORCPT ); Wed, 21 Sep 2016 04:41:28 -0400 Received: by preid-centos7.electromag.com.au (Postfix, from userid 1000) id 9162D35E12231; Wed, 21 Sep 2016 16:41:18 +0800 (AWST) From: Phil Reid To: wsa@the-dreams.de, robh+dt@kernel.org, mark.rutland@arm.com, sre@kernel.org, andrea.merello@gmail.com, preid@electromag.com.au, karl-heinz@schneider-inet.de, arnd@arndb.de, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH v5 1/6] I2C: i2c-smbus: add device tree support Date: Wed, 21 Sep 2016 16:41:09 +0800 Message-Id: <1474447274-90821-2-git-send-email-preid@electromag.com.au> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1474447274-90821-1-git-send-email-preid@electromag.com.au> References: <1474447274-90821-1-git-send-email-preid@electromag.com.au> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Andrea Merello According to Documentation/i2c/smbus-protocol, a smbus controller driver that wants to hook-in smbus extensions support, can call i2c_setup_smbus_alert(). There are very few drivers that are currently doing this. However the i2c-smbus module can also work with any smbus-extensions-unaware I2C controller, as long as we provide an extra IRQ line connected to the I2C bus ALARM signal. This patch makes it possible to go this way via DT. Note that the DT node will indeed describe a (little) piece of HW, that is the routing of the ALARM signal to an IRQ line (so it seems a fair DT use to me, but RFC). Note that AFAICT, by design, i2c-smbus module pretends to be an I2C slave with address 0x0C (that is the alarm response address), and IMHO this is quite consistent with usage in the DT as a I2C child node. Signed-off-by: Andrea Merello Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/i2c/i2c-smbus.txt | 20 ++++++++++++++++++++ drivers/i2c/i2c-smbus.c | 20 +++++++++++++++----- 2 files changed, 35 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-smbus.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-smbus.txt b/Documentation/devicetree/bindings/i2c/i2c-smbus.txt new file mode 100644 index 0000000..da83127 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-smbus.txt @@ -0,0 +1,20 @@ +* i2c-smbus extensions + +Required Properties: + - compatible: Must contain "smbus_alert" + - interrupts: The irq line for smbus ALERT signal + - reg: I2C slave address. Set to 0x0C (alert response address). + +Note: The i2c-smbus module registers itself as a slave I2C device. Whenever +a smbus controller directly support smbus extensions (and its driver supports +this), there is no need to add anything special to the DT. Otherwise, for using +i2c-smbus with any smbus-extensions-unaware I2C controllers, you need to +route the smbus ALARM signal to an extra IRQ line, thus you need to describe +this in the DT. + +Example: + alert@0x0C { + reg = <0x0C>; + compatible = "smbus_alert"; + interrupts = <0 36 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c index b0d2679..5806db3 100644 --- a/drivers/i2c/i2c-smbus.c +++ b/drivers/i2c/i2c-smbus.c @@ -23,6 +23,7 @@ #include #include #include +#include struct i2c_smbus_alert { unsigned int alert_edge_triggered:1; @@ -139,20 +140,29 @@ static int smbalert_probe(struct i2c_client *ara, struct i2c_smbus_alert_setup *setup = dev_get_platdata(&ara->dev); struct i2c_smbus_alert *alert; struct i2c_adapter *adapter = ara->adapter; + struct device_node *of_node = ara->dev.of_node; int res; + int irq_type; alert = devm_kzalloc(&ara->dev, sizeof(struct i2c_smbus_alert), GFP_KERNEL); if (!alert) return -ENOMEM; - alert->alert_edge_triggered = setup->alert_edge_triggered; - alert->irq = setup->irq; + if (setup) { + alert->alert_edge_triggered = setup->alert_edge_triggered; + alert->irq = setup->irq; + } else if (of_node) { + alert->irq = irq_of_parse_and_map(of_node, 0); + irq_type = irq_get_trigger_type(alert->irq); + alert->alert_edge_triggered = (irq_type & IRQ_TYPE_EDGE_BOTH); + } + INIT_WORK(&alert->alert, smbus_alert); alert->ara = ara; - if (setup->irq > 0) { - res = devm_request_irq(&ara->dev, setup->irq, smbalert_irq, + if (alert->irq > 0) { + res = devm_request_irq(&ara->dev, alert->irq, smbalert_irq, 0, "smbus_alert", alert); if (res) return res; @@ -160,7 +170,7 @@ static int smbalert_probe(struct i2c_client *ara, i2c_set_clientdata(ara, alert); dev_info(&adapter->dev, "supports SMBALERT#, %s trigger\n", - setup->alert_edge_triggered ? "edge" : "level"); + alert->alert_edge_triggered ? "edge" : "level"); return 0; }