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 62B70C433EF for ; Wed, 11 May 2022 18:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346179AbiEKSWM (ORCPT ); Wed, 11 May 2022 14:22:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237718AbiEKSWL (ORCPT ); Wed, 11 May 2022 14:22:11 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1916A126EA0 for ; Wed, 11 May 2022 11:22:09 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id j6so5665773ejc.13 for ; Wed, 11 May 2022 11:22:09 -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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=TysY5PPYSJqqGGSP17kFdgyVAcXW0GiDdLa8+M1+Q0ojkz+YMGJOdGZ1g7kkbPZOu6 yt+IrWP6PXRoXVf3HH1RNxijEEEziatsJwBR8ffnixgRhgmDKQimGHpCgltyrkDtU5pd QyBownI7LpEYTX9O9gVL+tE6Wpia3KSKpa7tY= 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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=LfxxqqxLKJpX6amRAq+8qxrxaHDM3afErcbctLb+i0nt0bdl66Y+XzPEkl7TvRdBQT VyTRGkoSRvOaQqvuhCxhL65KVJUXHdfBP9sGdz6Qagg408TKDPDqQC4FrQQeNmkd+kb3 icXgQ2/m2A21uYcRcDXVscyEC1JkPqr3uvWJteOoVfW4V9SZ+fhPWX+VdIIqJP0IoGKT BeX/6RLtOCHD1LMX1sq0fTylQEFijqFesiIZWIsrLid5qX3td4TizobXHoBKmt4QTl6p Tt/wmhiW2svaeFlHpuZ9Ign/fgqXGOqFyPjj9XeVIGZcEA8LWKX5TmpiI7SWPXVm2aOD i1Kw== X-Gm-Message-State: AOAM532wp08u7ZErf9MPH8pCST6oFas89kkHo0Y8YTWrHg48kfBtBJak U6i6fvC761054vQictWrvCrXoRDWTivRs8zZ4bo= X-Google-Smtp-Source: ABdhPJzYkLUsUL7T1tM9nUmuxTi/h0EaNWuoHMpOSgLiTAMuphY7bGwN1/zZOleHqs5ajdk9KQ0SGQ== X-Received: by 2002:a17:907:7b85:b0:6fd:d799:ef4e with SMTP id ne5-20020a1709077b8500b006fdd799ef4emr3470028ejc.319.1652293327423; Wed, 11 May 2022 11:22:07 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id r26-20020a056402019a00b0042617ba6391sm1503614edv.27.2022.05.11.11.22.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 11:22:06 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id bg25so1699510wmb.4 for ; Wed, 11 May 2022 11:22:06 -0700 (PDT) X-Received: by 2002:a05:600c:3c99:b0:392:b49c:7b79 with SMTP id bg25-20020a05600c3c9900b00392b49c7b79mr6101308wmb.199.1652293325498; Wed, 11 May 2022 11:22:05 -0700 (PDT) MIME-Version: 1.0 References: <20220425210643.2420919-1-dianders@chromium.org> <20220425140619.1.Ibfde5a26a7182c4b478d570c23d2649823ac2cce@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 11 May 2022 11:21:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings To: "Sankeerth Billakanti (QUIC)" Cc: Stephen Boyd , "bjorn.andersson@linaro.org" , "dmitry.baryshkov@linaro.org" , Rob Clark , Rob Herring , Vinod Koul , "Abhinav Kumar (QUIC)" , "linux-phy@lists.infradead.org" , dri-devel , freedreno , Kishon Vijay Abraham I , Krzysztof Kozlowski , linux-arm-msm , "Kalyan Thota (QUIC)" , "Kuogee Hsieh (QUIC)" , Daniel Vetter , David Airlie , Rob Clark , Sean Paul , "devicetree@vger.kernel.org" , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, On Fri, May 6, 2022 at 6:36 AM Sankeerth Billakanti (QUIC) wrote: > > >> >> Our internal power grid documents list the regulators as > >> >> VDD_A_*_1P2 and VDD_A_*_0P9 for all the platforms. > >> > > >> >Do your internal power grid documents indicate what these supplies > >> >are powering? The question is if these supplies power any of the > >> >logic inside the eDP controller or if they only supply power to the > >> >analog circuits in the eDP phy. If it's the eDP phy only then the > >> >regulator usage in the eDP driver should be removed. I would suspect > >> >this is the case because the controller is probably all digital logic > >> >and runs at the typical 1.8V that the rest of the SoC uses. > >> >Similarly, these are voltage references which sound like a PLL reference > >voltage. > >> > > >> >Please clarify this further. > >> > > >> > >> For the DP driver using the usb-dp combo phy, there were cases where > >> the usb driver was turning off the phy and pll regulators whenever usb-dp > >concurrent mode need not be supported. > >> This caused phy and pll to be powered down causing aux transaction failures > >and display blankouts. > >> From then on, it became a practice for the controller driver to vote for the > >phy and pll regulators also. > >> > > > >That sounds like USB-DP combo phy driver had improper regulator power > >management where aux transactions from DP didn't keep the power on to > >the phy. Where does the power physically go? If the power isn't physically > >going to the DP controller it shouldn't be controlled from the DP controller > >driver. If the aux bus needs the DP phy enabled, the DP controller driver > >should enable the phy power (via phy_power_on()?). > > Yes, it was limitation earlier when we did not have proper interface to interact > with the combo phy. > > In this case, the power from the regulators go to the combo phy. > > Now that there is an interface for the controller to interact with the > combo phy, the proposal to drop the phy regulator voting from the controller > driver seems reasonable to me. > > The phy_power_on() is used for getting the phy out of low power state or getting > it ready for data transfer. > > The controller driver needs to enable the phy power via the phy_init() before > any interaction with the sink like the aux transactions or before sending the data. > The controller can disable the regulators via the phy_exit() call. I can confirm that if I stop providing these regulators to the DP controller that the screen still comes up. ...but also there are lots of other things (including the PHY) that power these regulators up... >From offline discussion with folks: 1. It sounds like maybe the code for handling the regulators in the DP controller leaked in from downstream where the DP driver itself controls more stuff. 2. We should probably remove these regulators from the DP controller. 3. When we remove this from the DP controller, we'll have to make sure that the PHY driver calls regulator_set_load() as needed. Kuogee has volunteered to own this issue and send out patches fixing the stuff up. So for now, please consider ${SUBJECT} patch abandoned. -Doug 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 62D75C433FE for ; Wed, 11 May 2022 18:27:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uHKJVau2LinNOhlcTM2MFHpXTOJRaj8kxrZjc86VSWI=; b=JQNdDgqBG85kCe cTVZiZe8LK7FOFwP4skaa7b+LHUzca5Ji6UzCI7he3TJZtOQ2tt7GuKMnVfaEg5Lee2hGnRroUSkd y5R02gHErWgKpcSGY4DKla3BjUyH4dtUHwxDUnqZ8nEgND1UrxIibn/VKVR6zLbDfqJzTLDLDQBWH rzJQj7tklxpdo3KTus4/hXVq2FQA3y6IAPWIc5M/EWivefsYgMrnkeF2zt/qA6GyYzqFZe7AeBs0V mg0PEyj8Jy8IrA+q/RR0wjzV2NHY6wh2pyyB0PUu/bidUjI9pyNHSkfukJosHxI+7xufV6oGKtuhU 8gAD/o3vTVnufZrbCSIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nor40-0089Kz-P4; Wed, 11 May 2022 18:27:56 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nor3y-0089KZ-61 for linux-phy@lists.infradead.org; Wed, 11 May 2022 18:27:55 +0000 Received: by mail-ej1-x62e.google.com with SMTP id j6so5691601ejc.13 for ; Wed, 11 May 2022 11:27:53 -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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=TysY5PPYSJqqGGSP17kFdgyVAcXW0GiDdLa8+M1+Q0ojkz+YMGJOdGZ1g7kkbPZOu6 yt+IrWP6PXRoXVf3HH1RNxijEEEziatsJwBR8ffnixgRhgmDKQimGHpCgltyrkDtU5pd QyBownI7LpEYTX9O9gVL+tE6Wpia3KSKpa7tY= 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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=ur67q0lIrdSONqTSwilVSYHbd1V6FLJj7UhySxnF2SpgBGuoRVvYGt5+lCcUDjP/AE eLBQ/KPr8kciA43B3NIwHDDj0spX0nD240/jEt2AeNkj7uOJSJfNhHwgpEbTp9jUqUrH zPbojw/NZddQO4vmbN62lBPclReqMtNVu0zbF+19rR0jcfuVsXUjwmCjAAWM0FmAZwcb UNXrkhMA/dTNSwypEFQFs2sMwbzJAmjljYAdkF5SygiT8rbNRJ1XGrhMN8nPA2I2B7tj nfR036yuEbHRSUtyD9D7GFyieouySWEPLDYmaDREaZXZ2psGoLl0aefqpRuLahARDmWS shlA== X-Gm-Message-State: AOAM533MnPjOcDaPTYYtReEua7YNPaace/ByC1Ykpd/AYw6LuDzu19xn SNRi1yHHsHVkG5YuxkZsCruTE6/xKahvNFkL97g= X-Google-Smtp-Source: ABdhPJwt3dMEZ/WRqDXHMc7V5cgJPp7usZ1UQVS1yMZplUeGFR57P/dH0OWX9Da95lXSW5eMT+4lLw== X-Received: by 2002:a17:907:1c8d:b0:6f2:eb2:1cd6 with SMTP id nb13-20020a1709071c8d00b006f20eb21cd6mr25082164ejc.568.1652293671631; Wed, 11 May 2022 11:27:51 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id x1-20020aa7d381000000b0042617ba63casm1528227edq.84.2022.05.11.11.27.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 11:27:51 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id q20so1720023wmq.1 for ; Wed, 11 May 2022 11:27:51 -0700 (PDT) X-Received: by 2002:a05:600c:3c99:b0:392:b49c:7b79 with SMTP id bg25-20020a05600c3c9900b00392b49c7b79mr6101308wmb.199.1652293325498; Wed, 11 May 2022 11:22:05 -0700 (PDT) MIME-Version: 1.0 References: <20220425210643.2420919-1-dianders@chromium.org> <20220425140619.1.Ibfde5a26a7182c4b478d570c23d2649823ac2cce@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 11 May 2022 11:21:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings To: "Sankeerth Billakanti (QUIC)" Cc: Stephen Boyd , "bjorn.andersson@linaro.org" , "dmitry.baryshkov@linaro.org" , Rob Clark , Rob Herring , Vinod Koul , "Abhinav Kumar (QUIC)" , "linux-phy@lists.infradead.org" , dri-devel , freedreno , Kishon Vijay Abraham I , Krzysztof Kozlowski , linux-arm-msm , "Kalyan Thota (QUIC)" , "Kuogee Hsieh (QUIC)" , Daniel Vetter , David Airlie , Rob Clark , Sean Paul , "devicetree@vger.kernel.org" , LKML X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220511_112754_271452_E4EB4868 X-CRM114-Status: GOOD ( 31.66 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org Hi, On Fri, May 6, 2022 at 6:36 AM Sankeerth Billakanti (QUIC) wrote: > > >> >> Our internal power grid documents list the regulators as > >> >> VDD_A_*_1P2 and VDD_A_*_0P9 for all the platforms. > >> > > >> >Do your internal power grid documents indicate what these supplies > >> >are powering? The question is if these supplies power any of the > >> >logic inside the eDP controller or if they only supply power to the > >> >analog circuits in the eDP phy. If it's the eDP phy only then the > >> >regulator usage in the eDP driver should be removed. I would suspect > >> >this is the case because the controller is probably all digital logic > >> >and runs at the typical 1.8V that the rest of the SoC uses. > >> >Similarly, these are voltage references which sound like a PLL reference > >voltage. > >> > > >> >Please clarify this further. > >> > > >> > >> For the DP driver using the usb-dp combo phy, there were cases where > >> the usb driver was turning off the phy and pll regulators whenever usb-dp > >concurrent mode need not be supported. > >> This caused phy and pll to be powered down causing aux transaction failures > >and display blankouts. > >> From then on, it became a practice for the controller driver to vote for the > >phy and pll regulators also. > >> > > > >That sounds like USB-DP combo phy driver had improper regulator power > >management where aux transactions from DP didn't keep the power on to > >the phy. Where does the power physically go? If the power isn't physically > >going to the DP controller it shouldn't be controlled from the DP controller > >driver. If the aux bus needs the DP phy enabled, the DP controller driver > >should enable the phy power (via phy_power_on()?). > > Yes, it was limitation earlier when we did not have proper interface to interact > with the combo phy. > > In this case, the power from the regulators go to the combo phy. > > Now that there is an interface for the controller to interact with the > combo phy, the proposal to drop the phy regulator voting from the controller > driver seems reasonable to me. > > The phy_power_on() is used for getting the phy out of low power state or getting > it ready for data transfer. > > The controller driver needs to enable the phy power via the phy_init() before > any interaction with the sink like the aux transactions or before sending the data. > The controller can disable the regulators via the phy_exit() call. I can confirm that if I stop providing these regulators to the DP controller that the screen still comes up. ...but also there are lots of other things (including the PHY) that power these regulators up... >From offline discussion with folks: 1. It sounds like maybe the code for handling the regulators in the DP controller leaked in from downstream where the DP driver itself controls more stuff. 2. We should probably remove these regulators from the DP controller. 3. When we remove this from the DP controller, we'll have to make sure that the PHY driver calls regulator_set_load() as needed. Kuogee has volunteered to own this issue and send out patches fixing the stuff up. So for now, please consider ${SUBJECT} patch abandoned. -Doug -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy 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 B872DC433F5 for ; Wed, 11 May 2022 18:29:10 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 257CA10F1A7; Wed, 11 May 2022 18:29:10 +0000 (UTC) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by gabe.freedesktop.org (Postfix) with ESMTPS id A273B10F173 for ; Wed, 11 May 2022 18:29:08 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id w24so3585988edx.3 for ; Wed, 11 May 2022 11:29:08 -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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=TysY5PPYSJqqGGSP17kFdgyVAcXW0GiDdLa8+M1+Q0ojkz+YMGJOdGZ1g7kkbPZOu6 yt+IrWP6PXRoXVf3HH1RNxijEEEziatsJwBR8ffnixgRhgmDKQimGHpCgltyrkDtU5pd QyBownI7LpEYTX9O9gVL+tE6Wpia3KSKpa7tY= 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=uiYBAkZ/K7TON78jcHgwLk8yR9bWm2DLv+jXS6/7A90=; b=IYji7qOpHZ9LqnZHFRola9MBcQ/vxP+up8tT0w/zJ6TX1bME66Ib3gSP1Z12HT5vYk VkqrGnIDNoWnMtJ/03GECX2ZNUxHoBPLHJEbmQt83ncKL91RFz1OEeYiI87jw5RuOrPR NVAD7+5UQxqYpNXyr5zWvhWX1UHVPeYi44d7WT0vEUw/FoPIZ5mxZEBSuV7VG8it/Ca3 RlDo2SXdjd/+RohU/ils8FrveYhCdFN4HKCWFZuUppEhZcrd94zKrAbg7NeatW9O69nt bHSEG/eLaTmglQr5npIh8rR8oQofKYGXvF5YdgtjlWVoRQpjaDx8r23kvYe32LXdbz0I rBMQ== X-Gm-Message-State: AOAM532ovd7e0IElb2RswYWebU7TslRtqT9hVUrRF88GBdKJ1QTVVwgv iAvNI4QGxaE5d6Zle7YIQKtb62llVF1c5OpiRjQ= X-Google-Smtp-Source: ABdhPJz8sL2/zmNwZv5a5QRiDr0ZxRUGMt5+aqRiZzCSrgRihJNt0iX5WiQf+9BTO5hoMd8WMKuC9A== X-Received: by 2002:a50:ab57:0:b0:428:9f9b:d8e3 with SMTP id t23-20020a50ab57000000b004289f9bd8e3mr17491448edc.305.1652293746920; Wed, 11 May 2022 11:29:06 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id m3-20020a1709066d0300b006f3ef214deasm1248175ejr.80.2022.05.11.11.29.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 11:29:06 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id m2-20020a1ca302000000b003943bc63f98so1706703wme.4 for ; Wed, 11 May 2022 11:29:06 -0700 (PDT) X-Received: by 2002:a05:600c:3c99:b0:392:b49c:7b79 with SMTP id bg25-20020a05600c3c9900b00392b49c7b79mr6101308wmb.199.1652293325498; Wed, 11 May 2022 11:22:05 -0700 (PDT) MIME-Version: 1.0 References: <20220425210643.2420919-1-dianders@chromium.org> <20220425140619.1.Ibfde5a26a7182c4b478d570c23d2649823ac2cce@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 11 May 2022 11:21:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings 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: Rob Clark , Kishon Vijay Abraham I , "Kalyan Thota \(QUIC\)" , "devicetree@vger.kernel.org" , David Airlie , linux-arm-msm , "Kuogee Hsieh \(QUIC\)" , "Abhinav Kumar \(QUIC\)" , dri-devel , "bjorn.andersson@linaro.org" , "linux-phy@lists.infradead.org" , Vinod Koul , Rob Herring , Krzysztof Kozlowski , "dmitry.baryshkov@linaro.org" , Sean Paul , Stephen Boyd , freedreno , LKML Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Fri, May 6, 2022 at 6:36 AM Sankeerth Billakanti (QUIC) wrote: > > >> >> Our internal power grid documents list the regulators as > >> >> VDD_A_*_1P2 and VDD_A_*_0P9 for all the platforms. > >> > > >> >Do your internal power grid documents indicate what these supplies > >> >are powering? The question is if these supplies power any of the > >> >logic inside the eDP controller or if they only supply power to the > >> >analog circuits in the eDP phy. If it's the eDP phy only then the > >> >regulator usage in the eDP driver should be removed. I would suspect > >> >this is the case because the controller is probably all digital logic > >> >and runs at the typical 1.8V that the rest of the SoC uses. > >> >Similarly, these are voltage references which sound like a PLL reference > >voltage. > >> > > >> >Please clarify this further. > >> > > >> > >> For the DP driver using the usb-dp combo phy, there were cases where > >> the usb driver was turning off the phy and pll regulators whenever usb-dp > >concurrent mode need not be supported. > >> This caused phy and pll to be powered down causing aux transaction failures > >and display blankouts. > >> From then on, it became a practice for the controller driver to vote for the > >phy and pll regulators also. > >> > > > >That sounds like USB-DP combo phy driver had improper regulator power > >management where aux transactions from DP didn't keep the power on to > >the phy. Where does the power physically go? If the power isn't physically > >going to the DP controller it shouldn't be controlled from the DP controller > >driver. If the aux bus needs the DP phy enabled, the DP controller driver > >should enable the phy power (via phy_power_on()?). > > Yes, it was limitation earlier when we did not have proper interface to interact > with the combo phy. > > In this case, the power from the regulators go to the combo phy. > > Now that there is an interface for the controller to interact with the > combo phy, the proposal to drop the phy regulator voting from the controller > driver seems reasonable to me. > > The phy_power_on() is used for getting the phy out of low power state or getting > it ready for data transfer. > > The controller driver needs to enable the phy power via the phy_init() before > any interaction with the sink like the aux transactions or before sending the data. > The controller can disable the regulators via the phy_exit() call. I can confirm that if I stop providing these regulators to the DP controller that the screen still comes up. ...but also there are lots of other things (including the PHY) that power these regulators up... >From offline discussion with folks: 1. It sounds like maybe the code for handling the regulators in the DP controller leaked in from downstream where the DP driver itself controls more stuff. 2. We should probably remove these regulators from the DP controller. 3. When we remove this from the DP controller, we'll have to make sure that the PHY driver calls regulator_set_load() as needed. Kuogee has volunteered to own this issue and send out patches fixing the stuff up. So for now, please consider ${SUBJECT} patch abandoned. -Doug