Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp236317imd; Fri, 26 Oct 2018 07:49:24 -0700 (PDT) X-Google-Smtp-Source: AJdET5dklta4jY2ye3e3PyqJdkrAqd3+CL0K46FC2Iz+3Dh8c6fsTKJ4omDx6naZpA+heU0OW8EJ X-Received: by 2002:a17:902:708a:: with SMTP id z10-v6mr3916632plk.330.1540565364178; Fri, 26 Oct 2018 07:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540565364; cv=none; d=google.com; s=arc-20160816; b=isylNMe88O6SIWyfGMgjmSyGL640l2pcHcadqzc4lsUtlkEkbYuNYCn+NYaRjDSnQH z87yvvhw93X/bdgkC2VZgS+LJ0Rwg9l6HZVcdjdfB2vTm5Y1sODQMK5zDmwK2yulILoq PQbHaqhNUOJVY9NN4jxOgrKWpw3+o8GRRedNBCZb6ldjUo/ro6VIYTBsXqATRs/7fizt SLfD4U4Po/Sh46kGEM1hytqa8LPTW73yZbSKY45WYPmdlH0qy/PkI8INtcQ4lGsyEHId WConIO1KkETU8wL8XWvSeooG39idVxp/BPvCKr3MXPf5qCnLbyFY9zHeZCjNx/Fsnwm9 w4rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=PHI4p8W2jtbijjSY1FLtHEvuAVQumHjKX2ekAeQKdC0=; b=QIugcaVKBvcXNf68zHNpAWIhu4zT+9iT1tHxIWNfXrj2RJRyDpTJbLagA7YT16IMC4 WaOZUFEHBozDzGKDDaako+AfnqRi9/0dwOktIfFyzIoRuc9rT6Gkx8ZQskbXnqaGBHkl BoCX6OFoPNVexBxzvNWDksikTLCFp3XNro9FSAMN3sb9TydFaUtbm3Imia9iSWgAJ8Ku ivwyQl8eN7YO132nv6utUxeFWr342TzsrKHPwhVTrpiWMVxFrL701DUC8CJ/Lm2180as +VYYCbWoo5juUY/x6NPxuZNQqgcmR1I6+McJah2k7gX1f06XMfPpLPtxywh9g446GNFM xhHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v14-v6si6022585pgi.5.2018.10.26.07.49.08; Fri, 26 Oct 2018 07:49:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727600AbeJZXVC (ORCPT + 99 others); Fri, 26 Oct 2018 19:21:02 -0400 Received: from mail.bootlin.com ([62.4.15.54]:46237 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726458AbeJZXVA (ORCPT ); Fri, 26 Oct 2018 19:21:00 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id A97B12099B; Fri, 26 Oct 2018 16:43:38 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost.localdomain (aaubervilliers-681-1-12-210.w90-88.abo.wanadoo.fr [90.88.133.210]) by mail.bootlin.com (Postfix) with ESMTPSA id DF01720794; Fri, 26 Oct 2018 16:43:37 +0200 (CEST) From: Boris Brezillon To: Wolfram Sang , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Greg Kroah-Hartman , Arnd Bergmann Cc: Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Cyprian Wronka , Suresh Punnoose , Rafal Ciepiela , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Vitor Soares , Geert Uytterhoeven , Linus Walleij , Xiang Lin , linux-gpio@vger.kernel.org, Sekhar Nori , Przemyslaw Gaj , Peter Rosin , Mike Shettel , Stephen Boyd , Boris Brezillon , Rob Herring Subject: [PATCH v10 4/9] dt-bindings: i3c: Document core bindings Date: Fri, 26 Oct 2018 16:43:28 +0200 Message-Id: <20181026144333.12276-5-boris.brezillon@bootlin.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181026144333.12276-1-boris.brezillon@bootlin.com> References: <20181026144333.12276-1-boris.brezillon@bootlin.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A new I3C subsystem has been added and a generic description has been created to represent the I3C bus and the devices connected on it. Document this generic representation. Cc: Rob Herring Signed-off-by: Boris Brezillon --- Changes in v10: - Fix mistakes in the example (reported by Rob) Changes in v9: - Rework the way we encode the I2C vs I3C device in the reg property so that we don't need the funky macros to define and I3C or I2C dev - Drop Rob's Reviewed-by Changes in v8: - None Changes in v7: - None Changes in v6: - None Changes in v5: - Add Rob's R-b Changes in v4: - Clarify the fact that static address == I3C address and dynamic address == I3C address - Use i2c-scl-hz in the example Changes in v3: - Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz - Rework the way we expose the provisional ID and LVR information - Rename dynamic-address into assigned-address - Enforce the I3C master node name Changes in v2: - Define how to describe I3C devices in the DT and when it should be used. Note that the parsing of I3C devices is not yet implemented in the framework. Will be added when someone really needs it. --- Documentation/devicetree/bindings/i3c/i3c.txt | 139 ++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt new file mode 100644 index 000000000000..9774b48ef439 --- /dev/null +++ b/Documentation/devicetree/bindings/i3c/i3c.txt @@ -0,0 +1,139 @@ +Generic device tree bindings for I3C busses +=========================================== + +This document describes generic bindings that should be used to describe I3C +busses in a device tree. + +Required properties +------------------- + +- #address-cells - should be <3>. Read more about addresses below. +- #size-cells - should be <0>. +- compatible - name of the I3C master controller driving the I3C bus + +For other required properties e.g. to describe register sets, +clocks, etc. check the binding documentation of the specific driver. +The node describing an I3C bus should be named i3c-master. + +Optional properties +------------------- + +These properties may not be supported by all I3C master drivers. Each I3C +master bindings should specify which of them are supported. + +- i3c-scl-hz: frequency of the SCL signal used for I3C transfers. + When undefined the core sets it to 12.5MHz. + +- i2c-scl-hz: frequency of the SCL signal used for I2C transfers. + When undefined, the core looks at LVR (Legacy Virtual Register) + values of I2C devices described in the device tree to determine + the maximum I2C frequency. + +I2C devices +=========== + +Each I2C device connected to the bus should be described in a subnode. All +properties described in Documentation/devicetree/bindings/i2c/i2c.txt are +valid here, but several new properties have been added. + +New constraint on existing properties: +-------------------------------------- +- reg: contains 3 cells + + first cell : still encoding the I2C address + + + second cell: shall be 0 + + + third cell: shall encode the I3C LVR (Legacy Virtual Register) + bit[31:8]: unused/ignored + bit[7:5]: I2C device index. Possible values + * 0: I2C device has a 50 ns spike filter + * 1: I2C device does not have a 50 ns spike filter but supports high + frequency on SCL + * 2: I2C device does not have a 50 ns spike filter and is not tolerant + to high frequencies + * 3-7: reserved + + bit[4]: tell whether the device operates in FM (Fast Mode) or FM+ mode + * 0: FM+ mode + * 1: FM mode + + bit[3:0]: device type + * 0-15: reserved + +The I2C node unit-address should always match the first cell of the reg +property: @. + +I3C devices +=========== + +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and +are thus discoverable. So, by default, I3C devices do not have to be described +in the device tree. +This being said, one might want to attach extra resources to these devices, +and those resources may have to be described in the device tree, which in turn +means we have to describe I3C devices. + +Another use case for describing an I3C device in the device tree is when this +I3C device has a static I2C address and we want to assign it a specific I3C +dynamic address before the DAA takes place (so that other devices on the bus +can't take this dynamic address). + +The I3C device should be names @,, +where device-type is describing the type of device connected on the bus +(gpio-controller, sensor, ...). + +Required properties +------------------- +- reg: contains 3 cells + + first cell : encodes the static I2C address. Should be 0 if the device does + not have one (0 is not a valid I2C address). + + + second and third cells: should encode the ProvisionalID. The second cell + contains the manufacturer ID left-shifted by 1. + The third cell contains ORing of the part ID + left-shifted by 16, the instance ID left-shifted + by 12 and the extra information. This encoding is + following the PID definition provided by the I3C + specification. + +Optional properties +------------------- +- assigned-address: dynamic address to be assigned to this device. This + property is only valid if the I3C device has a static + address (first cell of the reg property != 0). + + +Example: + + i3c-master@d040000 { + compatible = "cdns,i3c-master"; + clocks = <&coreclock>, <&i3csysclock>; + clock-names = "pclk", "sysclk"; + interrupts = <3 0>; + reg = <0x0d040000 0x1000>; + #address-cells = <3>; + #size-cells = <0>; + i2c-scl-hz = <100000>; + + /* I2C device. */ + nunchuk: nunchuk@52 { + compatible = "nintendo,nunchuk"; + reg = <0x52 0x0 0x10>; + }; + + /* I3C device with a static I2C address. */ + thermal_sensor: sensor@68,39200144004 { + reg = <0x68 0x392 0x144004>; + assigned-address = <0xa>; + }; + + /* + * I3C device without a static I2C address but requiring + * resources described in the DT. + */ + sensor@0,39200154004 { + reg = <0x0 0x392 0x154004>; + clocks = <&clock_provider 0>; + }; + }; + -- 2.17.1