From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99A0F3FC1 for ; Thu, 2 Sep 2021 22:41:25 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id j18so4558927ioj.8 for ; Thu, 02 Sep 2021 15:41:25 -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=vEOAhsHQM9G+tVvC78A/rhgecetN4byQdhrLLpo0P0g=; b=LDmJnOglDM6SRfrqk879nlvltfZEhwju/ts9Exu/2rE0XB+Lj74aGi7ZCLry1NSj0f btPQfuDa+Q2ntfjL+zK+k6leKrLg6ahv0/pjTn7Y3JJbbdq5v55q2XUGEdXr0VDSURWz zo/R1rY1OagPqlvLvu4Emr9cTHgcwBCjlU/VE= 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=vEOAhsHQM9G+tVvC78A/rhgecetN4byQdhrLLpo0P0g=; b=hgd7omjaqIRumSjs5DJTKoTcmylhEbXmpBoyXRKxGJ9b8gg8cMuinyVPAr7ORx3yko sIQOviHuw9p3c0aP+Wug/gkXlY6KRTzV2BAK4hwckXhKQ+2tpeS+b4BSha+rXXfNYOge khqRxrHe1f9lv5HABeZwrPU4TgVmo4L8Ve3NIWLQki/652rk3Re4+1J6Fb32eTAbyuII e6WRlpEypctm8tpVv9Q07Qp+2uzMS24dbiifsV0C9b3HCLGBEwnt0psA1Zi1KnzlCDOF p3Rvh1h1TUt28R3xyJWwaaZ9ZJyOUQ4zpibG74nbKkshxtgN6NKmXErypKulGl9YhtrS u/ig== X-Gm-Message-State: AOAM5322amT02VfQ8SiAaPzOSlNFMGLdPLxP5ljVCJe+uXv5WJYTJ3NM ONNhvwucMIxTTKndn+/RCgMwUwjoDiAIdg== X-Google-Smtp-Source: ABdhPJxlyA23dzRZjWyQt0Q//UiQr+ayZ4i9skmHWDASLYfXkA3XDZqhhqRHVAe2VgQC4KNwezZr9g== X-Received: by 2002:a5e:da01:: with SMTP id x1mr9288ioj.43.1630622484611; Thu, 02 Sep 2021 15:41:24 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id u10sm1662846ilg.15.2021.09.02.15.41.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Sep 2021 15:41:24 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id f6so4621813iox.0 for ; Thu, 02 Sep 2021 15:41:24 -0700 (PDT) X-Received: by 2002:a92:cf4a:: with SMTP id c10mr329106ilr.269.1630621999435; Thu, 02 Sep 2021 15:33:19 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210901201934.1084250-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Thu, 2 Sep 2021 15:33:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding To: Andrzej Hajda Cc: Thierry Reding , Rob Herring , Sam Ravnborg , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Maxime Ripard , dri-devel , NXP Linux Team , 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" Hi, On Thu, Sep 2, 2021 at 3:10 PM Andrzej Hajda wrote: > > Removed most CC: SMTP server protested. Yeah, it was because of the dang defconfig patches. My general policy is to send the cover letter to everyone even if not everyone gets CCed on all patches, but it ended up as a lot... Speaking of which, I'd definitely be interested in your take on the defconfig topic: https://lore.kernel.org/r/CAD=FV=WPXAUyuAHb1jKx9F_aw+JGX4MWB3or=Eq5rXoKY=OQMw@mail.gmail.com Do you agree with Olof that I should set the "default" for the new config to be the same as the old config? It doesn't make sense going forward but it helps for anyone with old configs... > On 01.09.2021 22:19, 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/ > > > I like the idea - if something can be configured dynamically lets do it. > But I have few questions: > 1. Have you read different real panels id's? In many cases (MIPI DSI, > LVDS with EDID) manufacturers often forgot to set proper id fields. I do > not know how EDID's ids are reliable in case of edp panels. I have read several and (so far) they have been quite reliable but I will admit that I haven't done an exhaustive sample. I guess my answer to whether we can trust it is: a) Presumably you'd only use this new "edp-panel" compatible on systems whose panel IDs are known to be reliable. Old systems can keep determining the panel by compatible string. The two schemes can co-exist. b) As we start using this new scheme then there will be more validation of panel ID strings and, presumably, they will become more reliable. It is still true that ID conflicts could exist. A vendor could ship two different panels with the same ID and maybe nobody would notice because they weren't ever hooked up to the same board. In that case we'd have a question of what to do upstream. If this really happens then I suppose (worst case) we could use the device tree to help differentiate and each board could say that "panel ID hooked up to this board is actually panel ". I hope we don't have to do that because it feels dirty, but at least it gives us _something_ if we get backed into a corner. > 2. You are working with edp panels - beside EDID they have DPCD which > contains things like IEEE_OUI and "Device Identification String", I > guess they could be also used for detecting panels, have you considered > it? I think DPCD Id should be assigned to EDP-Sink interface, and EDID > Id to the actual panel behind it. With this assumption one could > consider which timings should be property of which entity. This could be another way to help us if we're backed into a corner in the future. Right now the driver requires that you give access to a full eDP AUX bus to use the "generic eDP" panel support even though it currently only relies on the EDID, so it would be pretty easy to utilize this info in the future. So far the ID has been reliable for me though. -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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 1ED16C433EF for ; Thu, 2 Sep 2021 22:35:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 E13F661041 for ; Thu, 2 Sep 2021 22:35:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E13F661041 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G7/SX+VekIkfT+Xm2xPoBumAMDqnltqP/oLiRoiiyog=; b=DJK1BAtBNfCggT OF6lUGaShjoCfI5IHXSm8rxqnhNRRA/uTvlUtF3bVXlGDEE6ZfFil4CR33eoBjVQc96Mti+SlIl4h WFM/QrxLrLiJPYWHDcZRgraBMv0Ve+Yq8BtXRLDMWMcV7sBfnKSuwY4iEPFDOXR+YRIsrCih2pB0L WGZOJ1+r1yXg205GjeFo1fv3zDhc2bC5B7j7HSgv53uFbMlID3rXoSqPeVxfIGiGKXmV9w3Tlm9Zg or+9onoYE0VUtJJDgRaG6XKQ8Eiau2O7VBq/E2p4WeQLWv4VrntyPnAnyf++t94e1vAfibqNtabej w6l3iCEscN7rZT9pLJig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mLvGx-00AdBi-U5; Thu, 02 Sep 2021 22:33:28 +0000 Received: from mail-il1-x12f.google.com ([2607:f8b0:4864:20::12f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mLvGt-00AdAm-DW for linux-arm-kernel@lists.infradead.org; Thu, 02 Sep 2021 22:33:25 +0000 Received: by mail-il1-x12f.google.com with SMTP id j15so3441542ila.1 for ; Thu, 02 Sep 2021 15:33:21 -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=vEOAhsHQM9G+tVvC78A/rhgecetN4byQdhrLLpo0P0g=; b=LDmJnOglDM6SRfrqk879nlvltfZEhwju/ts9Exu/2rE0XB+Lj74aGi7ZCLry1NSj0f btPQfuDa+Q2ntfjL+zK+k6leKrLg6ahv0/pjTn7Y3JJbbdq5v55q2XUGEdXr0VDSURWz zo/R1rY1OagPqlvLvu4Emr9cTHgcwBCjlU/VE= 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=vEOAhsHQM9G+tVvC78A/rhgecetN4byQdhrLLpo0P0g=; b=m8xB8k/HoIK8JZExyr7UJp/y5K5WNsjcwbhdUPXGXWP+Bi6ZFw5SsGdVCZdnX0Cm6d 9IvQw1fExRdvURvLVELeg6lH2+OhruReVQfSYGyZUIXOPEzWu2HFy2ASyIOb1WOjcFFG Dwme4A7WTOaCgY13OMH1IWtAaxl/R7Dm2kpvXSJm3KcFQfPNMhC+jAYzi2DvyB8L/Syn QyO3pMnvbRJS/H9wpqWBD/nPedsertnyaSQE1hUYOzIock9MABZjtbqGfUr+vts15DuM GdJY9zvdtua1E9j6S7M7Xj0MhcL1BxrUd5TLu+V+s8AjjHpvYetT/CE4ucqEfggMARb1 07FQ== X-Gm-Message-State: AOAM533CGQUE9JAKo2rubuclJ4gRIuLYpayDb5wqdnYrXbOxOBMRHqJf zH4d7K0ymwiQ3pt1i5B8EXuDvuNXc/Np9Q== X-Google-Smtp-Source: ABdhPJy2AIS1huzYsFP8Qkeqmjr0WFrGYGYyvcrseeBibobb2DfO0KtglEOufgvJpJKNwh0ekI7dyQ== X-Received: by 2002:a05:6e02:108:: with SMTP id t8mr342453ilm.216.1630622000796; Thu, 02 Sep 2021 15:33:20 -0700 (PDT) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id p19sm1613950ilj.58.2021.09.02.15.33.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Sep 2021 15:33:20 -0700 (PDT) Received: by mail-il1-f177.google.com with SMTP id i13so3432174ilm.4 for ; Thu, 02 Sep 2021 15:33:19 -0700 (PDT) X-Received: by 2002:a92:cf4a:: with SMTP id c10mr329106ilr.269.1630621999435; Thu, 02 Sep 2021 15:33:19 -0700 (PDT) MIME-Version: 1.0 References: <20210901201934.1084250-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Thu, 2 Sep 2021 15:33:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding To: Andrzej Hajda Cc: Thierry Reding , Rob Herring , Sam Ravnborg , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Maxime Ripard , dri-devel , NXP Linux Team , 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?= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210902_153323_504965_9ABC14E5 X-CRM114-Status: GOOD ( 51.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Sep 2, 2021 at 3:10 PM Andrzej Hajda wrote: > > Removed most CC: SMTP server protested. Yeah, it was because of the dang defconfig patches. My general policy is to send the cover letter to everyone even if not everyone gets CCed on all patches, but it ended up as a lot... Speaking of which, I'd definitely be interested in your take on the defconfig topic: https://lore.kernel.org/r/CAD=FV=WPXAUyuAHb1jKx9F_aw+JGX4MWB3or=Eq5rXoKY=OQMw@mail.gmail.com Do you agree with Olof that I should set the "default" for the new config to be the same as the old config? It doesn't make sense going forward but it helps for anyone with old configs... > On 01.09.2021 22:19, 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/ > > > I like the idea - if something can be configured dynamically lets do it. > But I have few questions: > 1. Have you read different real panels id's? In many cases (MIPI DSI, > LVDS with EDID) manufacturers often forgot to set proper id fields. I do > not know how EDID's ids are reliable in case of edp panels. I have read several and (so far) they have been quite reliable but I will admit that I haven't done an exhaustive sample. I guess my answer to whether we can trust it is: a) Presumably you'd only use this new "edp-panel" compatible on systems whose panel IDs are known to be reliable. Old systems can keep determining the panel by compatible string. The two schemes can co-exist. b) As we start using this new scheme then there will be more validation of panel ID strings and, presumably, they will become more reliable. It is still true that ID conflicts could exist. A vendor could ship two different panels with the same ID and maybe nobody would notice because they weren't ever hooked up to the same board. In that case we'd have a question of what to do upstream. If this really happens then I suppose (worst case) we could use the device tree to help differentiate and each board could say that "panel ID hooked up to this board is actually panel ". I hope we don't have to do that because it feels dirty, but at least it gives us _something_ if we get backed into a corner. > 2. You are working with edp panels - beside EDID they have DPCD which > contains things like IEEE_OUI and "Device Identification String", I > guess they could be also used for detecting panels, have you considered > it? I think DPCD Id should be assigned to EDP-Sink interface, and EDID > Id to the actual panel behind it. With this assumption one could > consider which timings should be property of which entity. This could be another way to help us if we're backed into a corner in the future. Right now the driver requires that you give access to a full eDP AUX bus to use the "generic eDP" panel support even though it currently only relies on the EDID, so it would be pretty easy to utilize this info in the future. So far the ID has been reliable for me though. -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel