From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 770DAC4725E for ; Thu, 30 Apr 2020 19:47:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4FD9020774 for ; Thu, 30 Apr 2020 19:47:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ed1A4jwG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726851AbgD3Tq1 (ORCPT ); Thu, 30 Apr 2020 15:46:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbgD3Tq1 (ORCPT ); Thu, 30 Apr 2020 15:46:27 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1281C035495 for ; Thu, 30 Apr 2020 12:46:26 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id 7so3887415pjo.0 for ; Thu, 30 Apr 2020 12:46:26 -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=ra7mjq8W6zmgPcLiIaItAAcFCZHz/YFFi7FQSJs3dtI=; b=ed1A4jwGrOn1n50TCUVoPnzef1xzoJBlgvyRW+Ov2HdLT9/mhC0E9DLA+vyQbgn7CO TRqoJvyj3MaEBlQke8sv2jYdXNdRwuCVZORy1ButXS16AMSWpsvr53NeTV5lJjdF/mNq mce7b144XuDxrwYF3rDvIIP3SjML0eHJg0M7w= 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=ra7mjq8W6zmgPcLiIaItAAcFCZHz/YFFi7FQSJs3dtI=; b=jqapxoziuTgAb2Lf+iiLQ6lV89XW8w4ToChrHwCo3QXTRnAaP2H/CcYlp0JNlrUs0B FYZiNb8C3cofaam6xO7cwZnrw7EFevmQc37DTEKHyeNT1hB5R8hCxQ+01Z1SjC0b8HgP 2Zua4BSR0ZiAnKalZsyo4YCUnhXSJ28u947gVc6+f285zN7KjNzfcUMMgZC5voNbd23/ n/xpfxIcSbF2eFZwzwYV0wNGkXYpnkYTOQV7QVTNHKE99tWEcYZ2AmupgHdrqZI8BFB+ DCtuAJmGmBZPPsbFz4A+JF+PH3KfmdZdLR0+BxlnYOAHn37eFcm8+anbIAqGpYOCHVnc Tz/A== X-Gm-Message-State: AGi0PuZlaclKedyP4p162d7ZNfbKPIFIGQ6TXwmMGSbdyHqjb3L3iwB9 3cAp7lHSzYm1B+VoQ7nctjZIcg== X-Google-Smtp-Source: APiQypI4aWGN8QYQmsWGb/tBQiOuqS/stRkAUG9VFIBD09lxji6QhItqnocfw0Mz14Wl3f+dP0NFwg== X-Received: by 2002:a17:902:784c:: with SMTP id e12mr586920pln.191.1588275986135; Thu, 30 Apr 2020 12:46:26 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id u3sm495993pfb.105.2020.04.30.12.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2020 12:46:25 -0700 (PDT) From: Douglas Anderson To: linus.walleij@linaro.org, bgolaszewski@baylibre.com, 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: linux-gpio@vger.kernel.org, jonas@kwiboo.se, robdclark@chromium.org, bjorn.andersson@linaro.org, jeffrey.l.hugo@gmail.com, jernej.skrabec@siol.net, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, swboyd@chromium.org, Douglas Anderson , Andy Gross , Krzysztof Kozlowski , Paul Walmsley , Sam Ravnborg , Thierry Reding , linux-kernel@vger.kernel.org Subject: [PATCH v4 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Date: Thu, 30 Apr 2020 12:46:11 -0700 Message-Id: <20200430194617.197510-1-dianders@chromium.org> X-Mailer: git-send-email 2.26.2.526.g744177e7f7-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. This series of patches is intended to allow the scenario described above. 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 measure HPD on this pane it comes up ~56 ms after the panel is powered. This means I can save 144 ms of delay. Side effects (though not main goals) of this series are: - ti-sn65dsi86 GPIOs are now exported in Linux. - ti-sn65dsi86 bindings are converted to yaml. - Common panel bindings now have "hpd-gpios" listed. - The simple-panel driver in Linux can delay in prepare based on "hpd-gpios" - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd" if HPD isn't hooked up. Changes in v4: - Don't include gpio.h - Use gpiochip_get_data() instead of container_of() to get data. - GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX - Use Linus W's favorite syntax to read a bit from a bitfield. - Define and use SN_GPIO_MUX_MASK. - Add a comment about why we use a bitmap for gchip_output. - Tacked on "or is otherwise unusable." to description. Changes in v3: - Becaue => Because - Add a kernel-doc to our pdata to clarify double-duty of gchip_output. - More comments about how powering off affects us (get_dir, dir_input). - Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return". - Use a bitmap rather than rolling my own. - Remind how gpio_get_optional() works in the commit message. - useful implement => useful to implement Changes in v2: - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs") - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2 - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs") - specification => specifier. - power up => power. - Added back missing suspend-gpios. - data-lanes and lane-polarities are are the right place now. - endpoints don't need to be patternProperties. - Specified more details for data-lanes and lane-polarities. - Added old example back in, fixing bugs in it. - Example i2c bus is just called "i2c", not "i2c1" now. - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2. - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2. Douglas Anderson (6): drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux dt-bindings: display: Add hpd-gpios to panel-common bindings drm/panel-simple: Support hpd-gpios for delaying prepare() dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza .../bindings/display/bridge/ti,sn65dsi86.txt | 87 ------ .../bindings/display/bridge/ti,sn65dsi86.yaml | 287 ++++++++++++++++++ .../bindings/display/panel/panel-common.yaml | 6 + arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 195 ++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 53 ++++ 6 files changed, 543 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 -- 2.26.2.526.g744177e7f7-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F3AEC47254 for ; Thu, 30 Apr 2020 19:46:28 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E86A720731 for ; Thu, 30 Apr 2020 19:46:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ed1A4jwG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E86A720731 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5B4CC6E94D; Thu, 30 Apr 2020 19:46:27 +0000 (UTC) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9DA456E94D for ; Thu, 30 Apr 2020 19:46:26 +0000 (UTC) Received: by mail-pj1-x1041.google.com with SMTP id 7so3887416pjo.0 for ; Thu, 30 Apr 2020 12:46:26 -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=ra7mjq8W6zmgPcLiIaItAAcFCZHz/YFFi7FQSJs3dtI=; b=ed1A4jwGrOn1n50TCUVoPnzef1xzoJBlgvyRW+Ov2HdLT9/mhC0E9DLA+vyQbgn7CO TRqoJvyj3MaEBlQke8sv2jYdXNdRwuCVZORy1ButXS16AMSWpsvr53NeTV5lJjdF/mNq mce7b144XuDxrwYF3rDvIIP3SjML0eHJg0M7w= 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=ra7mjq8W6zmgPcLiIaItAAcFCZHz/YFFi7FQSJs3dtI=; b=bHgIAqqbYUpx3bEIIJnvdrDZwdyTQ2xmDO+S4gj8nKtWnL13368TuRlWFa7sVdtYUL sh7z98usTjrtUNr7LKRTrDri0k5twhJqd6fjJ6EdtEQDRq7BTcNk1bRPBz6kjDBiOzqw QLmueYK1L6O+x6USO+Dgm+7GNRxFhvIdEn3hB4fYhViSSh2syBlccLiSVtX5dhqGK4EI qcyUtzZI2HPr45Q4SJR0sW8jCSLK+Gaw+9B4OAfl7TtOW1Vz3FkwHKUxEUvFWGjk2LZ6 tc1L+TT0Qqzq1M0KAWfSOtz9OrHbOGvFB2fdX0PAjm+UfoV8Ah/iWwx4M96aaMPcV1XQ 0r0A== X-Gm-Message-State: AGi0Pubt0+3Epv/dsf+pWibeUSKGKhrry1dI+6CumpDcLxY+9iQLIA2V TzvSh30CoeWhj0rxKl+sZ8zFEg== X-Google-Smtp-Source: APiQypI4aWGN8QYQmsWGb/tBQiOuqS/stRkAUG9VFIBD09lxji6QhItqnocfw0Mz14Wl3f+dP0NFwg== X-Received: by 2002:a17:902:784c:: with SMTP id e12mr586920pln.191.1588275986135; Thu, 30 Apr 2020 12:46:26 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:24fa:e766:52c9:e3b2]) by smtp.gmail.com with ESMTPSA id u3sm495993pfb.105.2020.04.30.12.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2020 12:46:25 -0700 (PDT) From: Douglas Anderson To: linus.walleij@linaro.org, bgolaszewski@baylibre.com, airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org, narmstrong@baylibre.com, a.hajda@samsung.com, Laurent.pinchart@ideasonboard.com, spanda@codeaurora.org Subject: [PATCH v4 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Date: Thu, 30 Apr 2020 12:46:11 -0700 Message-Id: <20200430194617.197510-1-dianders@chromium.org> X-Mailer: git-send-email 2.26.2.526.g744177e7f7-goog MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: robdclark@chromium.org, devicetree@vger.kernel.org, jernej.skrabec@siol.net, jeffrey.l.hugo@gmail.com, linux-arm-msm@vger.kernel.org, jonas@kwiboo.se, Douglas Anderson , dri-devel@lists.freedesktop.org, bjorn.andersson@linaro.org, linux-gpio@vger.kernel.org, Andy Gross , Thierry Reding , Krzysztof Kozlowski , Paul Walmsley , swboyd@chromium.org, Sam Ravnborg , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. This series of patches is intended to allow the scenario described above. 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 measure HPD on this pane it comes up ~56 ms after the panel is powered. This means I can save 144 ms of delay. Side effects (though not main goals) of this series are: - ti-sn65dsi86 GPIOs are now exported in Linux. - ti-sn65dsi86 bindings are converted to yaml. - Common panel bindings now have "hpd-gpios" listed. - The simple-panel driver in Linux can delay in prepare based on "hpd-gpios" - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd" if HPD isn't hooked up. Changes in v4: - Don't include gpio.h - Use gpiochip_get_data() instead of container_of() to get data. - GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX - Use Linus W's favorite syntax to read a bit from a bitfield. - Define and use SN_GPIO_MUX_MASK. - Add a comment about why we use a bitmap for gchip_output. - Tacked on "or is otherwise unusable." to description. Changes in v3: - Becaue => Because - Add a kernel-doc to our pdata to clarify double-duty of gchip_output. - More comments about how powering off affects us (get_dir, dir_input). - Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return". - Use a bitmap rather than rolling my own. - Remind how gpio_get_optional() works in the commit message. - useful implement => useful to implement Changes in v2: - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs") - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2 - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs") - specification => specifier. - power up => power. - Added back missing suspend-gpios. - data-lanes and lane-polarities are are the right place now. - endpoints don't need to be patternProperties. - Specified more details for data-lanes and lane-polarities. - Added old example back in, fixing bugs in it. - Example i2c bus is just called "i2c", not "i2c1" now. - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2. - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2. Douglas Anderson (6): drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux dt-bindings: display: Add hpd-gpios to panel-common bindings drm/panel-simple: Support hpd-gpios for delaying prepare() dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza .../bindings/display/bridge/ti,sn65dsi86.txt | 87 ------ .../bindings/display/bridge/ti,sn65dsi86.yaml | 287 ++++++++++++++++++ .../bindings/display/panel/panel-common.yaml | 6 + arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 2 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 195 ++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 53 ++++ 6 files changed, 543 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 -- 2.26.2.526.g744177e7f7-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel