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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2921C433FE for ; Fri, 8 Apr 2022 12:13:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232975AbiDHMP5 (ORCPT ); Fri, 8 Apr 2022 08:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231808AbiDHMP5 (ORCPT ); Fri, 8 Apr 2022 08:15:57 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2D17140DD7 for ; Fri, 8 Apr 2022 05:13:49 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id t207so3190870qke.2 for ; Fri, 08 Apr 2022 05:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Arewm4aQpx1cT2q4dPKQ3HPLjp07y7cA6oxjb8oJlW8=; b=VKgfA8yrFSFOJIddQ/PpANf1sfzrMGxijHDMvjVQx4hjCnWb9Ld4jB4oBtszl+ppQT QYqjR2pAjQju6o1gswuZmtFffh2m4gDg/g16gDI+t1OhuEOIvoR9X4CvOMXB03B1FASM UtA6slUL9gNiySX82qtdqEwk9fNSNbOwmJeHY+IH3ONgTmjvpefoY4AlpYQ8VbmzYTgz pRB/MDy1V90CpF9Xeqjio2ZJF3pCZizbOj1GV7RevgZeGXOMK5u8QiV4UT+lFefIaOEf 6MEnDSJ3e8W26O2U3AmmuG7Kwb65WaDd9Qx2NiLTzNuzfk9Q4I9LOyONhNZ3T+hXIP+z xpEg== 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=Arewm4aQpx1cT2q4dPKQ3HPLjp07y7cA6oxjb8oJlW8=; b=rJHgTgKtV8UAgqQg+6hex8eFzigBxUC+zgSRzU9Oc4ik9nOBEQoJZT2vDQoOL850AP wzm59d6f7cRiifSZC4GsJ/qefoTq38oV9+2fYVcOswkiMVkwlKwJjEhBarBgP1FL9uie 9O0gsJOv50haDZJUbgwLcDh+5Bo5xPGgESEKLTRwzZXzyMiZEGG/7Bzaepww1xZUrlKh WMbX9pCCET4ZCrozmTuqTK6YuF37PetKc0mQPBPfORHtlLNRv9VwBjLgjO+z7aWekXj4 SR6K76x6khcSi5vn17kNLRNoPL1IMpwFVQEy0RtsFXeMaQR9KNMsjUyjMqvTFZx+aWZY dF6A== X-Gm-Message-State: AOAM533G9mBJyLB0iq9zlGXZ1gKCA7OJHW1ysyK8ZSFms+9EZcBqajDE 0Q9CbPsd/fzZEE1JqNJUkhm/3rG0GRb5qoQ2spVlnQ== X-Google-Smtp-Source: ABdhPJy5P9+4bfSCbB1onvnvwIp8rhXMjt0EzyPw6aJVpgHebQZIks1AUDZz/i0HFQXxvuXWYClnpcoYSSCUg+3xJqA= X-Received: by 2002:a05:620a:28c7:b0:67d:6d4e:16ee with SMTP id l7-20020a05620a28c700b0067d6d4e16eemr12338727qkp.59.1649420028771; Fri, 08 Apr 2022 05:13:48 -0700 (PDT) MIME-Version: 1.0 References: <1648656179-10347-1-git-send-email-quic_sbillaka@quicinc.com> <1648656179-10347-2-git-send-email-quic_sbillaka@quicinc.com> <392b933f-760c-3c81-1040-c514045df3da@linaro.org> <3e5fa57f-d636-879a-b98f-77323d07c156@linaro.org> In-Reply-To: From: Dmitry Baryshkov Date: Fri, 8 Apr 2022 15:13:38 +0300 Message-ID: Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus To: Doug Anderson Cc: Abhinav Kumar , "Sankeerth Billakanti (QUIC)" , quic_kalyant , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , quic_vproddut , David Airlie , linux-arm-msm , "Kuogee Hsieh (QUIC)" , freedreno , dri-devel , "bjorn.andersson@linaro.org" , Sean Paul , "Aravind Venkateswaran (QUIC)" , Stephen Boyd , Sean Paul , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, 8 Apr 2022 at 03:28, Doug Anderson wrote: > > Hi, > > On Thu, Apr 7, 2022 at 4:36 PM Dmitry Baryshkov > wrote: > > > > The ps8640 driver looks 'working by coincidence'. It calls > > dp_aux_populate, then immediately after the function returns it checks > > for the panel. If panel-edp is built as a module, the probe might fail > > easily. > > The anx7625 driver has the same kind of issue. The DP AUX bus is > > populated from the probe() and after some additional work the panel is > > being checked. > > This design is fragile and from my quick glance it can break (or be > > broken) too easy. It reminds me of our drm msm 'probe' loops > > preventing the device to boot completely if the dsi bridge/panel could > > not be probed in time. > > I did spend some time thinking about this, at least for ps8640. I > believe that as long as the panel's probe isn't asynchronous. By panel probe (as a probe of any device) is potentially asynchronous. As in your example, the PWM might not be present, the regulator probe might have been delayed, the panel-edp might be built as a module, which is not present for some reason. > Basically if the panel isn't ready then ps8640 should return and we'll > retry later. I do remember the probe loops that we used to have with > msm and I don't _think_ this would trigger it. I don't have proof here. But as I wrote, this thing might break at some point. > That being said, if we need to separate out the AUX bus into a > sub-device like we did in sn65dsi86 we certainly could. Ideally we should separate the "bridge" subdevice, like it was done in sn65dsi86. So that the aux host probes, registers the EP device, then the bridge device can not be probed (and thus the drm_bridge is not created) until the next bridge becomes available. -- With best wishes Dmitry