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=-6.0 required=3.0 tests=BAYES_00,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 354B3C433E1 for ; Mon, 29 Mar 2021 16:08:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01AE66198A for ; Mon, 29 Mar 2021 16:08:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229557AbhC2QHx (ORCPT ); Mon, 29 Mar 2021 12:07:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229910AbhC2QHV (ORCPT ); Mon, 29 Mar 2021 12:07:21 -0400 Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F5E6C061574 for ; Mon, 29 Mar 2021 09:07:20 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id y18so12858086qky.11 for ; Mon, 29 Mar 2021 09:07:20 -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=h2tJ34SW4jrHJri6gw67H0wvGraWyIt4USuLVf0C2eM=; b=GC462xaBMRhJ2Eg7lkA6WeeOnHsYjJbAp7YGB3uHNWWsUKUWq0+/KNHc6unUex7fOZ OyjUJ86cSqxt7XZpVIceOdbPGydX1JHY2Wo3UptaJvygqAWzsXDJwjju3fXAElFrutDI HIyemZPRzo1F6TDoJ53UFlWlq4YWUTEmyu6hI= 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=h2tJ34SW4jrHJri6gw67H0wvGraWyIt4USuLVf0C2eM=; b=Ma+7nFlmCtpHgBMKD04xMCe5ompnS4vyy5Nx0n3AhDp01g/KdBFZ+GzrxDXx6jIF7D L/mcpu9HCWxd7JIkq7i+IX9svsfcBbqf8ALlgG+kvtPUy9klgA7wzQCkX/nOkgwTcB1h gkJK4Si99W9jtXLqedDvapobogowxC5d1YbDO3SaODNxXqKf7AhF24oMscLw5E4FCTV/ kT10Sxa3DLKzELOyBUBjFCNpgedEVNYyz+KiVcSa981VDOOXTssu1LT8y+OHMZv8aL2i +KFlae3PKz1K23dMgwkE8MzqARbmTK9oPB/6RiBUbvnn1MDc8e7ntsTCVzZ1zC/ug7U2 2Ilg== X-Gm-Message-State: AOAM533sohxFHaPfeQZOjm0uFl7JfuCOYvxH17NrsKtF/WXrA+7Mx5Rd S+cnx5KRNnyLVS5UgsNCgL6T+9/6I8p+dA== X-Google-Smtp-Source: ABdhPJy5dPjUqeQ3ujkOgss5S/HrUvNN8QrJb+1Xn+Mk/Wde6cQRW4axRlNEmkjiWyQ+rX3W81Ektw== X-Received: by 2002:a05:620a:954:: with SMTP id w20mr26729381qkw.57.1617034039484; Mon, 29 Mar 2021 09:07:19 -0700 (PDT) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id b21sm13291512qkl.14.2021.03.29.09.07.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Mar 2021 09:07:18 -0700 (PDT) Received: by mail-yb1-f171.google.com with SMTP id i144so14312917ybg.1 for ; Mon, 29 Mar 2021 09:07:18 -0700 (PDT) X-Received: by 2002:a25:69c1:: with SMTP id e184mr39188232ybc.345.1617034038260; Mon, 29 Mar 2021 09:07:18 -0700 (PDT) MIME-Version: 1.0 References: <20210316140707.RFC.1.I3a21995726282f1e9fcb70da5eb96f19ed96634f@changeid> In-Reply-To: From: Doug Anderson Date: Mon, 29 Mar 2021 09:07:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom To: Thierry Reding Cc: Rob Clark , Matthias Kaehlcke , Rob Clark , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Nicolas Boichat , David Airlie , linux-arm-msm , Andy Gross , dri-devel , Bjorn Andersson , Rob Herring , Steev Klimaszewski , Stephen Boyd , Sam Ravnborg , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote: > > The point remains that unless we describe exactly which panel we're > dealing with, we ultimately have no way of properly quirking anything if > we ever have to. Just to clarify here: with my initial proposal we actually could still quirk things if we had to. If the quirk needed to be applied before power on we'd just have to apply the quirk to the whole board (which we'd have to do anyway). After the panel was powered on then we could read the EDID and apply a quirk based on what the EDID tells us, right? > Also, once we allow this kind of wildcard we can > suddenly get into a situation where people might want to reuse this on > something that's not at all a google-pompom board because the same > particular power sequence happens to work on on some other board. That's a legit concern. Of course, people could already do that with existing panels right? One would also hope that if they reused this they also used the "more specific to least specific" rule, so someone could reuse (without any problems) with: compatible = "some-other-company,some-other-board-panel", "google,pompom-panel" That doesn't seem like it would be terrible. > Similarly I can imagine a situation where we could now have the same > panel supported by multiple different wildcard compatible strings. How > is that supposed to be any cleaner than what we have now? I'm tempted to call this (same panel supported by multiple different compatible strings) a feature, actually. Specifically: Even if the exact same hardware is shipped with more than one board, it may have a different EDID programmed into it. From what I've seen the timings used on a panel may need to be adjusted based on the SoC used (and what clock rates it can provide / features of the underlying display driver), EMI concerns, and power consumption concerns. Once a different EDID is programmed in it then it sorta becomes a "different" panel, right? I think sometimes (?) panel vendors assign a slightly different model number per board, but I'm not sure. -Doug