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=-0.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 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 D5235C54E49 for ; Sat, 9 May 2020 22:49:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AE370208DB for ; Sat, 9 May 2020 22:49:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="UDXkhZzq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727976AbgEIWs6 (ORCPT ); Sat, 9 May 2020 18:48:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727887AbgEIWs6 (ORCPT ); Sat, 9 May 2020 18:48:58 -0400 Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1712DC05BD09 for ; Sat, 9 May 2020 15:48:58 -0700 (PDT) Received: by mail-ua1-x944.google.com with SMTP id a7so2048265uak.2 for ; Sat, 09 May 2020 15:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1z6oppBATgO51fKBm6uoe5dBY+8qJAJ+NcU9svBiBE=; b=UDXkhZzqvn6HISO/zwZFZ7FZVudKN1BUwwPpa1bhMiQAp57zi77qXCZkWGSGbJnaj+ CpidWsT8xIRgF3KBvMaUmHntjppKEZZbn2EZCUsY4wsc5xKCasW7y1lBeLcBAmQozU70 +WBgYOmN9SKxTya/oya8RORLtmXdR1BuD2x84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1z6oppBATgO51fKBm6uoe5dBY+8qJAJ+NcU9svBiBE=; b=etnrEEsYrLoV8qliwZY6/6DE+6oPhwfBYl8raYxbQ5205VWFXFH9yfo/WwLcbbbfh9 90/TBzs5KH/rZqrp0CZzKK04Y7czl81IYE6+FqICI+p9FTGdyF1s0GD4ztk8l5zOhuHy jNW9imji/0+a7dHnQsFNgPRcZM4ZbUq7otHKiuygObqGMT6qL0MXGzufLdcnDHtv7SyT ttZBsU9B3S+BS7AiMAFLP6zmbCl8zRVS2cAXK4Irp4K6HyC/A1AXQabhBUkzTf2g93t0 WkY3lW5qucGZgiQO+1uj1m3pEgnOlFEUoV4WuCUROeMqNSvdOzY7cLeWbo3lclCJz/hi 03vw== X-Gm-Message-State: AGi0PuZdAvIENzliAYqdR8ZBG0QzYB6TenvAwNx/eNlJYkxUuX7J3sMY wcNWhe5zQKpulueHZDCO25hRc9A9sCM= X-Google-Smtp-Source: APiQypLWd16te8UpM5T8YxbM1lbPQbnXaR32QNQh245ztZsdpCMCOFeg3b0+Qrd7U8CFoAZnMX9NSA== X-Received: by 2002:ab0:142f:: with SMTP id b44mr6803689uae.113.1589064536756; Sat, 09 May 2020 15:48:56 -0700 (PDT) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com. [209.85.222.47]) by smtp.gmail.com with ESMTPSA id x6sm5362607vkx.1.2020.05.09.15.48.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 15:48:55 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id r2so2049358uam.7 for ; Sat, 09 May 2020 15:48:54 -0700 (PDT) X-Received: by 2002:ab0:b13:: with SMTP id b19mr6914696uak.91.1589064534355; Sat, 09 May 2020 15:48:54 -0700 (PDT) MIME-Version: 1.0 References: <20200507213500.241695-1-dianders@chromium.org> <20200509201511.GD30802@ravnborg.org> In-Reply-To: <20200509201511.GD30802@ravnborg.org> From: Doug Anderson Date: Sat, 9 May 2020 15:48:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect To: Sam Ravnborg , LinusW , Stephen Boyd , Laurent Pinchart Cc: Bartosz Golaszewski , David Airlie , Daniel Vetter , Rob Herring , Neil Armstrong , Andrzej Hajda , Sandeep Panda , Rob Clark , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Jernej Skrabec , Jeffrey Hugo , Stephen Boyd , linux-arm-msm , Jonas Karlman , dri-devel , "open list:GPIO SUBSYSTEM" , Andy Gross , Thierry Reding , Krzysztof Kozlowski , Paul Walmsley , Bjorn Andersson , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg wrote: > > Hi Douglas. > > On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote: > > > > 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 v5: > > - Use of_xlate so that numbers in dts start at 1, not 0. > > - Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > > > 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 > > Applied: > > dt-bindings: display: Add hpd-gpios to panel-common bindings > > drm/panel-simple: Support hpd-gpios for delaying prepare() > to drm-misc-next. > > The others was missing reviews so we need to wait for feedback. Thanks! Given the previous feedback from Linus W, Stephen, and Laurent I expect things are good enough to land now, but it'd be good to get confirmation (I removed some of the previous tags just to get confirmation). If we can get review tags early next week maybe it'll still be in time to land for 5.8? -Doug 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 D6B45C47255 for ; Sat, 9 May 2020 22:55:36 +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 93ABE208DB for ; Sat, 9 May 2020 22:55:36 +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="UDXkhZzq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93ABE208DB 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 DD57D6E06B; Sat, 9 May 2020 22:55:35 +0000 (UTC) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by gabe.freedesktop.org (Postfix) with ESMTPS id 65A696E06B for ; Sat, 9 May 2020 22:55:34 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id 4so4847543qtb.4 for ; Sat, 09 May 2020 15:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1z6oppBATgO51fKBm6uoe5dBY+8qJAJ+NcU9svBiBE=; b=UDXkhZzqvn6HISO/zwZFZ7FZVudKN1BUwwPpa1bhMiQAp57zi77qXCZkWGSGbJnaj+ CpidWsT8xIRgF3KBvMaUmHntjppKEZZbn2EZCUsY4wsc5xKCasW7y1lBeLcBAmQozU70 +WBgYOmN9SKxTya/oya8RORLtmXdR1BuD2x84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1z6oppBATgO51fKBm6uoe5dBY+8qJAJ+NcU9svBiBE=; b=DfdpGC86A9lO1N7dNXqTCncIbWEqCZCMI4a+VB6fa5CLZdc+il8c+DONiVEexdIza/ E/0xR814JRE2qEVp7y7M9KZT1xHv0tZXmJxds49GjJPepSmxKrDI5ozuME1D4MlOJkXv MOJgwmX+bPkYCHB0lo63VtN9DrekKNmR1emt/VVfdrT4rAh+awFJ43hecBkN6YFfk/JP yPESeEvJ+iZJO97LMJN/DtrnxPobBtizE33CFJdGeqE2+00wLsh6qxN9J8cGzbMW+ROO 3diUtSU3qnM/nIX51E/aKhZYMGYMN4QSR9z/27N8qAlSRkwwAzZ+6AIEZ9WgMpf6pAUO oynQ== X-Gm-Message-State: AGi0Puaznkvs7aDBpsWOf7klMEV6WsYXpfJN6ZBIJp9fFx7Yp4CQjN+8 tP62yvcqjQTpaUHv2SqK1VraEqsbhWg= X-Google-Smtp-Source: APiQypJ+aCqpQ8AEhudO1ciDnppGv0vnUtldttAukZmiYr2rE3ef9kkGpr66cUjsdOZDRy0fFB1B+A== X-Received: by 2002:ac8:6b09:: with SMTP id w9mr10154100qts.263.1589064933196; Sat, 09 May 2020 15:55:33 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id k43sm5547280qtk.67.2020.05.09.15.55.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 15:55:33 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id c2so3019389ybi.7 for ; Sat, 09 May 2020 15:55:33 -0700 (PDT) X-Received: by 2002:ab0:b13:: with SMTP id b19mr6914696uak.91.1589064534355; Sat, 09 May 2020 15:48:54 -0700 (PDT) MIME-Version: 1.0 References: <20200507213500.241695-1-dianders@chromium.org> <20200509201511.GD30802@ravnborg.org> In-Reply-To: <20200509201511.GD30802@ravnborg.org> From: Doug Anderson Date: Sat, 9 May 2020 15:48:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect To: Sam Ravnborg , LinusW , Stephen Boyd , Laurent Pinchart 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: Neil Armstrong , David Airlie , Sandeep Panda , dri-devel , Bjorn Andersson , Andrzej Hajda , Thierry Reding , Rob Clark , Jeffrey Hugo , Krzysztof Kozlowski , Bartosz Golaszewski , Andy Gross , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Jonas Karlman , linux-arm-msm , "open list:GPIO SUBSYSTEM" , Rob Herring , Paul Walmsley , Jernej Skrabec , Stephen Boyd , LKML Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg wrote: > > Hi Douglas. > > On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote: > > > > 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 v5: > > - Use of_xlate so that numbers in dts start at 1, not 0. > > - Squash https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/ > > > > 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 > > Applied: > > dt-bindings: display: Add hpd-gpios to panel-common bindings > > drm/panel-simple: Support hpd-gpios for delaying prepare() > to drm-misc-next. > > The others was missing reviews so we need to wait for feedback. Thanks! Given the previous feedback from Linus W, Stephen, and Laurent I expect things are good enough to land now, but it'd be good to get confirmation (I removed some of the previous tags just to get confirmation). If we can get review tags early next week maybe it'll still be in time to land for 5.8? -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel