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 D2BE9C433FE for ; Thu, 7 Apr 2022 17:07:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345938AbiDGRJ4 (ORCPT ); Thu, 7 Apr 2022 13:09:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239814AbiDGRJz (ORCPT ); Thu, 7 Apr 2022 13:09:55 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C231331341 for ; Thu, 7 Apr 2022 10:07:54 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id i27so12191437ejd.9 for ; Thu, 07 Apr 2022 10:07:54 -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=m2s4PG1XXBPY+xZ/g2KKtsmSmzO1vbLqhx1OJRbwqHk=; b=VFenbI8vl9C3SVgHSCx12w6Hk5Qy6qGRxJMtZkd2lfhRJFgJjv3Do/knpuu+OWtSMY 5b2c+eLOqhqoJks1M7BXl4sXkKZN5YZgLU58Vm7j8JcNmrZlNpaJ8SjKyiX/GO4QvbYC sZXP/gmxVZ1n4Wq7vE1X70J6/KrrTVlQB0LFg= 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=m2s4PG1XXBPY+xZ/g2KKtsmSmzO1vbLqhx1OJRbwqHk=; b=6j6MbA8QqpcgtQkBQi1n6sNIY0zudNwWMdpnpzXuaAAS4R3BjU9xIzrOebaZ9MfpD6 g62b9Lel8X2hCAOKzkffGPPEAgSlTVhizO0qCdbGVxmJ8y5GUXRVLpZfQf1IAg7MuZ08 dW410diXSnbIo3bgBcNEc5QCKaHjwfteRzY1oXbYx91GiglMvboogEP6QRsJ73b/+Q1q YDIIx8BCjotk4ixwRQQdJDhY2P5Gn0fBuuETvp4aIy8XqsJnjtQHQ16f/rBtFMmQzoYk J6Vj/JF6BADQuTvxlLNDwlCAXGgKiydvmLgKfb91qbqzNJQKZS0ocKhtvFY8nefJdzmH FlyQ== X-Gm-Message-State: AOAM533pXKEXW3RSYmW1X6DcYX0Gi2LG9YqEKiYKuyOkOnINSy3IrNc7 bXWNRGVQIH4qrZr+EF1FoDGpTtfghPmaWw== X-Google-Smtp-Source: ABdhPJx4wXLz5fIDZumX5xToNrLZTC7H4+3RzLtD5tM+F0jqEb+GpSHovmzkIF1g2euviNlEFjisoA== X-Received: by 2002:a17:907:2d8d:b0:6df:a06c:7c55 with SMTP id gt13-20020a1709072d8d00b006dfa06c7c55mr14469262ejc.325.1649351273094; Thu, 07 Apr 2022 10:07:53 -0700 (PDT) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com. [209.85.128.43]) by smtp.gmail.com with ESMTPSA id m3-20020a17090679c300b006cf9ce53354sm7798799ejo.190.2022.04.07.10.07.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Apr 2022 10:07:52 -0700 (PDT) Received: by mail-wm1-f43.google.com with SMTP id p189so3979482wmp.3 for ; Thu, 07 Apr 2022 10:07:50 -0700 (PDT) X-Received: by 2002:a05:600c:4e10:b0:38e:6a6a:c06a with SMTP id b16-20020a05600c4e1000b0038e6a6ac06amr13253896wmq.15.1649351270179; Thu, 07 Apr 2022 10:07:50 -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: Doug Anderson Date: Thu, 7 Apr 2022 10:07:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus To: "Sankeerth Billakanti (QUIC)" Cc: "dmitry.baryshkov@linaro.org" , quic_kalyant , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "Abhinav Kumar (QUIC)" , quic_vproddut , David Airlie , linux-arm-msm , "bjorn.andersson@linaro.org" , LKML , dri-devel , Stephen Boyd , Sean Paul , Sean Paul , "Aravind Venkateswaran (QUIC)" , "Kuogee Hsieh (QUIC)" , freedreno Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC) wrote: > > Hi Dmitry and Doug, > > > Hi, > > > > On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov > > wrote: > > > > > > On 05/04/2022 20:02, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Tue, Apr 5, 2022 at 5:54 AM Dmitry Baryshkov > > > > wrote: > > > >>> 3. For DP and eDP HPD means something a little different. > > > >>> Essentially there are two concepts: a) is a display physically > > > >>> connected and b) is the display powered up and ready. For DP, the > > > >>> two are really tied together. From the kernel's point of view you > > > >>> never "power down" a DP display and you can't detect that it's > > > >>> physically connected until it's ready. Said another way, on you > > > >>> tie "is a display there" to the HPD line and the moment a display > > > >>> is there it's ready for you to do AUX transfers. For eDP, in the > > > >>> lowest power state of a display it _won't_ assert its "HPD" > > > >>> signal. However, it's still physically present. For eDP you simply > > > >>> have to _assume_ it's present without any actual proof since you > > > >>> can't get proof until you power it up. Thus for eDP, you report > > > >>> that the display is there as soon as we're asked. We can't _talk_ > > > >>> to the display yet, though. So in get_modes() we need to be able > > > >>> to power the display on enough to talk over the AUX channel to it. > > > >>> As part of this, we wait for the signal named "HPD" which really means > > "panel finished powering on" in this context. > > > >>> > > > >>> NOTE: for aux transfer, we don't have the _display_ pipe and > > > >>> clocks running. We only have enough stuff running to do the AUX > > transfer. > > > >>> We're not clocking out pixels. We haven't fully powered on the > > > >>> display. The AUX transfer is designed to be something that can be > > > >>> done early _before_ you turn on the display. > > > >>> > > > >>> > > > >>> OK, so basically that was a longwinded way of saying: yes, we > > > >>> could avoid the AUX transfer in probe, but we can't wait all the > > > >>> way to enable. We have to be able to transfer in get_modes(). If > > > >>> you think that's helpful I think it'd be a pretty easy patch to > > > >>> write even if it would look a tad bit awkward IMO. Let me know if > > > >>> you want me to post it up. > > > >> > > > >> I think it would be a good idea. At least it will allow us to > > > >> judge, which is the more correct way. > > > > > > > > I'm still happy to prototype this, but the more I think about it the > > > > more it feels like a workaround for the Qualcomm driver. The eDP > > > > panel driver is actually given a pointer to the AUX bus at probe > > > > time. It's really weird to say that we can't do a transfer on it > > > > yet... As you said, this is a little sideband bus. It should be able > > > > to be used without all the full blown infra of the rest of the driver. > > > > > > Yes, I have that feeling too. However I also have a feeling that just > > > powering up the PHY before the bus probe is ... a hack. There are no > > > obvious stopgaps for the driver not to power it down later. > > > > This is why I think we need to move to Runtime PM to manage this. Basically: > > > > 1. When an AUX transfer happens, you grab a PM runtime reference that > > _that_ powers up the PHY. > > > > 2. At the end of the AUX transfer function, you do a "put_autosuspend". > > > > Then it becomes not a hack, right? > > > > > > pm runtime ops needs to be implemented for both eDP and DP. This change > take good amount of planning and code changes as it affects DP also. > > Because this patch series consist of basic eDP changes for SC7280 bootup, > shall we take this pm_runtime implementation in subsequent patch series? Dmitry is the real decision maker here, but in my opinion it would be OK to get something landed first that worked OK and wasn't taking us too far in the wrong direction and then we could get a follow up patch to move to pm_runtime. 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 06F49C433EF for ; Thu, 7 Apr 2022 17:07:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6153510EBD6; Thu, 7 Apr 2022 17:07:54 +0000 (UTC) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by gabe.freedesktop.org (Postfix) with ESMTPS id CCF5A10EBD6 for ; Thu, 7 Apr 2022 17:07:52 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id x24so2203926edl.2 for ; Thu, 07 Apr 2022 10:07:52 -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=m2s4PG1XXBPY+xZ/g2KKtsmSmzO1vbLqhx1OJRbwqHk=; b=VFenbI8vl9C3SVgHSCx12w6Hk5Qy6qGRxJMtZkd2lfhRJFgJjv3Do/knpuu+OWtSMY 5b2c+eLOqhqoJks1M7BXl4sXkKZN5YZgLU58Vm7j8JcNmrZlNpaJ8SjKyiX/GO4QvbYC sZXP/gmxVZ1n4Wq7vE1X70J6/KrrTVlQB0LFg= 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=m2s4PG1XXBPY+xZ/g2KKtsmSmzO1vbLqhx1OJRbwqHk=; b=vd3qtnWNQ3v6RdFU4jd6eL0h/C/RrCMEfi30uUapnMEeqh+1+qEuPLTsqTAh3GhCgN Rxkezoep37Dw7tjMugIdxQVyLSqYnJpaZDcDREN6MsH5XvD8PvRGbm9e5kWhtm/w9xN3 Uqa9GG6QmK/aEEHopVVmEW9l/FiI5nNG4R61vlXzQTjD6x/qXCckRMosG/DFDstOOrBQ hqYO3ilWsJb9Df1SQzuCxAWMO/qpq5jNcNuWxRmlgDYqvKpbvviMOOgutaXuz/s4BwJJ PX3fsmwob9ryu58/UqVsfCH+s9zytSA+pgpc4csWg0ZwV4WRPlOKfUATSyvMLmqANmP9 lm4A== X-Gm-Message-State: AOAM5323kd3aqCyhv5oBImpwaLmmozFkYO2ph/haCVEYUewGtkNL3f2l Z5x0Mx2ONx+TupfwxpQ8d0gKKqYhB/knXg== X-Google-Smtp-Source: ABdhPJwtZNado8dYly/ykSYeQZ92oD/02KTQhBxKhPQg2/dm+P79eyfcGzQlwDNI0WTK9kjp54I6RQ== X-Received: by 2002:a50:c3c6:0:b0:416:293f:1f42 with SMTP id i6-20020a50c3c6000000b00416293f1f42mr15210856edf.187.1649351271260; Thu, 07 Apr 2022 10:07:51 -0700 (PDT) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com. [209.85.128.48]) by smtp.gmail.com with ESMTPSA id g25-20020a1709067c5900b006e806bf74c5sm3204577ejp.88.2022.04.07.10.07.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Apr 2022 10:07:51 -0700 (PDT) Received: by mail-wm1-f48.google.com with SMTP id h16so4010250wmd.0 for ; Thu, 07 Apr 2022 10:07:50 -0700 (PDT) X-Received: by 2002:a05:600c:4e10:b0:38e:6a6a:c06a with SMTP id b16-20020a05600c4e1000b0038e6a6ac06amr13253896wmq.15.1649351270179; Thu, 07 Apr 2022 10:07:50 -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: Doug Anderson Date: Thu, 7 Apr 2022 10:07:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus To: "Sankeerth Billakanti (QUIC)" 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" , quic_vproddut , David Airlie , linux-arm-msm , "Kuogee Hsieh \(QUIC\)" , freedreno , "Abhinav Kumar \(QUIC\)" , dri-devel , "bjorn.andersson@linaro.org" , Sean Paul , "dmitry.baryshkov@linaro.org" , "Aravind Venkateswaran \(QUIC\)" , Stephen Boyd , Sean Paul , LKML Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Thu, Apr 7, 2022 at 7:19 AM Sankeerth Billakanti (QUIC) wrote: > > Hi Dmitry and Doug, > > > Hi, > > > > On Tue, Apr 5, 2022 at 10:36 AM Dmitry Baryshkov > > wrote: > > > > > > On 05/04/2022 20:02, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Tue, Apr 5, 2022 at 5:54 AM Dmitry Baryshkov > > > > wrote: > > > >>> 3. For DP and eDP HPD means something a little different. > > > >>> Essentially there are two concepts: a) is a display physically > > > >>> connected and b) is the display powered up and ready. For DP, the > > > >>> two are really tied together. From the kernel's point of view you > > > >>> never "power down" a DP display and you can't detect that it's > > > >>> physically connected until it's ready. Said another way, on you > > > >>> tie "is a display there" to the HPD line and the moment a display > > > >>> is there it's ready for you to do AUX transfers. For eDP, in the > > > >>> lowest power state of a display it _won't_ assert its "HPD" > > > >>> signal. However, it's still physically present. For eDP you simply > > > >>> have to _assume_ it's present without any actual proof since you > > > >>> can't get proof until you power it up. Thus for eDP, you report > > > >>> that the display is there as soon as we're asked. We can't _talk_ > > > >>> to the display yet, though. So in get_modes() we need to be able > > > >>> to power the display on enough to talk over the AUX channel to it. > > > >>> As part of this, we wait for the signal named "HPD" which really means > > "panel finished powering on" in this context. > > > >>> > > > >>> NOTE: for aux transfer, we don't have the _display_ pipe and > > > >>> clocks running. We only have enough stuff running to do the AUX > > transfer. > > > >>> We're not clocking out pixels. We haven't fully powered on the > > > >>> display. The AUX transfer is designed to be something that can be > > > >>> done early _before_ you turn on the display. > > > >>> > > > >>> > > > >>> OK, so basically that was a longwinded way of saying: yes, we > > > >>> could avoid the AUX transfer in probe, but we can't wait all the > > > >>> way to enable. We have to be able to transfer in get_modes(). If > > > >>> you think that's helpful I think it'd be a pretty easy patch to > > > >>> write even if it would look a tad bit awkward IMO. Let me know if > > > >>> you want me to post it up. > > > >> > > > >> I think it would be a good idea. At least it will allow us to > > > >> judge, which is the more correct way. > > > > > > > > I'm still happy to prototype this, but the more I think about it the > > > > more it feels like a workaround for the Qualcomm driver. The eDP > > > > panel driver is actually given a pointer to the AUX bus at probe > > > > time. It's really weird to say that we can't do a transfer on it > > > > yet... As you said, this is a little sideband bus. It should be able > > > > to be used without all the full blown infra of the rest of the driver. > > > > > > Yes, I have that feeling too. However I also have a feeling that just > > > powering up the PHY before the bus probe is ... a hack. There are no > > > obvious stopgaps for the driver not to power it down later. > > > > This is why I think we need to move to Runtime PM to manage this. Basically: > > > > 1. When an AUX transfer happens, you grab a PM runtime reference that > > _that_ powers up the PHY. > > > > 2. At the end of the AUX transfer function, you do a "put_autosuspend". > > > > Then it becomes not a hack, right? > > > > > > pm runtime ops needs to be implemented for both eDP and DP. This change > take good amount of planning and code changes as it affects DP also. > > Because this patch series consist of basic eDP changes for SC7280 bootup, > shall we take this pm_runtime implementation in subsequent patch series? Dmitry is the real decision maker here, but in my opinion it would be OK to get something landed first that worked OK and wasn't taking us too far in the wrong direction and then we could get a follow up patch to move to pm_runtime.