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 7FEFEC433EF for ; Fri, 8 Apr 2022 12:13:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231392AbiDHMP5 (ORCPT ); Fri, 8 Apr 2022 08:15:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229471AbiDHMP4 (ORCPT ); Fri, 8 Apr 2022 08:15:56 -0400 Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0547140DD4 for ; Fri, 8 Apr 2022 05:13:49 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id s4so4584974qkh.0 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=DR+5Mm5sQfuwePIkkNTVppAt6xyiF78bCwY0EH7R30BSeywT8t7cV6R/XzoYKLNngB Xn5GSj6jDJ4wjagOcrb0+TUYFezOBMNQujwAqlNMMg9DLzSG5lOpfiT4TMndg3UgBiqn buXT7G9PaivQuG6pbD3Gy6phKxs2DdoGFPa9wBpw9/dAaN0shLy0+jANl/iNho2zw0Eh 2GogRdlRlmQseJ5ctfKj7er/HpFI2X2i015M8y0BD1kKPHOeiy+4PO6jqkUzBiNlJ3I+ hTQ7y+6DNwfqEs92Ko81Kz9XKpclFdiVbwfAablmJ9pWVriAzPc3tGAMosMaU8qKvQs8 lgXg== X-Gm-Message-State: AOAM531xxn2h/GE0wB0YLr2Rr2aBVaI10AxZnNtv9rfkzD+N4dwp8dFq URfuyA5RQNx3EhxydZ35Ql57k2gJEwumnxKFnnqDzA== 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: linux-arm-msm@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 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6665C433EF for ; Fri, 8 Apr 2022 12:13:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 225CA10E413; Fri, 8 Apr 2022 12:13:51 +0000 (UTC) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by gabe.freedesktop.org (Postfix) with ESMTPS id A585B10E413 for ; Fri, 8 Apr 2022 12:13:49 +0000 (UTC) Received: by mail-qk1-x734.google.com with SMTP id j6so4585152qkp.9 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=6RXVnCn+tE8w/bq9mv61caAj0QBnP1rWkTEVOh3wxhyCUq9wQ57JPKZSD0wWdlNllz 3qSpP/mu2f0i52a0qTjtKoIdJeBsbuDCqw2aR5lRkntC8wEHVSuAbAM+DMW4R0KNM9ih ssFMUwUhZEJSqaQobEALf9U5u/EMBIY0s0KdTNxa8UjfmhRutP35l//BJlQPeVtGn2Fl QGXlrtRLVPhEPuKUde6qcZDGb4JDpPqk0ZapsrVTOP6Q3XOqs598GraZLHpFTDY3weOP D6rwES9yB3yO/YGiiHMdn4d4MoTlpAjfvST669fdpufsaOi1o7rWp1LHL225E8KAPQYm rQDA== X-Gm-Message-State: AOAM531jJEv/KGwRGJal5ryo1YZFz9BBPP0qUsHLXCi0rgQtabPoN4jC txnLd7HSveJ2df0TiGomm0hvz7yNY814rYaKPxxtzg== 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 Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: quic_kalyant , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "Sankeerth Billakanti \(QUIC\)" , quic_vproddut , David Airlie , linux-arm-msm , Stephen Boyd , Abhinav Kumar , dri-devel , "Kuogee Hsieh \(QUIC\)" , Sean Paul , Sean Paul , "Aravind Venkateswaran \(QUIC\)" , "bjorn.andersson@linaro.org" , freedreno , LKML Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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