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.5 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,URIBL_BLOCKED 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 D7FB7C432BE for ; Mon, 9 Aug 2021 22:18:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFE4B60C41 for ; Mon, 9 Aug 2021 22:18:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236639AbhHIWSk (ORCPT ); Mon, 9 Aug 2021 18:18:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232854AbhHIWSj (ORCPT ); Mon, 9 Aug 2021 18:18:39 -0400 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FDD0C0613D3 for ; Mon, 9 Aug 2021 15:18:18 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id y9so3578949qtv.7 for ; Mon, 09 Aug 2021 15:18:18 -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=1kSuSdOzpn2BC3hOOiKLl3g0gaz4argQkrrvlL062JE=; b=kr9pYlMuV9ECH5XIXkt+0asDJ+giRnj4+5OSL6oQgpR/pvLqhUJJIA7vco8MDpekpg JNiiBamDLModZJ3liyKJ5Z/cSkx8a67P7K7Q12+71TEeSlCraUlj5CKRm4h3KFF7i360 35Eu0UmQtpvg4y7StN2DunBOonRSZiHz90auk= 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=1kSuSdOzpn2BC3hOOiKLl3g0gaz4argQkrrvlL062JE=; b=lyAg7WTvvtbbT+15Cvm0ZUT0JScr5uEzZUMFaQ4TETwl0+vPReBNZORFwCUWJs6+y4 P+gmVKHRr82hp9uaugWbZaRLVCcPbZ9qi1bV22CqUiAQHk9Q0zjkYdoDb7lppMuYZ58U xfmuI64bRKPbGUIfk4naH2Vd+XCrIX+2imcdIHDEVKGs30AEWxTrcGmstqdzoUqyvp2E RlkEcoC7QxAgeKBMu7Iz+zozrsJmCRKTxb/oJovSmlPagL7Hq0pKolPwj5QkgO8YzJKZ msvxOSchgSvJ+HFAecWBQDAezCjaHM/NqYOcIyuq9Pmta/tZed/GoV3BWeKCYOi1l8QY YV9Q== X-Gm-Message-State: AOAM5302io1687z9yoF5MYpekkAmqVl5uRTgPW0/3zhW1OS0oiM3LkJT psfl1lz47KHWhg1Uk2i2WTbwqXcRxSKEqQ== X-Google-Smtp-Source: ABdhPJzbkteuRSFMZPEFkixf1eCctS2YURgXiyfLYjPeiQtRR34SpBFHWP9SZ9Civz56RNJ9E49Inw== X-Received: by 2002:ac8:760a:: with SMTP id t10mr22429088qtq.174.1628547497473; Mon, 09 Aug 2021 15:18:17 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id p19sm6985165qtk.75.2021.08.09.15.18.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Aug 2021 15:18:15 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id m193so32439189ybf.9 for ; Mon, 09 Aug 2021 15:18:15 -0700 (PDT) X-Received: by 2002:a25:b845:: with SMTP id b5mr33593609ybm.343.1628547495182; Mon, 09 Aug 2021 15:18:15 -0700 (PDT) MIME-Version: 1.0 References: <20210730212625.3071831-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Mon, 9 Aug 2021 15:18:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/6] eDP: Support probing eDP panels dynamically instead of hardcoding To: Sam Ravnborg Cc: Thierry Reding , Rob Herring , Thomas Zimmermann , Daniel Vetter , dri-devel , linux-arm-msm , Maarten Lankhorst , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , David Airlie , Bjorn Andersson , Maxime Ripard , Steev Klimaszewski , Linus W , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Aug 3, 2021 at 1:41 PM Sam Ravnborg wrote: > > Hi Douglas, > > On Fri, Jul 30, 2021 at 02:26:19PM -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. > > Have you considered a new driver for edp panels? > panel-edp.c? > > There will be some duplicate code from pnale-simple - but the same can > be said by the other panel drivers too. > In the end I think it is better to separate them so we end up with two > less complex panel drivers rather than one do-it-all panel driver. > > I have not looked in detail how this would look like, but my first > impression is that we should split it out. I certainly could, but my argument against it is that really it's the exact same set of eDP panels that would be supported by both drivers. By definition the "simple" eDP panels are the ones that just have a regulator/enable GPIO and some timings to turn them off. Those are the exact same set of panels that can be probed if we just provide the panel ID that's hardcoded in the EDID. As you can see from the implementation patch I'm actually sharing the private data structures (the ones containing the timing) for panels that are supported both as "probable" and as hardcoded. If we split into two drivers we'd either need to duplicate the timings for all panels supported by both drivers or we'd have to somehow export them (maybe hard if things are in modules). Also, since it's the same set of eDP panels we'd need to exactly duplicate all the code handling delays / HPD. It just doesn't feel right to me. -Doug