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=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7965FC433F5 for ; Thu, 9 Sep 2021 00:30:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5350C61158 for ; Thu, 9 Sep 2021 00:30:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235458AbhIIAbh (ORCPT ); Wed, 8 Sep 2021 20:31:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234769AbhIIAbg (ORCPT ); Wed, 8 Sep 2021 20:31:36 -0400 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4ED1C061575 for ; Wed, 8 Sep 2021 17:30:27 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id f6so143909iox.0 for ; Wed, 08 Sep 2021 17:30:27 -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=5TYYBxc50K8ZMZBZ7awprT/bOkKTiGesfrb7WFjJZ+A=; b=KCg85QMP/OVnq6/fqe2waVZlGw1gFTsTbflgSC3G8O1iDp1IJHUm3MOwpZoQjxxDR7 Atw25rhjAEpmxxhj1rRyXedydjURMxf4JnVSadGKtWgcyetFjVG75upvVHgaoqHaOe7Q i7ClThKtbyUxOILSABwytp3A6HENqxe+XgPEA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5TYYBxc50K8ZMZBZ7awprT/bOkKTiGesfrb7WFjJZ+A=; b=5RencNvEoNJyOpB8BZupW2bb2d3RU5eEvx5K9zdCwZorbLLwq05ctJAMc+l9tNCWFB 3L03PLgalpvmos2RugdLOS3ROgFoO1aBiTMfVr6TvXPDVm6CPohOm27wOcXBsBoNN7Gv VwtxP/KlMRiSIC04YpFm/sghHiORWYg8DvNI/KhXVvAWfYOyrAUfzvPyFBot1VE0OVQi 7JZnZCAhCxubz6W62GkU7YvUzeSyPd+XDCQ/WmZsxilNkdCqn/hUSmwdInFRBHgdDg1M hHXutHWbe0nXyCJUJoRY2nFL7vbrNSXI0UWpV3n5JArxyWFgaqBMbjV25voR4Lx2i4bw 2Qfw== X-Gm-Message-State: AOAM532RWEVRX+RsdtBQb4qYNZWGIvR/5FHccn5Op1U3VMYn7KFdOWNI wWE2DdNmC7KxB50lQskY4o3tTTkvRvlRlA== X-Google-Smtp-Source: ABdhPJzIEHMaLpe0KVT1TktD1QAyvF2EEcB1bM+ebcgovf9Aumpohi3KsWkFyGhr5RjcLPQcNrWO0g== X-Received: by 2002:a05:6638:cd5:: with SMTP id e21mr238423jak.97.1631147427222; Wed, 08 Sep 2021 17:30:27 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id s7sm105750ioc.42.2021.09.08.17.30.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 17:30:27 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id q3so109014iot.3 for ; Wed, 08 Sep 2021 17:30:27 -0700 (PDT) X-Received: by 2002:a05:6e02:214e:: with SMTP id d14mr150446ilv.142.1631147079713; Wed, 08 Sep 2021 17:24:39 -0700 (PDT) MIME-Version: 1.0 References: <20210901201934.1084250-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Wed, 8 Sep 2021 17:24:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding To: Sam Ravnborg Cc: Thierry Reding , Rob Herring , Maarten Lankhorst , linux-arm-msm , Bjorn Andersson , Linus W , Daniel Vetter , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Steev Klimaszewski , Thomas Zimmermann , Maxime Ripard , David Airlie , dri-devel , Al Viro , Alexandre Belloni , Alexandre Torgue , Andreas Kemnade , Andrey Zhizhikin , Anson Huang , Arnd Bergmann , Catalin Marinas , Chen-Yu Tsai , Claudiu Beznea , Codrin Ciubotariu , Corentin Labbe , Daniel Thompson , Dmitry Baryshkov , Dmitry Osipenko , Emil Velikov , Enric Balletbo i Serra , Eugen Hristev , Fabio Estevam , Fabrice Gasnier , Florian Fainelli , Geert Uytterhoeven , Grygorii Strashko , =?UTF-8?Q?Guido_G=C3=BCnther?= , Jagan Teki , Jernej Skrabec , Joel Stanley , Jonathan Hunter , Kees Cook , Krzysztof Kozlowski , Krzysztof Kozlowski , Lionel Debieve , Liviu Dudau , Lorenzo Pieralisi , Ludovic Desroches , Magnus Damm , Manivannan Sadhasivam , Marek Szyprowski , =?UTF-8?Q?Martin_J=C3=BCcker?= , Michael Walle , NXP Linux Team , Nicolas Ferre , Nishanth Menon , Olivier Moysan , Olof Johansson , Otavio Salvador , Paul Cercueil , Pengutronix Kernel Team , Razvan Stefanescu , Robert Richter , Russell King , Sascha Hauer , Shawn Guo , Stefan Wahren , Sudeep Holla , Thomas Bogendoerfer , Tony Lindgren , Tudor Ambarus , Vinod Koul , Viresh Kumar , Vladimir Zapolskiy , Will Deacon , Linux ARM , LKML , linux-mips , linux-omap , Linux-Renesas , linux-samsung-soc , linux-sunxi@lists.linux.dev, "open list:TEGRA ARCHITECTURE SUPPORT" , =?UTF-8?Q?=C5=81ukasz_Stelmach?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org Hi, On Sun, Sep 5, 2021 at 11:55 AM Sam Ravnborg wrote: > > Hi Douglas, > > On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote: > > The goal of this patch series is to move away from hardcoding exact > > eDP panels in device tree files. As discussed in the various patches > > in this series (I'm not repeating everything here), most eDP panels > > are 99% probable and we can get that last 1% by allowing two "power > > up" delays to be specified in the device tree file and then using the > > panel ID (found in the EDID) to look up additional power sequencing > > delays for the panel. > > > > This patch series is the logical contiunation of a previous patch > > series where I proposed solving this problem by adding a > > board-specific compatible string [1]. In the discussion that followed > > it sounded like people were open to something like the solution > > proposed in this new series. > > > > In version 2 I got rid of the idea that we could have a "fallback" > > compatible string that we'd use if we didn't recognize the ID in the > > EDID. This simplifies the bindings a lot and the implementation > > somewhat. As a result of not having a "fallback", though, I'm not > > confident in transitioning any existing boards over to this since > > we'll have to fallback to very conservative timings if we don't > > recognize the ID from the EDID and I can't guarantee that I've seen > > every panel that might have shipped on an existing product. The plan > > is to use "edp-panel" only on new boards or new revisions of old > > boards where we can guarantee that every EDID that ships out of the > > factory has an ID in the table. > > > > Version 3 of this series now splits out all eDP panels to their own > > driver and adds the generic eDP panel support to this new driver. I > > believe this is what Sam was looking for [2]. > > > > [1] https://lore.kernel.org/r/YFKQaXOmOwYyeqvM@google.com/ > > [2] https://lore.kernel.org/r/YRTsFNTn%2FT8fLxyB@ravnborg.org/ > > > > Changes in v3: > > - Decode hex product ID w/ same endianness as everyone else. > > - ("Reorder logicpd_type_28...") patch new for v3. > > - Split eDP panels patch new for v3. > > - Move wayward panels patch new for v3. > > - ("Non-eDP panels don't need "HPD" handling") new for v3. > > - Split the delay structure out patch just on eDP now. > > - ("Better describe eDP panel delays") new for v3. > > - Fix "prepare_to_enable" patch new for v3. > > - ("Don't re-read the EDID every time") moved to eDP only patch. > > - Generic "edp-panel" handled by the eDP panel driver now. > > - Change init order to we power at the end. > > - Adjust endianness of product ID. > > - Fallback to conservative delays if panel not recognized. > > - Add Sharp LQ116M1JW10 to table. > > - Add AUO B116XAN06.1 to table. > > - Rename delays more generically so they can be reused. > > > > Changes in v2: > > - No longer allow fallback to panel-simple. > > - Add "-ms" suffix to delays. > > - Don't support a "fallback" panel. Probed panels must be probed. > > - Not based on patch to copy "desc"--just allocate for probed panels. > > - Add "-ms" suffix to delays. > > > > Douglas Anderson (16): > > dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels > > drm/edid: Break out reading block 0 of the EDID > > drm/edid: Allow the querying/working with the panel ID from the EDID > > drm/panel-simple: Reorder logicpd_type_28 / mitsubishi_aa070mc01 > > drm/panel-simple-edp: Split eDP panels out of panel-simple > > ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP > > arm64: defconfig: Everyone who had PANEL_SIMPLE now gets > > PANEL_SIMPLE_EDP > > MIPS: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP > > drm/panel-simple-edp: Move some wayward panels to the eDP driver > > drm/panel-simple: Non-eDP panels don't need "HPD" handling > > drm/panel-simple-edp: Split the delay structure out > > drm/panel-simple-edp: Better describe eDP panel delays > > drm/panel-simple-edp: hpd_reliable shouldn't be subtraced from > > hpd_absent > > drm/panel-simple-edp: Fix "prepare_to_enable" if panel doesn't handle > > HPD > > drm/panel-simple-edp: Don't re-read the EDID every time we power off > > the panel > > drm/panel-simple-edp: Implement generic "edp-panel"s probed by EDID > > Thanks for looking into this. I really like the outcome. > We have panel-simple that now (mostly) handle simple panels, > and thus all the eDP functionality is in a separate driver. > > I have provided a few nits. > My only take on this is the naming - as we do not want to confuse > panel-simple and panel-edp I strongly suggest renaming the driver to > panel-edp. Sure, I'll do that. I was trying to express the fact that the new "panel-edp" driver won't actually handle _all_ eDP panels, only the eDP panels that are (comparatively) simpler. For instance, I'm not planning to handle panel-samsung-atna33xc20.c in "panel-edp". I guess people will figure it out, though. > And then rename the corresponding Kconfig entry. > > With these few changes all patches are: > Acked-by: Sam Ravnborg Thanks, I'll add it to the patches. If there's anything major I need to change I'll give you a yell to make sure you see it. > For bisectability I suggest to move the defconfig patches up before you > introduce the new Kconfig symbol. Or maybe they will be added via > another tree and then this is not possible to control Yup, I'll do that. There was some question about the defconfig patch but they are hopefully cleared up now. > I assume you will apply the patches yourself. Sure, I can do that with your Ack. I'll also make sure that patches that Jani commented on get resolved. -Doug