All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Doug Anderson <dianders@chromium.org>,
	"Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
Cc: "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	Rob Clark <robdclark@chromium.org>,
	Rob Herring <robh+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	"Abhinav Kumar (QUIC)" <quic_abhinavk@quicinc.com>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"Kalyan Thota (QUIC)" <quic_kalyant@quicinc.com>,
	"Kuogee Hsieh (QUIC)" <quic_khsieh@quicinc.com>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings
Date: Fri, 6 May 2022 13:36:43 +0000	[thread overview]
Message-ID: <MW4PR02MB71866E59B844A0842DF7570EE1C59@MW4PR02MB7186.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CAE-0n53MEBYhyRtGWOCmjj923UQU_iVE_SEBQw6_FUci8NLz3w@mail.gmail.com>

>> >> 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.

Thank you,
Sankeerth

WARNING: multiple messages have this Message-ID (diff)
From: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Doug Anderson <dianders@chromium.org>,
	 "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
Cc: Rob Clark <robdclark@chromium.org>,
	"Kalyan Thota \(QUIC\)" <quic_kalyant@quicinc.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"Kuogee Hsieh \(QUIC\)" <quic_khsieh@quicinc.com>,
	"Abhinav Kumar \(QUIC\)" <quic_abhinavk@quicinc.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	Vinod Koul <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	Sean Paul <sean@poorly.run>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	freedreno <freedreno@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings
Date: Fri, 6 May 2022 13:36:43 +0000	[thread overview]
Message-ID: <MW4PR02MB71866E59B844A0842DF7570EE1C59@MW4PR02MB7186.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CAE-0n53MEBYhyRtGWOCmjj923UQU_iVE_SEBQw6_FUci8NLz3w@mail.gmail.com>

>> >> 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.

Thank you,
Sankeerth

WARNING: multiple messages have this Message-ID (diff)
From: "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Doug Anderson <dianders@chromium.org>,
	 "Sankeerth Billakanti (QUIC)" <quic_sbillaka@quicinc.com>
Cc: "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>,
	Rob Clark <robdclark@chromium.org>,
	Rob Herring <robh+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	"Abhinav Kumar (QUIC)" <quic_abhinavk@quicinc.com>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"Kalyan Thota (QUIC)" <quic_kalyant@quicinc.com>,
	"Kuogee Hsieh (QUIC)" <quic_khsieh@quicinc.com>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings
Date: Fri, 6 May 2022 13:36:43 +0000	[thread overview]
Message-ID: <MW4PR02MB71866E59B844A0842DF7570EE1C59@MW4PR02MB7186.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CAE-0n53MEBYhyRtGWOCmjj923UQU_iVE_SEBQw6_FUci8NLz3w@mail.gmail.com>

>> >> 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.

Thank you,
Sankeerth
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2022-05-06 13:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 21:06 [PATCH 0/2] dt-bindings: List supplies needed for sc7280 eDP Douglas Anderson
2022-04-25 21:06 ` Douglas Anderson
2022-04-25 21:06 ` Douglas Anderson
2022-04-25 21:06 ` [PATCH 1/2] dt-bindings: msm/dp: List supplies in the bindings Douglas Anderson
2022-04-25 21:06   ` Douglas Anderson
2022-04-25 21:06   ` Douglas Anderson
2022-04-25 21:14   ` Stephen Boyd
2022-04-25 21:14     ` Stephen Boyd
2022-04-25 21:14     ` Stephen Boyd
2022-04-25 21:18     ` Doug Anderson
2022-04-25 21:18       ` Doug Anderson
2022-04-25 21:18       ` Doug Anderson
2022-05-05 18:02       ` Sankeerth Billakanti
2022-05-05 18:02         ` Sankeerth Billakanti
2022-05-05 18:02         ` Sankeerth Billakanti
2022-05-05 18:18         ` Stephen Boyd
2022-05-05 18:18           ` Stephen Boyd
2022-05-05 18:18           ` Stephen Boyd
2022-05-05 18:47           ` Sankeerth Billakanti (QUIC)
2022-05-05 18:47             ` Sankeerth Billakanti (QUIC)
2022-05-05 18:47             ` Sankeerth Billakanti (QUIC)
2022-05-05 19:06             ` Stephen Boyd
2022-05-05 19:06               ` Stephen Boyd
2022-05-05 19:06               ` Stephen Boyd
2022-05-06 13:36               ` Sankeerth Billakanti (QUIC) [this message]
2022-05-06 13:36                 ` Sankeerth Billakanti (QUIC)
2022-05-06 13:36                 ` Sankeerth Billakanti (QUIC)
2022-05-11 18:21                 ` Doug Anderson
2022-05-11 18:21                   ` Doug Anderson
2022-05-11 18:21                   ` Doug Anderson
2022-04-25 21:06 ` [PATCH 2/2] dt-bindings: phy: List supplies for qcom,edp-phy Douglas Anderson
2022-04-25 21:06   ` Douglas Anderson
2022-04-25 21:06   ` Douglas Anderson
2022-05-05 18:47   ` Sankeerth Billakanti (QUIC)
2022-05-05 18:47     ` Sankeerth Billakanti (QUIC)
2022-05-05 18:47     ` Sankeerth Billakanti (QUIC)
2022-06-16 15:35   ` Doug Anderson
2022-06-16 15:35     ` Doug Anderson
2022-06-16 15:35     ` Doug Anderson
2022-06-17  0:10     ` Vinod Koul
2022-06-17  0:10       ` Vinod Koul
2022-06-17  0:10       ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW4PR02MB71866E59B844A0842DF7570EE1C59@MW4PR02MB7186.namprd02.prod.outlook.com \
    --to=quic_sbillaka@quicinc.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=kishon@ti.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_kalyant@quicinc.com \
    --cc=quic_khsieh@quicinc.com \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.