Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp44551lfe; Fri, 15 Apr 2022 18:38:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8s2RQffdhBpzyOts6PTXopyKhEXP9qEuAvZA8kDef11rJ2EesUB9uznks+aB7LAQrVcvr X-Received: by 2002:a05:6a00:1a90:b0:4fa:9400:afaf with SMTP id e16-20020a056a001a9000b004fa9400afafmr1545465pfv.82.1650073082302; Fri, 15 Apr 2022 18:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650073082; cv=none; d=google.com; s=arc-20160816; b=HD4c0omTcFdhlKtcGr4ScmDsSyQ33rizBC+GqR0c8XXuho/sLg+xWX2lpQWIzaoxTR Q1cp9MjfDJu2K/OtIspAPAxK/xyk5bztzEPNoSTg2tLJRldRqdtXyP9d+1UbtQBML5BK cIYLFEbHm2xwUgChZCHaQuSOxFhhXodvKB73+OPe0NIxkDLtGRDywr7ZxvO4H3GqH6Dr VXBDdj26emAtiorBFMAGSUa3NyG6R/FSrAmtvNZMMyRF1ktuafF8nih19fO5D20AYMii RJs2OHr/10pv1ELDlffNBjIFW92XWAHQqksyDbdJ8/zkNwpWD54zOU1eH/Pmz78htN/j XK9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IWv2Ppbp50uTzsTbYA0OggS+HfcMIlPvUJ7mUKY3HEI=; b=dscMt2EiaiSA1sWz6LLRd90hOyYNUHueY0WhK/T27oi2ZLOxibM0mjlcJHnpXQ2jX8 W2Z1/admISNsC7st8CLLKOvxSdQyxBCqJfvMhE312CRLO/9G/0ybjrBktGYJLu8cduAG 3HKC1n3IooQthklFvBznZRsB45fFmgiJBqhbnI066tyQlpi7zkPm7QJxwcvy1dC7br2Y FgJdBBhEHR+IOTR/Et1IPgmz/AMvgqFWC1UmMjGIBBRFE7ghUbksQ8YP9f4LBAQgMA5n FtVFm+pQQgERkpdDoFwIfnAHtDYuD/H08zdFnow2Uvc9aU9jw1wCzYC51c+PzxHayNLp fxFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jpVPYefQ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id j5-20020a056a00174500b004fa3a8dff8esi3032953pfc.69.2022.04.15.18.38.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:38:02 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jpVPYefQ; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8BFB7ED9D9; Fri, 15 Apr 2022 18:03:56 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237250AbiDNVyA (ORCPT + 99 others); Thu, 14 Apr 2022 17:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236602AbiDNVx4 (ORCPT ); Thu, 14 Apr 2022 17:53:56 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BBCB31DCD for ; Thu, 14 Apr 2022 14:51:30 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id k23so12491423ejd.3 for ; Thu, 14 Apr 2022 14:51:30 -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=IWv2Ppbp50uTzsTbYA0OggS+HfcMIlPvUJ7mUKY3HEI=; b=jpVPYefQu+vId/3f5egszIn+HK5nNmft6hktSoVVoMwB7NsgD6J+XSQn5+0NH/VWpy VXjCbtOuADG+DrniheywOPAuqHUYmIbMlmpQM4SZTG2ymrScPAO9N3TVG4g4LXgCf37m 1z3OH2jWXmMbPBBx9Yi2sjclyIwaE72EoZKY4= 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=IWv2Ppbp50uTzsTbYA0OggS+HfcMIlPvUJ7mUKY3HEI=; b=Ep4dlBP6FC3O8nQst4fiEPazFtQ2EcP/XiDt3rmiSEuTMRpjQlAuL4Sr8FFIH2w6k0 gKQ4qoKpzOCDqbwVw2kQI7TPEFbH8O8cQ/jui5SSp2ZrW/Bbcc8aexS/RRXS4QXYIgY2 hUjL3se29/cLLdgSpKpDugbnFDnZ5pbdw6vMC8xbeNtUqc6OsPwHKL1zmhfDEhdoHjcl ewkzoih6oqLHCZxlxGFoiemORntKCBSbKXGMGNnR2DsmqXtey79fzSH3umnJmP5yaOLO JgQW4lq+IStHtUOxkP/8ENn9Ag5gyFFpw5qANztwNrjkLWzECjnWpogjy0NwVfUQMgk0 LcVQ== X-Gm-Message-State: AOAM530t1zoZgtCFeNVfT4iR6H8A+QtkGEqeyS3N5HShduz24HPClYOB X+YqEsiZdcvRbH1SANgQv2KC7FckDb79HaKHLRw= X-Received: by 2002:a17:906:2991:b0:6cf:1fd4:39a3 with SMTP id x17-20020a170906299100b006cf1fd439a3mr4049318eje.21.1649973088875; Thu, 14 Apr 2022 14:51:28 -0700 (PDT) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com. [209.85.128.51]) by smtp.gmail.com with ESMTPSA id b12-20020a17090630cc00b006dfdfe15cf8sm1040691ejb.196.2022.04.14.14.51.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Apr 2022 14:51:28 -0700 (PDT) Received: by mail-wm1-f51.google.com with SMTP id 123-20020a1c1981000000b0038b3616a71aso4044556wmz.4 for ; Thu, 14 Apr 2022 14:51:28 -0700 (PDT) X-Received: by 2002:a05:600c:4f10:b0:38c:ae36:d305 with SMTP id l16-20020a05600c4f1000b0038cae36d305mr499148wmq.34.1649973087758; Thu, 14 Apr 2022 14:51:27 -0700 (PDT) MIME-Version: 1.0 References: <1649938766-6768-1-git-send-email-quic_sbillaka@quicinc.com> <1649938766-6768-2-git-send-email-quic_sbillaka@quicinc.com> <81c3a9fb-4c92-6969-c715-ca085322f9c6@linaro.org> <56453228-d4b2-c7e4-7b72-6de8637f2def@linaro.org> In-Reply-To: <56453228-d4b2-c7e4-7b72-6de8637f2def@linaro.org> From: Doug Anderson Date: Thu, 14 Apr 2022 14:51:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 1/4] drm/msm/dp: Add eDP support via aux_bus To: Dmitry Baryshkov Cc: Stephen Boyd , Sankeerth Billakanti , dri-devel , linux-arm-msm , freedreno , LKML , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Rob Clark , Sean Paul , quic_kalyant , Abhinav Kumar , Kuogee Hsieh , Bjorn Andersson , Sean Paul , David Airlie , Daniel Vetter , quic_vproddut , Aravind Venkateswaran , Steev Klimaszewski Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Apr 14, 2022 at 2:16 PM Dmitry Baryshkov wrote: > > > Hmm, interesting. Probably for DRM_BRIDGE_OP_MODES that will work? > > It's definitely worth confirming but from my reading of the code it > > _probably_ wouldn't hurt. > > > > One thing someone would want to confirm would be what would happen if > > we move this code and the panel code to implement DRM_BRIDGE_OP_EDID > > properly. It looks as if both actually ought to be implementing that > > instead of DRM_BRIDGE_OP_MODES, at least in some cases. A fix for a > > future day. Could we get into trouble if one moved before the other? > > Then the panel would no longer override the eDP controller and the eDP > > controller would try to read from a possibly unpowered panel? > > That would depend on the way the get_edid would be implemented in DP > driver. Currently the edid is cached via the > dp_display_process_hpd_high() -> dp_panel_read_sink_caps() call chain. > > With this patchset, the dp_hpd_plug_handle() -> > dp_display_usbpd_configure_cb() -> dp_display_process_hpd_high() will be > called too late for the get_modes/get_edid (from dp_bridge's enable() op). > > There is another issue. drm_panel has only get_modes() callback, so > panel_bridge can not implement get_edid() unless we extend the panel > interface (which might be a good idea). Ah, that makes sense and explains why the current panel code does the EDID reading in its get_modes() function even though get_modes() is _documented_ that it doesn't read the EDID. ;-) I guess it's another of the "let's move some people over to the new way but we'll keep the old code working". Definitely makes it hard to understand at times. > > For hotplug/detect I'm even less confident that setting the bits would > > be harmless. I haven't sat down and traced everything, but from what I > > can see the panel _doesn't_ set these bits, does it? I believe that > > the rule is that when every bridge in the chain _doesn't_ implement > > detect/hotplug that the panel is always present. The moment someone > > says "hey, I can detect" then it suddenly becomes _not_ always > > present. Yes, I guess we could have the panel implement "detect" and > > return true, but I'm not convinced that's actually better... > > I think it makes sense to implement OP_DETECT in panel bridge (that > always returns connector_status_connected) at least to override the > possible detect ops in previous bridges. So I truly don't know the right answer, but are you sure that's the best design? I _think_ that panel_bridge is used for all kinds of panels, right? So what if there's some type of display that uses a panel but there's still a mechanism that supports physical detection of the panel? By implementing "detect" in the generic panel_bridge then you're _preventing_ anyone higher up in the chain from implementing it and you're forcing it to be "always connected". For instance, we could come up with a new display standard called "pluggable eDP" that is just like eDP except that you can physically detect it. This imaginary new display standard is different from DP because it has eDP power sequencing (fully powers the display off when the screen is off) but it's hot pluggable! It introduces a new pin that goes to the DP controller called RT-HPD for "really, truly hot plug detect" that works even when the panel is off. The existing "HPD" pin continues to mean that the panel is read to communicate. If the drm_panel hardcodes "always connected" then I can't implement my "pluggable eDP" system, right? However, if we leave it just like it is today then my new system would be easy to implement. ;-) The above example is obviously not truly a real one but I guess my point is that I find it more intuitive / useful to say that we should only implement "detect" if we truly think we can detect and that if nobody says they can detect then we must be always connected. As an aside; I think in general it's not always easy to fit every possible graphics system into these "bridge chains" and the simple sequence of pre-enable, enable, etc, so we have to do our best and accept the fact that sometimes we'll need special cases. Dave Stephenson's patches [1] should tell us that, at least. [1] https://lore.kernel.org/all/cover.1646406653.git.dave.stevenson@raspberrypi.com/ -Doug