From patchwork Fri Jul 30 21:26:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 489387 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=-19.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 395B2C4338F for ; Fri, 30 Jul 2021 21:26:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2232060F46 for ; Fri, 30 Jul 2021 21:26:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231939AbhG3V0y (ORCPT ); Fri, 30 Jul 2021 17:26:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231903AbhG3V0w (ORCPT ); Fri, 30 Jul 2021 17:26:52 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9B92C0613C1 for ; Fri, 30 Jul 2021 14:26:46 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id e5so12605719pld.6 for ; Fri, 30 Jul 2021 14:26:46 -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=uDbg21Rf2V3jdZDSKF8dbOSamKttBFrGYQS/hOkLKIM=; b=Dt3QaGEKJYQZpLNZ++o1Zh7kagDav2QSU5ZW7Z46Hb/uObkC78VphH8EgnIIj97Rdm 1EO47fO8lBpdVGkPx0g2fBeXbz25u3zHUp/jrnZB3stIlEmHpihzNztapECzMg7HLXKw AmWLluiT4t/pxEPrj5pbfoOpqwWsk1W+n4O/w= 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=uDbg21Rf2V3jdZDSKF8dbOSamKttBFrGYQS/hOkLKIM=; b=dR9/VMDDhE6FFZq+wtT6QKWeCjs9OPojV+8esgIleM7GX+Jnyt/8kNHjQekWXZcRof 6cDrTjWU+dQhnuUXhHq4yX3O7YM65+iyhE6Ugr80ClpgCgS3Q7hx51LGlsBz9V3kIgTu fRtVjCc2kXQV+d1k+JT/rLtgrXkhvwAxCQ54JKbWrYu4wfpKEOwAhZtQ0nscdD7SKl48 t3XN2nv2zmsg0tn0nB4l3G6ADX54hF+1BFQIdOg7vEmHAMXR80zFjMSgeRmbno5lDmtH 9ILZGg5rOm/Ka0bqjV+AXO7HcMONjgn5u5zWSG7ArZg4rsU41DdfEgpBy6W2qESZuDLn I8lA== X-Gm-Message-State: AOAM530f/BjmOqbGmsCDpO/KzaySLJNiLncYM2e/KItwiOSDaIJxdkJD RBQhILObUj0NTjAL04n6iKJlXg== X-Google-Smtp-Source: ABdhPJy29foJ9bcVWNWDDSnMOmun1T+EKhKagCWWHZ2uc3dmqwxtcbjTqo+KDuWUfDXITLP/4vQgoQ== X-Received: by 2002:a17:90a:a511:: with SMTP id a17mr5267369pjq.69.1627680406216; Fri, 30 Jul 2021 14:26:46 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:3424:e0ac:5a92:d061]) by smtp.gmail.com with ESMTPSA id u21sm3484625pfh.163.2021.07.30.14.26.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 14:26:45 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring Cc: Sam Ravnborg , Thomas Zimmermann , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Maarten Lankhorst , devicetree@vger.kernel.org, David Airlie , Bjorn Andersson , Maxime Ripard , Steev Klimaszewski , Linus W , Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH v2 1/6] dt-bindings: drm/panel-simple: Introduce generic eDP panels Date: Fri, 30 Jul 2021 14:26:20 -0700 Message-Id: <20210730142537.v2.1.I1116e79d34035338a45c1fc7cdd14a097909c8e0@changeid> X-Mailer: git-send-email 2.32.0.554.ge1b32706d8-goog In-Reply-To: <20210730212625.3071831-1-dianders@chromium.org> References: <20210730212625.3071831-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org eDP panels generally contain almost everything needed to control them in their EDID. This comes from their DP heritage were a computer needs to be able to properly control pretty much any DP display that's plugged into it. The one big issue with eDP panels and the reason that we need a panel driver for them is that the power sequencing can be different per panel. While it is true that eDP panel sequencing can be arbitrarily complex, in practice it turns out that many eDP panels are compatible with just some slightly different delays. See the contents of the bindings file introduced in this patch for some details. The fact that eDP panels are 99% probable and that the power sequencing (especially power up) can be compatible between many panels means that there's a constant desire to plug multiple different panels into the same board. This could be for second sourcing purposes or to support multiple SKUs (maybe a 11" and a 13", for instance). As discussed [1], it should be OK to support this by adding two properties to the device tree to specify the delays needed for powering up the panel the first time. We'll create a new "edp-panel" bindings file and define the two delays that might need to be specified. NOTE: in the vast majority of the cases (HPD is hooked up and isn't glitchy or is debounced) even these delays aren't needed. [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com Signed-off-by: Douglas Anderson --- Changes in v2: - No longer allow fallback to panel-simple. - Add "-ms" suffix to delays. .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml new file mode 100644 index 000000000000..6a621376ff86 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.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/panel/panel-edp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Probable (via DP AUX / EDID) eDP Panels with simple poweron sequences + +maintainers: + - Douglas Anderson + +description: | + This binding file can be used to indicate that an eDP panel is connected + to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without + actually specifying exactly what panel is connected. This is useful for + the case that more than one different panel could be connected to the + board, either for second-sourcing purposes or to support multiple SKUs + with different LCDs that hook up to a common board. + + As per above, a requirement for using this binding is that the panel is + represented under the DP AUX bus. This means that we can use any + information provided by the DP AUX bus (including the EDID) to identify + the panel. We can use this to identify display size, resolution, and + timings among other things. + + One piece of information about eDP panels that is typically _not_ + provided anywhere on the DP AUX bus is the power sequencing timings. + This is the reason why, historically, we've always had to explicitly + list eDP panels. We solve that here with two tricks. The "worst case" + power on timings for any panels expected to be connected to a board are + specified in these bindings. Once we've powered on, it's expected that + the operating system will lookup the panel in a table (based on EDID + information) to figure out other power sequencing timings. + + eDP panels in general can have somewhat arbitrary power sequencing + requirements. However, even though it's arbitrary in general, the + vast majority of panel datasheets have a power sequence diagram that + looks the exactly the same as every other panel. Each panel datasheet + cares about different timings in this diagram but the fact that the + diagram is so similar means we can come up with a single driver to + handle it. + + These diagrams all look roughly like this, sometimes labeled with + slightly different numbers / lines but all pretty much the same + sequence. This is because much of this diagram comes straight from + the eDP Standard. + + __________________________________________________ + Vdd ___/: :\____ / + _/ : : \_____/ + ::: :<--T10-->::: + : +-----------------------+---------+---------+ + eDP -----------+ Black video | Src vid | Blk vid + + Display : +-----------------------+---------+---------+ + : _______________________:_________:_________: + HPD :| : : | + ___________| : : |_____________ + : : : : + Sink +-----------------------:---------:---------+ + AUX CH -----------+ AUX Ch operational : : +------------- + +-----------------------:---------:---------+ + : : : : + :: :: : : + Src main +------+------+--------------+---------+ + lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+------------- + +------+------+--------------+---------+ + : :<-T6->:<-T8->: : + :__:: + LED_EN | | + _____________________________________| |____________________________ + : : + __________:__:_ + PWM | : : | + __________________________| : : |__________________________ + : : : : + _____________:__________:__:_:______ + Bklight ____/: : : : : :\____ + power _______/ :<---T13---->: : : :: \______________ + (Vbl) ::<---------T14--------->: :<-T15->:: + + The above looks fairly complex but, as per above, each panel only cares + about a subset of those timings. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: edp-panel + + hpd-reliable-delay-ms: + description: + A fixed amount of time that must be waited after powering on the + panel's power-supply before the HPD signal is a reliable way to know + when the AUX channel is ready. This is useful for panels that glitch + the HPD at the start of power-on. This value is not needed if HPD is + always reliable for all panels that might be connected. + + hpd-absent-delay-ms: + description: + The panel specifies that HPD will be asserted this many milliseconds + from power on (timing T3 in the diagram above). If we have no way to + measure HPD then a fixed delay of this many milliseconds can be used. + This can also be used as a timeout when waiting for HPD. Does not + include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms + and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and + then we know HPD would assert in the next 120 ms. This value is not + needed if HPD hooked up, either through a GPIO in the panel node or + hooked up directly to the eDP controller. + + backlight: true + enable-gpios: true + port: true + power-supply: true + no-hpd: true + hpd-gpios: true + +additionalProperties: false + +required: + - compatible + - power-supply + +examples: + - | + #include + #include + #include + + i2c { + #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"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + sn65dsi86_out: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + + aux-bus { + panel { + compatible = "edp-panel"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + hpd-reliable-delay-ms = <15>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; + }; + }; From patchwork Fri Jul 30 21:26:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 489386 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=-19.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 AE133C43214 for ; Fri, 30 Jul 2021 21:26:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A7DD60F46 for ; Fri, 30 Jul 2021 21:26:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231903AbhG3V07 (ORCPT ); Fri, 30 Jul 2021 17:26:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232460AbhG3V04 (ORCPT ); Fri, 30 Jul 2021 17:26:56 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A18BAC0613C1 for ; Fri, 30 Jul 2021 14:26:51 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id m10-20020a17090a34cab0290176b52c60ddso16194799pjf.4 for ; Fri, 30 Jul 2021 14:26: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=37Nacw64+KOiMZmL+vH2rc7D0NFwBJZ1GX41lOzA7sI=; b=k3dRWkT1xUJQUM1V3eFMcOCXVOa7G3HDa077JfJ6+aehexe59cOrNfpB0XemFMroc7 9fP1fXGIEoJ8JUIUXS0nvYt0g7InyqCzjz5uw5aaB6YNXKRPz3KVs6jgRqfLRflWaoNM EtrOjelZ44Et6gdFGNEK/YWJ3uD9WIzm5XkIY= 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=37Nacw64+KOiMZmL+vH2rc7D0NFwBJZ1GX41lOzA7sI=; b=mEZ/IQHRBk9RgWw4QIHImoWsTLUZk3LxVHBOI3EuJYmaJS5yrrvmzPYwOLN1UzzlPT /bVNEGvL/Gqwy4OkM5FEecuaqNplb3UDz0sDFltRLLBmrxXxxAJPAfOauan8Rkasall6 H23MLNVAiIevE4ow9POppVXxktVlMVkKQ1MR1MzjWcBEurBQqQlerE5utAUGIvIVNcUE MD+KyNOrL3IYvjrG69XQCD0hXY2M1r90NyyShmKKu+pOTIpMXXawFCNeXWueL1wcedYj 0f0SQZvksRYpbzWNnAqwbZ7QKLLgJvEYn8hfNXfeiskAw/kpNE75qzCJgPI6Yh3BBXsw 4s3Q== X-Gm-Message-State: AOAM5302R6VTiXlNd+EpdyuuIS0XhDsIaqLDijdfr5fhNeSNxHp1aCy7 92yAORMSB/5rCHqtx1K2D970cw== X-Google-Smtp-Source: ABdhPJyd5vlwWOM/HeeHAZX/FPiTwLb2eJnUBso0gVxPSxpB1owLbAxI8YeEzKhk0K0yQ86ZtY/f3Q== X-Received: by 2002:a63:2308:: with SMTP id j8mr4059101pgj.166.1627680411233; Fri, 30 Jul 2021 14:26:51 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:3424:e0ac:5a92:d061]) by smtp.gmail.com with ESMTPSA id u21sm3484625pfh.163.2021.07.30.14.26.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 14:26:50 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring Cc: Sam Ravnborg , Thomas Zimmermann , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Maarten Lankhorst , devicetree@vger.kernel.org, David Airlie , Bjorn Andersson , Maxime Ripard , Steev Klimaszewski , Linus W , Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH v2 4/6] drm/panel-simple: Don't re-read the EDID every time we power off the panel Date: Fri, 30 Jul 2021 14:26:23 -0700 Message-Id: <20210730142537.v2.4.Ib810fb3bebd0bd6763e4609e1a6764d06064081e@changeid> X-Mailer: git-send-email 2.32.0.554.ge1b32706d8-goog In-Reply-To: <20210730212625.3071831-1-dianders@chromium.org> References: <20210730212625.3071831-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org The simple-panel driver is for panels that are not hot-pluggable at runtime. Let's keep our cached EDID around until driver unload. Signed-off-by: Douglas Anderson --- (no changes since v1) drivers/gpu/drm/panel/panel-simple.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index ff8b59471c71..b06bf30c65d0 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -350,9 +350,6 @@ static int panel_simple_suspend(struct device *dev) regulator_disable(p->supply); p->unprepared_time = ktime_get(); - kfree(p->edid); - p->edid = NULL; - return 0; } @@ -834,6 +831,9 @@ static int panel_simple_remove(struct device *dev) if (panel->ddc && (!panel->aux || panel->ddc != &panel->aux->ddc)) put_device(&panel->ddc->dev); + kfree(panel->edid); + panel->edid = NULL; + return 0; } From patchwork Fri Jul 30 21:26:24 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 489385 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=-19.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 5F136C43214 for ; Fri, 30 Jul 2021 21:27:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 48A7560F3A for ; Fri, 30 Jul 2021 21:27:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232774AbhG3V1D (ORCPT ); Fri, 30 Jul 2021 17:27:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230004AbhG3V07 (ORCPT ); Fri, 30 Jul 2021 17:26:59 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A19E5C06175F for ; Fri, 30 Jul 2021 14:26:53 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id o44-20020a17090a0a2fb0290176ca3e5a2fso16248275pjo.1 for ; Fri, 30 Jul 2021 14:26:53 -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=/9pe0vp/2S/yyqFRQwYtuI91YF1fj5/j9qd/6MVyxqs=; b=BHXVq1MELYCtBV1DweXqBcVD2kudADL1JM8qpK0g3TeRhog1FtBWSIOx+tkx0O2qeR f0uNhIkDdWYsdXndWcG4IeUH9hqRqUc84qcym81SiRG6Sm3AS1vYv15zDyEN4rp3RLcI 4qNTMUpBQgkmsR043IFfKWNnWLfZnFcZHfa5I= 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=/9pe0vp/2S/yyqFRQwYtuI91YF1fj5/j9qd/6MVyxqs=; b=snfzWBh3ziRIGeg77dBMDu/T/jOnzoKnwxV+UIuMHMSxYcJMg4VmXOlbnDdva0OItz 5E8qt1Cc4aQhpMwrKCDFHgY+jLIGvrfOZsn8LjdKswvOll/WBoptmqOf9hPZu5FosOCn k92SEevE03omjfRLwnH2yFZLCbzfmrtoqBeO6JyXzon+SUN7jf8iwH1LeVqPpfIijCv5 Xmeczj4HaPwxioBzg+Hao97hkb2Jvw/NWD9Z8CTx8aPZT0JGzyQmdVyaEA2NRYe0Nny/ K27JkEj7R9Ir4oSjBd4X+oytmlRRrqCo7CfxM43nZbLOvU9ETYorVgOeoj1cmwIewqjp Tl4w== X-Gm-Message-State: AOAM5321AsyNLnt8UzzaRFhdpAR0FBbYZfEvtaP7SFQFKD+XRqWwf0qz tZ3l3aXJYPBtW80nCyld6N/6eg== X-Google-Smtp-Source: ABdhPJxBN3lxm1xi3KDrnnKCQfeCE7CY6sVtsiHHzl5j9dYSm4NyqWLxct5ErQnSu186qB/gdEC1Pg== X-Received: by 2002:a62:7c4d:0:b029:3b0:b284:fd9c with SMTP id x74-20020a627c4d0000b02903b0b284fd9cmr2739725pfc.11.1627680413218; Fri, 30 Jul 2021 14:26:53 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:3424:e0ac:5a92:d061]) by smtp.gmail.com with ESMTPSA id u21sm3484625pfh.163.2021.07.30.14.26.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 14:26:52 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring Cc: Sam Ravnborg , Thomas Zimmermann , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Maarten Lankhorst , devicetree@vger.kernel.org, David Airlie , Bjorn Andersson , Maxime Ripard , Steev Klimaszewski , Linus W , Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH v2 5/6] drm/panel-simple: Split the delay structure out of the panel description Date: Fri, 30 Jul 2021 14:26:24 -0700 Message-Id: <20210730142537.v2.5.I11c226341f8e86d376a53d5ec11cb82f6fd2c38c@changeid> X-Mailer: git-send-email 2.32.0.554.ge1b32706d8-goog In-Reply-To: <20210730212625.3071831-1-dianders@chromium.org> References: <20210730212625.3071831-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org In the case where we can read an EDID for a panel the only part of the panel description that can't be found directly from the EDID is the description of the delays. Let's break the delay structure out so that we can specify just the delays for panels that are detected by EDID. This is simple code motion. No functional change is intended. Signed-off-by: Douglas Anderson --- Changes in v2: - Rebased atop revert of delays between GPIO & regulator drivers/gpu/drm/panel/panel-simple.c | 159 ++++++++++++++------------- 1 file changed, 82 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index b06bf30c65d0..7d80bb20e6e0 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -41,6 +41,87 @@ #include #include +/** + * struct panel_delay - Describes delays for a simple panel. + */ +struct panel_delay { + /** + * @prepare: Time for the panel to become ready. + * + * The time (in milliseconds) that it takes for the panel to + * become ready and start receiving video data + */ + unsigned int prepare; + + /** + * @hpd_absent_delay: Time to wait if HPD isn't hooked up. + * + * Add this to the prepare delay if we know Hot Plug Detect + * isn't used. + */ + unsigned int hpd_absent_delay; + + /** + * @prepare_to_enable: Time between prepare and enable. + * + * The minimum time, in milliseconds, that needs to have passed + * between when prepare finished and enable may begin. If at + * enable time less time has passed since prepare finished, + * the driver waits for the remaining time. + * + * If a fixed enable delay is also specified, we'll start + * counting before delaying for the fixed delay. + * + * If a fixed prepare delay is also specified, we won't start + * counting until after the fixed delay. We can't overlap this + * fixed delay with the min time because the fixed delay + * doesn't happen at the end of the function if a HPD GPIO was + * specified. + * + * In other words: + * prepare() + * ... + * // do fixed prepare delay + * // wait for HPD GPIO if applicable + * // start counting for prepare_to_enable + * + * enable() + * // do fixed enable delay + * // enforce prepare_to_enable min time + */ + unsigned int prepare_to_enable; + + /** + * @enable: Time for the panel to display a valid frame. + * + * The time (in milliseconds) that it takes for the panel to + * display the first valid frame after starting to receive + * video data. + */ + unsigned int enable; + + /** + * @disable: Time for the panel to turn the display off. + * + * The time (in milliseconds) that it takes for the panel to + * turn the display off (no content is visible). + */ + unsigned int disable; + + /** + * @unprepare: Time to power down completely. + * + * The time (in milliseconds) that it takes for the panel + * to power itself down completely. + * + * This time is used to prevent a future "prepare" from + * starting until at least this many milliseconds has passed. + * If at prepare time less time has passed since unprepare + * finished, the driver waits for the remaining time. + */ + unsigned int unprepare; +}; + /** * struct panel_desc - Describes a simple panel. */ @@ -85,83 +166,7 @@ struct panel_desc { } size; /** @delay: Structure containing various delay values for this panel. */ - struct { - /** - * @delay.prepare: Time for the panel to become ready. - * - * The time (in milliseconds) that it takes for the panel to - * become ready and start receiving video data - */ - unsigned int prepare; - - /** - * @delay.hpd_absent_delay: Time to wait if HPD isn't hooked up. - * - * Add this to the prepare delay if we know Hot Plug Detect - * isn't used. - */ - unsigned int hpd_absent_delay; - - /** - * @delay.prepare_to_enable: Time between prepare and enable. - * - * The minimum time, in milliseconds, that needs to have passed - * between when prepare finished and enable may begin. If at - * enable time less time has passed since prepare finished, - * the driver waits for the remaining time. - * - * If a fixed enable delay is also specified, we'll start - * counting before delaying for the fixed delay. - * - * If a fixed prepare delay is also specified, we won't start - * counting until after the fixed delay. We can't overlap this - * fixed delay with the min time because the fixed delay - * doesn't happen at the end of the function if a HPD GPIO was - * specified. - * - * In other words: - * prepare() - * ... - * // do fixed prepare delay - * // wait for HPD GPIO if applicable - * // start counting for prepare_to_enable - * - * enable() - * // do fixed enable delay - * // enforce prepare_to_enable min time - */ - unsigned int prepare_to_enable; - - /** - * @delay.enable: Time for the panel to display a valid frame. - * - * The time (in milliseconds) that it takes for the panel to - * display the first valid frame after starting to receive - * video data. - */ - unsigned int enable; - - /** - * @delay.disable: Time for the panel to turn the display off. - * - * The time (in milliseconds) that it takes for the panel to - * turn the display off (no content is visible). - */ - unsigned int disable; - - /** - * @delay.unprepare: Time to power down completely. - * - * The time (in milliseconds) that it takes for the panel - * to power itself down completely. - * - * This time is used to prevent a future "prepare" from - * starting until at least this many milliseconds has passed. - * If at prepare time less time has passed since unprepare - * finished, the driver waits for the remaining time. - */ - unsigned int unprepare; - } delay; + struct panel_delay delay; /** @bus_format: See MEDIA_BUS_FMT_... defines. */ u32 bus_format;