From patchwork Mon Feb 12 05:15:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Stanley X-Patchwork-Id: 871895 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="t8oX1eG8"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zfv8l6qSNz9t3G for ; Mon, 12 Feb 2018 16:18:47 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932480AbeBLFRB (ORCPT ); Mon, 12 Feb 2018 00:17:01 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:39735 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932467AbeBLFQ4 (ORCPT ); Mon, 12 Feb 2018 00:16:56 -0500 Received: by mail-pg0-f66.google.com with SMTP id w17so6817733pgv.6; Sun, 11 Feb 2018 21:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=rNzHqYsvJJiXVpH19xWBuCpdAEWoaA62sThTAClHcLk=; b=t8oX1eG82SL8dNu8ePVbTuXvHxHAZBDlPuXY72vvPDd1hmCqMBzRHWI8EYU9CUlm1g Qu4LU8ve/cE3w0YL/oPVqgQUuKJE92tXIQv1tWPxL2eD0xyhup9vGh09gbcuuBpy3sWW if7SdrtpcqbGVUtkqdrW6/FMPBiLA2IjSVE5/4NJefsYnRgJYrcI2S3hPwDTA3JL16b3 csZdzg5HrJDx2W6zZGYkZzJ2dxBvqQrVSEyMtGpPKFDOtMi9Jua2WLWK9Iyuhf9qpEpL JBmI4/XsysvEUVYMy9tHan36jpV384Y97W4w70O/jhZP4gzmB9YbCVRqcLqdK01L7uc+ L/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=rNzHqYsvJJiXVpH19xWBuCpdAEWoaA62sThTAClHcLk=; b=PChkOCc/wmLaZQ8yGCExYmk7ZYa5aXZ12VfqkQWf+YBrK9C3llHttvxklbsg399ScF MSae8GUrR/8mF0J5XlQFvAiOKzZtnGOfcMyuUThKSTzRS48IN5poAY+oGzDUduvZOlOL GDkQSD4Ar6HrNEz0qbl45fmLk6nD6Scjf2SE+/HhSihEp2ac2qZznmM5BvM/e18E/b3K +Kb4hWIX8CkbkWvZaYrJvScH8WQfFTC/g3FtJ7vXubv8vWpp415DY6fY/KVR2mk0RPwj M1B+sflZP3HV4QB68QgvJ1cxh2gK6uTHCiuQP4QYboknicmLIFPNFseKtKmBozbAC+v7 CvwQ== X-Gm-Message-State: APf1xPD5GsJl/xKTUU9jozJszHn+m5BX/yZf2dx/8oXl3kL2ET4BJKci w131UGcxkCPa+S2q7RBkpWo= X-Google-Smtp-Source: AH8x227Q3pzvM1GylU05VYDgsU/qKQz6rNYhF/imtcuvJ78NsGK+7f7oAKQL/p5Hl8ZM1+QUcWIiCA== X-Received: by 10.99.137.195 with SMTP id v186mr7816810pgd.90.1518412615535; Sun, 11 Feb 2018 21:16:55 -0800 (PST) Received: from aurora.jms.id.au ([203.0.153.9]) by smtp.gmail.com with ESMTPSA id u13sm23646448pfd.169.2018.02.11.21.16.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 11 Feb 2018 21:16:54 -0800 (PST) Received: by aurora.jms.id.au (sSMTP sendmail emulation); Mon, 12 Feb 2018 15:46:48 +1030 From: Joel Stanley To: Greg Kroah-Hartman , Rob Herring , Mark Rutland Cc: Jeremy Kerr , Christopher Bostic , Brad Bishop , Edward James , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: [PATCH 05/10] dt-bindings: fsi: Add specification for FSI busses Date: Mon, 12 Feb 2018 15:45:44 +1030 Message-Id: <20180212051549.8575-6-joel@jms.id.au> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180212051549.8575-1-joel@jms.id.au> References: <20180212051549.8575-1-joel@jms.id.au> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org From: Jeremy Kerr This change introduces a proposed layout for describing FSI busses in the device tree. While the bus is probe-able, we'd still like a method of describing subordinate (eg i2c) busses that are behind FSI devices. The FSI core will be responsible for matching probed slaves & engines to their device tree nodes, so the FSI device drivers' probe() functions will be passed a struct device with the appropriate of_node populated where a matching DT node is found. Signed-off-by: Jeremy Kerr Acked-by: Joel Stanley Acked-by: Brad Bishop Acked-by: Eddie James Acked-by: Rob Herring Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/fsi/fsi.txt | 144 ++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt new file mode 100644 index 000000000000..4eaf488d4015 --- /dev/null +++ b/Documentation/devicetree/bindings/fsi/fsi.txt @@ -0,0 +1,144 @@ +FSI bus & engine generic device tree bindings +============================================= + +The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and +engines within those slaves. However, we have a facility to match devicetree +nodes to probed engines. This allows for fsi engines to expose non-probeable +busses, which are then exposed by the device tree. For example, an FSI engine +that is an I2C master - the I2C bus can be described by the device tree under +the engine's device tree node. + +FSI masters may require their own DT nodes (to describe the master HW itself); +that requirement is defined by the master's implementation, and is described by +the fsi-master-* binding specifications. + +Under the masters' nodes, we can describe the bus topology using nodes to +represent the FSI slaves and their slave engines. As a basic outline: + + fsi-master { + /* top-level of FSI bus topology, bound to an FSI master driver and + * exposes an FSI bus */ + + fsi-slave@ { + /* this node defines the FSI slave device, and is handled + * entirely with FSI core code */ + + fsi-slave-engine@ { + /* this node defines the engine endpoint & address range, which + * is bound to the relevant fsi device driver */ + ... + }; + + fsi-slave-engine@ { + ... + }; + + }; + }; + +Note that since the bus is probe-able, some (or all) of the topology may +not be described; this binding only provides an optional facility for +adding subordinate device tree nodes as children of FSI engines. + +FSI masters +----------- + +FSI master nodes declare themselves as such with the "fsi-master" compatible +value. It's likely that an implementation-specific compatible value will +be needed as well, for example: + + compatible = "fsi-master-gpio", "fsi-master"; + +Since the master nodes describe the top-level of the FSI topology, they also +need to declare the FSI-standard addressing scheme. This requires two cells for +addresses (link index and slave ID), and no size: + + #address-cells = <2>; + #size-cells = <0>; + +FSI slaves +---------- + +Slaves are identified by a (link-index, slave-id) pair, so require two cells +for an address identifier. Since these are not a range, no size cells are +required. For an example, a slave on link 1, with ID 2, could be represented +as: + + cfam@1,2 { + reg = <1 2>; + [...]; + } + +Each slave provides an address-space, under which the engines are accessible. +That address space has a maximum of 23 bits, so we use one cell to represent +addresses and sizes in the slave address space: + + #address-cells = <1>; + #size-cells = <1>; + + +FSI engines (devices) +--------------------- + +Engines are identified by their address under the slaves' address spaces. We +use a single cell for address and size. Engine nodes represent the endpoint +FSI device, and are passed to those FSI device drivers' ->probe() functions. + +For example, for a slave using a single 0x400-byte page starting at address +0xc00: + + engine@c00 { + reg = <0xc00 0x400>; + }; + + +Full example +------------ + +Here's an example that illustrates: + - an FSI master + - connected to an FSI slave + - that contains an engine that is an I2C master + - connected to an I2C EEPROM + +The FSI master may be connected to additional slaves, and slaves may have +additional engines, but they don't necessarily need to be describe in the +device tree if no extra platform information is required. + + /* The GPIO-based FSI master node, describing the top level of the + * FSI bus + */ + gpio-fsi { + compatible = "fsi-master-gpio", "fsi-master"; + #address-cells = <2>; + #size-cells = <0>; + + /* A FSI slave (aka. CFAM) at link 0, ID 0. */ + cfam@0,0 { + reg = <0 0>; + #address-cells = <1>; + #size-cells = <1>; + + /* FSI engine at 0xc00, using a single page. In this example, + * it's an I2C master controller, so subnodes describe the + * I2C bus. + */ + i2c-controller@c00 { + reg = <0xc00 0x400>; + + /* Engine-specific data. In this case, we're describing an + * I2C bus, so we're conforming to the generic I2C binding + */ + compatible = "some-vendor,fsi-i2c-controller"; + #address-cells = <1>; + #size-cells = <1>; + + /* I2C endpoint device: an Atmel EEPROM */ + eeprom@50 { + compatible = "atmel,24c256"; + reg = <0x50>; + pagesize = <64>; + }; + }; + }; + }; From patchwork Mon Feb 12 05:15:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Stanley X-Patchwork-Id: 871894 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="OjspTIcS"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zfv7K44Twz9t3G for ; Mon, 12 Feb 2018 16:17:33 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932695AbeBLFRa (ORCPT ); Mon, 12 Feb 2018 00:17:30 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:37638 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932467AbeBLFR1 (ORCPT ); Mon, 12 Feb 2018 00:17:27 -0500 Received: by mail-pg0-f67.google.com with SMTP id o1so6821506pgn.4; Sun, 11 Feb 2018 21:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=R2fi9dEw2GrkHAYwMSiZ7445jXCPYwkaXsj7fqtAgbI=; b=OjspTIcSF6PJqnOJ2vacc4jqDK8SsP8Il4FyIi2GHvgdFHphXl9LsYC/+lQdu22tqV sU1ooeU/ishK6kX1BivDbT+TS2rjJrYEr1mOz7JTS9bCTdri8w7GzKrqQJPG5BtuoImK YXk3L0tHDmU+36T4XFmCGlsYPVEf1yzxQcF7Xx0OHuxGefx/2WDLuQOo27bNOm+ETQvY L4zHw8iGwGaaIHYfvYE4MvaaNFcTb2d9TW/Z5aX+akfX+NJMdu/pOB2KVAzErUCrcKBU eH6xJHCm6c7xetKRHscUMVhNv6FH6yFlmMpU5sTVH8Q1zb+JUaQH8FZRUzxEXffz+6Vv 8cIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=R2fi9dEw2GrkHAYwMSiZ7445jXCPYwkaXsj7fqtAgbI=; b=HXU3NHn5kyxAHu4no9f3S7k/VmVqIydPQ/3MjlRQB1KM6P/KO3wcnoQhXPFJDowOIX IZSsvj/FFIXE0ftzCxDwVJGd481bqd1eXPdTx7DUKSdjXB9fiQ1R7eyZCMvlQeR/Uicq UlZGWN3z/sYJyOE2VmB0vXnrL2w+UrNvrjRzSgVmyzd07lVdJTETdcUc3CC7W38vGxZu DzoXTxyTlUFuL6ziMKof0iNWSMB7toV5MJ7wV+w8BAnNbOgyxk6Qv0kN21MgkrsAeFMm Xqc1U7NA6XqQR+2e9IeTvLQIRHC31x5X3MIQ6E+1IdKyZAtJ2dB1UkezWIQQDbDbF179 EyrA== X-Gm-Message-State: APf1xPDwHbi9VZ7zw4LcoeOywRWao8mmZZqIBFIxalZYgiC52RyavlJh 7wR/QXhkw5NS3dGmwRxx6yA= X-Google-Smtp-Source: AH8x225JBYlCh3YSSbyNlVro6IZGGKSUCvcLBRpMLa5noWljc/AbSDizQlVusCXxWthhmjU0YJ6w5A== X-Received: by 10.101.92.138 with SMTP id a10mr8459575pgt.191.1518412647033; Sun, 11 Feb 2018 21:17:27 -0800 (PST) Received: from aurora.jms.id.au ([203.0.153.9]) by smtp.gmail.com with ESMTPSA id v1sm20735911pfg.33.2018.02.11.21.17.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 11 Feb 2018 21:17:26 -0800 (PST) Received: by aurora.jms.id.au (sSMTP sendmail emulation); Mon, 12 Feb 2018 15:47:19 +1030 From: Joel Stanley To: Greg Kroah-Hartman , Rob Herring , Mark Rutland Cc: Christopher Bostic , Jeremy Kerr , Brad Bishop , Edward James , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: [PATCH 09/10] dt-bindings: fsi: Add optional property no-scan-on-init Date: Mon, 12 Feb 2018 15:45:48 +1030 Message-Id: <20180212051549.8575-10-joel@jms.id.au> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20180212051549.8575-1-joel@jms.id.au> References: <20180212051549.8575-1-joel@jms.id.au> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org From: Christopher Bostic Add an optional FSI master property 'no-scan-on-init. This can be specified to indicate that a master should not be automatically scanned at init time. This is required in cases where a scan could interfere with another FSI master on the same bus. Signed-off-by: Christopher Bostic Acked-by: Jeremy Kerr Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/fsi/fsi.txt | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt index 4eaf488d4015..ab516c673a4b 100644 --- a/Documentation/devicetree/bindings/fsi/fsi.txt +++ b/Documentation/devicetree/bindings/fsi/fsi.txt @@ -56,6 +56,13 @@ addresses (link index and slave ID), and no size: #address-cells = <2>; #size-cells = <0>; +An optional boolean property can be added to indicate that a particular master +should not scan for connected devices at initialization time. This is +necessary in cases where a scan could cause arbitration issues with other +masters that may be present on the bus. + + no-scan-on-init; + FSI slaves ----------