From patchwork Wed Apr 15 15:48:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 11491513 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id AB20081 for ; Wed, 15 Apr 2020 15:50:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8D3E2208FE for ; Wed, 15 Apr 2020 15:50:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="gmIc3L29" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409979AbgDOPuT (ORCPT ); Wed, 15 Apr 2020 11:50:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2394208AbgDOPtt (ORCPT ); Wed, 15 Apr 2020 11:49:49 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 072D4C061A10 for ; Wed, 15 Apr 2020 08:49:49 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id nu11so25502pjb.1 for ; Wed, 15 Apr 2020 08:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=NipZ0gHcLA0OIIWqIKZlc3VMj5MYxGX/fpRV8K+RKfE=; b=gmIc3L29Nm/J1LTHQ5Ew8IiD+7cuzBNHr4sZJnZXva/kpFcagn8+xZgcEC1I7OpZ+p c2Kio/4sny0PAE3dh8HV5+U0My5BSVRl+UG3I0IqdmlIAUPgnQRHorrVcmAVx9lJGiXw +KVaNbkSkidOjvQewho+ZIkfI+w/NyXIJD5jw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=NipZ0gHcLA0OIIWqIKZlc3VMj5MYxGX/fpRV8K+RKfE=; b=syqF78F4UzHwc1WbzuYDYx3FPv0tAICmbtXLQeDPzx9Em59UWLBcFp9rlilHSGfk4P 4BrsB77gYRC6G7264GFl0W9ytKKmA2wTdHRn1SXY8pxoetATBfjy4Qfvc4XIz9pfEt0D mdhJ6cJWhQAP1CT92SlWGj8+xcB9vEzS873//vNLr97ciprfFAidBzrRIIfVL1PWwBQQ cZz8kcS1ZtKl/Ul0/lPovBzpW35kwQJ8AhGjDJ+9LwWOo94CT1GXlzRbZGB9UdNO5dXL Qwltqj5VXljpr5uK2LhvO90TLSsZM8ZVfSBvY/4E0XFbwBj+jJsBo0o+XjKtEfh5GO5O /+eQ== X-Gm-Message-State: AGi0PubQXd010Ay8nqoN0bjdfBOkXJz3BFqKgsVI12LTa5axv3WrIluv XXDImJoFwN/J/I2QssuY1s9sLQ== X-Google-Smtp-Source: APiQypKpWOoytMwFddtGig+tyQ1cQ/+/BzyjeqjuD+Yn676+RLoOm8Ss5kMQWXOS5y+mMg71oTdPxA== X-Received: by 2002:a17:90a:a591:: with SMTP id b17mr7102737pjq.90.1586965788260; Wed, 15 Apr 2020 08:49:48 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id x27sm14382473pfj.74.2020.04.15.08.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 08:49:47 -0700 (PDT) From: Douglas Anderson To: airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org, narmstrong@baylibre.com, a.hajda@samsung.com, Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org Cc: jonas@kwiboo.se, bjorn.andersson@linaro.org, devicetree@vger.kernel.org, jeffrey.l.hugo@gmail.com, swboyd@chromium.org, jernej.skrabec@siol.net, linux-arm-msm@vger.kernel.org, robdclark@chromium.org, dri-devel@lists.freedesktop.org, Douglas Anderson , Krzysztof Kozlowski , Paul Walmsley , Stephen Boyd , linux-kernel@vger.kernel.org Subject: [PATCH 1/3] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml Date: Wed, 15 Apr 2020 08:48:39 -0700 Message-Id: <20200415084758.1.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid> X-Mailer: git-send-email 2.26.0.110.g2183baf09c-goog MIME-Version: 1.0 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org This moves the bindings over, based a lot on toshiba,tc358768.yaml. Unless there's someone known to be better, I've set the maintainer in the yaml as the first person to submit bindings. Signed-off-by: Douglas Anderson --- .../bindings/display/bridge/ti,sn65dsi86.txt | 87 -------- .../bindings/display/bridge/ti,sn65dsi86.yaml | 188 ++++++++++++++++++ 2 files changed, 188 insertions(+), 87 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt deleted file mode 100644 index 8ec4a7f2623a..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt +++ /dev/null @@ -1,87 +0,0 @@ -SN65DSI86 DSI to eDP bridge chip --------------------------------- - -This is the binding for Texas Instruments SN65DSI86 bridge. -http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf - -Required properties: -- compatible: Must be "ti,sn65dsi86" -- reg: i2c address of the chip, 0x2d as per datasheet -- enable-gpios: gpio specification for bridge_en pin (active high) - -- vccio-supply: A 1.8V supply that powers up the digital IOs. -- vpll-supply: A 1.8V supply that powers up the displayport PLL. -- vcca-supply: A 1.2V supply that powers up the analog circuits. -- vcc-supply: A 1.2V supply that powers up the digital core. - -Optional properties: -- interrupts-extended: Specifier for the SN65DSI86 interrupt line. - -- gpio-controller: Marks the device has a GPIO controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. - See ../../gpio/gpio.txt for more information. -- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of - the cell formats. - -- clock-names: should be "refclk" -- clocks: Specification for input reference clock. The reference - clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. - -- data-lanes: See ../../media/video-interface.txt -- lane-polarities: See ../../media/video-interface.txt - -- suspend-gpios: specification for GPIO1 pin on bridge (active low) - -Required nodes: -This device has two video ports. Their connections are modelled using the -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for DSI input -- Video port 1 for eDP output - -Example -------- - -edp-bridge@2d { - compatible = "ti,sn65dsi86"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x2d>; - - enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>; - suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>; - - interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>; - - vccio-supply = <&pm8916_l17>; - vcca-supply = <&pm8916_l6>; - vpll-supply = <&pm8916_l17>; - vcc-supply = <&pm8916_l6>; - - clock-names = "refclk"; - clocks = <&input_refclk>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - edp_bridge_in: endpoint { - remote-endpoint = <&dsi_out>; - }; - }; - - port@1 { - reg = <1>; - - edp_bridge_out: endpoint { - data-lanes = <2 1 3 0>; - lane-polarities = <0 1 0 1>; - remote-endpoint = <&edp_panel_in>; - }; - }; - }; -} diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml new file mode 100644 index 000000000000..8cacc6db33a9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI86 DSI to eDP bridge chip + +maintainers: + - Sandeep Panda + +description: | + The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP. + http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf + +properties: + compatible: + const: ti,sn65dsi86 + + reg: + const: 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specification for bridge_en pin (active high). + + vccio-supply: + description: A 1.8V supply that powers up the digital IOs. + + vpll-supply: + description: A 1.8V supply that powers up the DisplayPort PLL. + + vcca-supply: + description: A 1.2V supply that powers up the analog circuits. + + vcc-supply: + description: A 1.2V supply that powers up the digital core. + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + Specification for input reference clock. The reference clock rate must + be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. + + clock-names: + const: refclk + + gpio-controller: true + '#gpio-cells': + const: 2 + description: + First cell is pin number, second cell is flags. GPIO pin numbers are + 1-based to match the datasheet. See ../../gpio/gpio.txt for more + information. + + '#pwm-cells': + const: 1 + description: See ../../pwm/pwm.yaml for description of the cell formats. + + data-lanes: + description: See ../../media/video-interface.txt + + lane-polarities: + description: See ../../media/video-interface.txt + + ports: + type: object + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + additionalProperties: false + + description: + Video port for MIPI DSI input + + properties: + reg: + const: 0 + + patternProperties: + endpoint: + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + required: + - reg + + port@1: + type: object + additionalProperties: false + + description: + Video port for eDP output (panel or connector). + + properties: + reg: + const: 1 + + patternProperties: + endpoint: + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + required: + - reg + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - vccio-supply + - vpll-supply + - vcca-supply + - vcc-supply + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + + i2c1 { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + }; + }; + From patchwork Wed Apr 15 15:48:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 11491511 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 867FD92C for ; Wed, 15 Apr 2020 15:50:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B32E2078B for ; Wed, 15 Apr 2020 15:50:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ocsih6TZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728818AbgDOPuQ (ORCPT ); Wed, 15 Apr 2020 11:50:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2394211AbgDOPtu (ORCPT ); Wed, 15 Apr 2020 11:49:50 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C051C0610D6 for ; Wed, 15 Apr 2020 08:49:50 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id b8so137098pfp.8 for ; Wed, 15 Apr 2020 08:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Xv5Jh31H5+w8jdcU3qZ2inNmrbUd8kK+/sKgr7aMmBA=; b=ocsih6TZchbbdMilfJ2eaHo8YrE4iyg4spUMxkGBGstj8CDKhojbdYG+R6JnRMOHpi cibm2DqYQindZF69po+bUjLtkYkIIFvjCe50kEUJUbPMiABottJBLLZhsFmJEMAKF8bX iYWvV+b13tAnkuxypq1P36v0kRWJuAPIlucVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Xv5Jh31H5+w8jdcU3qZ2inNmrbUd8kK+/sKgr7aMmBA=; b=MeTNzjaPf0uxZhPX46YJvXTyNEthQq4llWGAJ9MZrpnHnT6tiM/uEaJiwy0Y2zx6Zr zwq6/PHgnKu5nzO1PDXGjpHAOkNpEOBgdgHD8MgZXUJR73IkOR0SZWiIlMke19ATSxi6 tjIV+cTPC44O5GJFi+Ts97FdplHWT70q1rjLiQ3OWMFxW8jhQCcoOees7R71xUqXCstj 9GvFNPmwO/12Ws+MlZZteuHvOYcpzvrv80WKoliTpHeHZ4kXtIE6pzpK7ZqYxJqEt+Hk VdjWGEJRJciWmPcjEMar5hPtSngKsTpHVQGE6TZaGFkCKpku7Pp2371dKj9VOZQ49n3V hdtw== X-Gm-Message-State: AGi0PuYV5yE8XMYutmGUOhTx9KN4EkeZr2ap7VCVZqdx0k6xPU3/a/Wb GR2PIltXn3ThP5ngMOJYUVun5w== X-Google-Smtp-Source: APiQypJ7H4gzqxg/2G4EhbDrGrS2BP4/dIipLbFjqpBVazKk05eyediy+KegDkVKm7ncrS7AMSqZ6Q== X-Received: by 2002:a62:e50f:: with SMTP id n15mr5859148pff.22.1586965789612; Wed, 15 Apr 2020 08:49:49 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id x27sm14382473pfj.74.2020.04.15.08.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 08:49:49 -0700 (PDT) From: Douglas Anderson To: airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org, narmstrong@baylibre.com, a.hajda@samsung.com, Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org Cc: jonas@kwiboo.se, bjorn.andersson@linaro.org, devicetree@vger.kernel.org, jeffrey.l.hugo@gmail.com, swboyd@chromium.org, jernej.skrabec@siol.net, linux-arm-msm@vger.kernel.org, robdclark@chromium.org, dri-devel@lists.freedesktop.org, Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Add hpd-gpios to the bindings Date: Wed, 15 Apr 2020 08:48:40 -0700 Message-Id: <20200415084758.2.Ic98f6622c60a1aa547ed85781f2c3b9d3e56b734@changeid> X-Mailer: git-send-email 2.26.0.110.g2183baf09c-goog In-Reply-To: <20200415084758.1.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid> References: <20200415084758.1.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid> MIME-Version: 1.0 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Allow people to specify to use a GPIO for hot-plug-detect. Add an example. NOTE: The current patch adding support for hpd-gpios to the Linux driver for hpd-gpios only adds enough support to the driver so that the bridge can use one of its own GPIOs. The bindings, however, are written generically. Signed-off-by: Douglas Anderson --- .../bindings/display/bridge/ti,sn65dsi86.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 8cacc6db33a9..554bfd003000 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -60,6 +60,10 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats. + hpd-gpios: + maxItems: 1 + description: If present use the given GPIO for hot-plug-detect. + data-lanes: description: See ../../media/video-interface.txt @@ -148,7 +152,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - bridge@2d { + sn65dsi86_bridge: bridge@2d { compatible = "ti,sn65dsi86"; reg = <0x2d>; @@ -165,6 +169,10 @@ examples: clocks = <&rpmhcc RPMH_LN_BB_CLK2>; clock-names = "refclk"; + gpio-controller; + #gpio-cells = <2>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + ports { #address-cells = <1>; #size-cells = <0>; From patchwork Wed Apr 15 15:48:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 11491509 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9397092C for ; Wed, 15 Apr 2020 15:49:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6F7DC208FE for ; Wed, 15 Apr 2020 15:49:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Q+2H5HRG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404421AbgDOPt5 (ORCPT ); Wed, 15 Apr 2020 11:49:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S2394214AbgDOPtx (ORCPT ); Wed, 15 Apr 2020 11:49:53 -0400 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 942BCC061A0C for ; Wed, 15 Apr 2020 08:49:51 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id b8so137121pfp.8 for ; Wed, 15 Apr 2020 08:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3TcYtFb955DdLUqQ4wh/jHw6PTVA4MVFQZ5AAMLk1uI=; b=Q+2H5HRGqXKyuO953mqNSWSWuP0Jcv8K05M9H+z/d6VxWaJnyz6OwL5VqxYVisCc3E 6J4MhvDrnhPaWQsT13ScrFZugoYK/gqrWykjAndpdJkUTE3APxxsojgE1jOwEhzeoEwo Z6N3eOZLbKC+BXFfyy3hEZZIOMDmc8M9ksf9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3TcYtFb955DdLUqQ4wh/jHw6PTVA4MVFQZ5AAMLk1uI=; b=ZPyNqhHdazgXq8S/cVe/LP93EXoxKE0apyUq7unaE7X25uc3GdoO30QdNLFrjYjvOs 2eqpCyFsRIDis8gATbmiM8IKwow0QBlYK2WK7yEN3pSggdsMAwGnfqhmurP4WuWaTh9F Kl6E4KIk/0//JlTq50AIfRzNehLuhkPdKrDNWqFikKKU/9anlNeWA8hR60XJ8DiGCemW gwA8yeg0kuk7jd85VmU4ny1cdKEEjL2c3xjSAl7r0NTyF24PdpGmgJ6H+LqJcQ/fPvg2 TZtuWW+RS+vrvo5ZnzU0uCWPIpKfiqK1P206xtRBU57QktRRVJITnEV9Y1KjDFxee+VG SgVw== X-Gm-Message-State: AGi0PuZMPvb18fJO9VrAcsdKWy9TZ6Plg3gKRcTcw3wY3VX3f9D202UF 7J2es2QiGKl/ODPcDQVg0W6P8A== X-Google-Smtp-Source: APiQypJLeNa5uw5VJSbOSg64EhAnxZefyNQeVYOHS3PESCrfw0xwE/dGys7uupMVLlpw6DBGbzXF+g== X-Received: by 2002:aa7:81c3:: with SMTP id c3mr9311089pfn.12.1586965790965; Wed, 15 Apr 2020 08:49:50 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id x27sm14382473pfj.74.2020.04.15.08.49.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 08:49:50 -0700 (PDT) From: Douglas Anderson To: airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org, narmstrong@baylibre.com, a.hajda@samsung.com, Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org Cc: jonas@kwiboo.se, bjorn.andersson@linaro.org, devicetree@vger.kernel.org, jeffrey.l.hugo@gmail.com, swboyd@chromium.org, jernej.skrabec@siol.net, linux-arm-msm@vger.kernel.org, robdclark@chromium.org, dri-devel@lists.freedesktop.org, Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH 3/3] drm/bridge: ti-sn65dsi86: Allow one of the bridge GPIOs to be HPD Date: Wed, 15 Apr 2020 08:48:41 -0700 Message-Id: <20200415084758.3.Ia50267a5549392af8b37e67092ca653a59c95886@changeid> X-Mailer: git-send-email 2.26.0.110.g2183baf09c-goog In-Reply-To: <20200415084758.1.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid> References: <20200415084758.1.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid> MIME-Version: 1.0 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86: Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is kinda useless, at least for embedded DisplayPort (eDP). However, despite the fact that the actual HPD pin on the bridge is mostly useless for eDP, the concept of HPD for eDP still makes sense. It allows us to optimize out a hardcoded delay that many panels need if HPD isn't hooked up. Panel timing diagrams show HPD as one of the events to measure timing from and we have to assume the worst case if we can't actually read HPD. One way to use HPD for eDP without using the mostly useless HPD pin on ti-sn65dsi86 is to route the panel's HPD somewhere else in the system, like to a GPIO. This works great because eDP panels aren't physically hotplugged. That means the debouncing logic that caused us problems wasn't really needed and a raw GPIO works great. As per the above, a smart board designer would realize the value of HPD and choose to route it to a GPIO somewhere on the board to avoid the silly sn65dsi86 debouncing. While said "smart designer" could theoretically route HPD anywhere on the board, a really smart designer would realize that there are several GPIOs on the bridge itself that are nearly useless for anything but this purpose and route HPD to one of those. Specifically, to argue that the GPIOs on the bridge are mostly useless for non-bridge-related things: - You need to power on the bridge to use them. Ideally a system only powers on the bridge when the screen is on which means you could only use the GPIOs on the bridge when the screen is on (or you're willing to burn a bunch of extra power). - You need to control the GPIOs via i2c commands, which means that you can only use these GPIOs for drivers that can call gpio_set_value_cansleep(). With the above, let's assume that: - If someone was going to route the HPD to a GPIO they'd use one of the GPIOs on the bridge. - There's not lots of value exposing the GPIOs on the bridge through the normal Linux GPIO framework because nobody will likely use them for something non-bridge-related. As you can probably guess from the above arguments, this patch adds the ability to use one of the bridge's GPIOs as the HPD pin but it doesn't add it in the completely generic (and a bit heavier) way of going through the GPIO subsystem. This means: - With this patch you can't use bridge GPIOs for non-bridge purposes. - With this patch you can't use a different GPIO in the SoC for HPD. Despite the above limitations, which keep the code simpler, we still use the generic GPIO device tree bindings. If someone later has a need to relax some of the restrictions here, it would just need a code patch. We wouldn't need to change the device tree bindings. This patch has been tested on a board that is not yet mainline. On the hardware I have: - Panel spec says HPD could take up to 200 ms to come up, so without HPD hooked up we need to delay 200 ms. - On my board the panel is powered by the same rail as the touchscreen. By chance of probe order the touchscreen comes up first. This means by the time we check HPD in ti_sn_bridge_enable() it's already up. Thus we can use the panel on 200 ms earlier. - If I hack out the touscreen, I see that I wait ~31 ms for HPD to go high. This means I save ~169 ms of delay. - If I measure HPD on this pane it comes up ~56 ms after the panel is powered. The delta between 31 and 56 ms is because the panel regulator is turned on at the end of ti_sn_bridge_pre_enable() in drm_panel_prepare(). There is apparently some time between that and ti_sn_bridge_enable(). Signed-off-by: Douglas Anderson --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 107 ++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 6ad688b320ae..187b2bdd0cb4 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -54,6 +54,13 @@ #define BPP_18_RGB BIT(0) #define SN_HPD_DISABLE_REG 0x5C #define HPD_DISABLE BIT(0) +#define SN_GPIO_IO_REG 0x5E +#define SN_GPIO_INPUT_SHIFT 4 +#define SN_GPIO_OUTPUT_SHIFT 0 +#define SN_GPIO_CTRL_REG 0x5F +#define SN_GPIO_MUX_INPUT 0 +#define SN_GPIO_MUX_OUTPUT 1 +#define SN_GPIO_MUX_SPECIAL 2 #define SN_AUX_WDATA_REG(x) (0x64 + (x)) #define SN_AUX_ADDR_19_16_REG 0x74 #define SN_AUX_ADDR_15_8_REG 0x75 @@ -102,6 +109,7 @@ struct ti_sn_bridge { struct gpio_desc *enable_gpio; struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM]; int dp_lanes; + int hpd_gpio_pin; }; static const struct regmap_range ti_sn_bridge_volatile_ranges[] = { @@ -120,6 +128,45 @@ static const struct regmap_config ti_sn_bridge_regmap_config = { .cache_type = REGCACHE_NONE, }; +/** + * ti_sn_read_gpio() - Read a GPIO pin. + * @pdata: Platform data. + * @gpio_num: The GPIO to read. This is 1-based to match the pin names so + * valid values are 1-4. + * + * This function assumes the pin direction / muxing is already configured. + * + * Return: 0 if the pin is low; 1 if the pin is high; -error upon failure + */ +static int ti_sn_read_gpio(struct ti_sn_bridge *pdata, int gpio_num) +{ + unsigned int val; + int ret; + + ret = regmap_read(pdata->regmap, SN_GPIO_IO_REG, &val); + if (ret) + return ret; + + return (val >> (SN_GPIO_INPUT_SHIFT + gpio_num - 1)) & 1; +} + +/** + * ti_sn_setup_mux() - Setup a GPIO pinmux. + * @pdata: Platform data. + * @gpio_num: The GPIO to setup. This is 1-based to match the pin names so + * valid values are 1-4. + * @val: The mux value; One of the SN_GPIO_MUX_... constants. + * + * Return: 0 if success; either error. + */ +static int ti_sn_setup_mux(struct ti_sn_bridge *pdata, int gpio_num, int val) +{ + int shift = (gpio_num - 1) * 2; + + return regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG, + 0x3 << shift, val << shift); +} + static void ti_sn_bridge_write_u16(struct ti_sn_bridge *pdata, unsigned int reg, u16 val) { @@ -658,6 +705,11 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, return ret; } +static bool ti_sn_read_hpd_gpio(struct ti_sn_bridge *pdata) +{ + return ti_sn_read_gpio(pdata, pdata->hpd_gpio_pin) == 1; +} + static void ti_sn_bridge_enable(struct drm_bridge *bridge) { struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge); @@ -666,6 +718,25 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge) int dp_rate_idx; unsigned int val; int ret = -EINVAL; + bool hpd_asserted; + + /* + * On some designs HPD could be routed to one of the GPIOs on the + * bridge. In that case, delay up to 2 seconds waiting for HPD to be + * asserted. + */ + if (pdata->hpd_gpio_pin) { + ret = ti_sn_setup_mux(pdata, pdata->hpd_gpio_pin, + SN_GPIO_MUX_INPUT); + if (ret) { + DRM_ERROR("failed to setup HPD mux\n"); + return; + } + + ret = readx_poll_timeout(ti_sn_read_hpd_gpio, pdata, + hpd_asserted, hpd_asserted, + 1000, 2000000); + } /* * Run with the maximum number of lanes that the DP sink supports. @@ -874,6 +945,40 @@ static int ti_sn_bridge_parse_dsi_host(struct ti_sn_bridge *pdata) return 0; } +static void ti_sn_probe_hpd_gpio(struct ti_sn_bridge *pdata) +{ + struct device_node *np = pdata->dev->of_node; + int num_elems; + u32 hpd_gpio_pin; + + num_elems = of_property_count_u32_elems(np, "hpd-gpios"); + + /* It's optional, so no worries if it's not there */ + if (num_elems == -EINVAL) + return; + + if (num_elems != 3) { + dev_warn(pdata->dev, + "Unexpected hpd-gpios count (%d); ignoring\n", + num_elems); + return; + } + + /* + * Right now, we only support using one of our own GPIOs for + * this, but our device tree bindings are more generic. Confirm + * we're actually a client of ourselves. + */ + if (of_parse_phandle(np, "hpd-gpios", 0) != np) { + dev_warn(pdata->dev, + "Only bridge-local hpd-gpios supported; ignoring\n"); + return; + } + + if (!of_property_read_u32_index(np, "hpd-gpios", 1, &hpd_gpio_pin)) + pdata->hpd_gpio_pin = hpd_gpio_pin; +} + static int ti_sn_bridge_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -916,6 +1021,8 @@ static int ti_sn_bridge_probe(struct i2c_client *client, return ret; } + ti_sn_probe_hpd_gpio(pdata); + ret = ti_sn_bridge_parse_regulators(pdata); if (ret) { DRM_ERROR("failed to parse regulators\n");