LKML Archive on
help / color / mirror / Atom feed
From: Manu Gautam <>
To: Stephen Boyd <>, Doug Anderson <>
Cc: Kishon Vijay Abraham I <>,
	Rob Herring <>,
	Stephen Boyd <>,
	LKML <>,, Rob Herring <>,
	Vivek Gautam <>,
	Evan Green <>,,
	Varadarajan Narayanan <>,
	Wei Yongjun <>,
	Fengguang Wu <>
Subject: Re: [PATCH v4 2/7] phy: qcom-qmp: Enable pipe_clk before PHY initialization
Date: Wed, 11 Apr 2018 21:07:38 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On 4/11/2018 12:02 AM, Stephen Boyd wrote:
> Quoting Doug Anderson (2018-04-10 08:05:27)
>> On Mon, Apr 9, 2018 at 11:36 PM, Manu Gautam <> wrote:
>>> On 3/30/2018 2:24 AM, Doug Anderson wrote:
>>>> Oh!  This is what you did in the previous version of the patch, then you said:
>>>> "That is still needed as PHY might take some time to generate pipe_clk
>>>> after its PLL is locked".
>>>> It's really going to take more than the 200 us that the clock driver
>>>> is giving it?  If so, I'd prefer to increase the amount of time waited
>>>> in the clock driver, or adding a fixed delay _before_ the clk_enable()
>>>> so that the 200 us that the clock driver gives it would be enough.
>>>> I'm just not a fan of ignoring status bits if it can be helped.
>>> I too would want to do that but it is not just about the delay.
>>> As per QMP PHY hardware designers, pipe_clk should be enabled in GCC
>>> as first thing in the PHY initialization sequence. Same sequence also has
>>> been used in downstream phy driver always.
>>> Changing the sequence might work but I would like to stick to the HPG
>>> recommendation and avoid any deviation as PHY issues are very hard to
>>> debug.
>> So hardware guys tell you that you're _supposed to_ ignore the clock
>> ready bit for that clock and just hope it turns on and settles in time
>> once power comes on for the clock?  That doesn't seem ideal.  My guess
>> is that it's a bug in the specification that the QMP PHY hardware
>> designers gave you.
It could be a bug in specification. But same sequence has been well tested on both
msm8996 and sdm845, so I would for now like to stick with that for now.
>> Stephen can feel free to override me if he disagrees since he's in
>> charge of the clock part of this, but IMHO we should get the
>> specification fixed and turn things on in the order that lets us check
>> the status bits.
> Presumably there's a PLL "enable" bit in the QMP phy init sequence that
> we can use to enable the PLL output at a bypass rate and then enable the
> clk in GCC and then resume the PLL enable sequence. That would allow us
> to make sure the clk is working.
> Are the branches in GCC ever turned on or off at runtime though? Or do
> we just turn them on because they're defaulted off out of reset and then
> leave them on?
It can be left on always.
> I ask because it may be easier to never expose these clks in Linux, hit
> the enable bits in the branches during clk driver probe, and then act
> like they never exist because we don't really use them.
This sounds better idea. Let me check if I can get a patch for same in msm8996
and sdm845 clock drivers.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2018-04-11 15:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-29 11:04 [PATCH v4 0/7] phy: qcom: Updates for USB PHYs on SDM845 Manu Gautam
2018-03-29 11:04 ` [PATCH v4 1/7] clk: msm8996-gcc: change halt check for USB/PCIE pipe_clk Manu Gautam
2018-03-29 20:55   ` Doug Anderson
2018-04-05 20:07     ` Stephen Boyd
2018-04-10  6:44       ` Manu Gautam
2018-03-29 11:04 ` [PATCH v4 2/7] phy: qcom-qmp: Enable pipe_clk before PHY initialization Manu Gautam
2018-03-29 17:28   ` Evan Green
2018-03-29 18:44   ` Doug Anderson
2018-03-29 20:54     ` Doug Anderson
2018-04-10  6:36       ` Manu Gautam
2018-04-10 15:05         ` Doug Anderson
2018-04-10 18:32           ` Stephen Boyd
2018-04-11 15:37             ` Manu Gautam [this message]
2018-04-12 20:38               ` Stephen Boyd
2018-04-13  7:00                 ` Manu Gautam
2018-03-29 11:04 ` [PATCH v4 3/7] phy: qcom-qusb2: Fix crash if nvmem cell not specified Manu Gautam
2018-03-29 11:04 ` [PATCH v4 4/7] dt-bindings: phy-qcom-qmp: Update bindings for sdm845 Manu Gautam
2018-03-29 19:39   ` Doug Anderson
2018-03-29 11:04 ` [PATCH v4 5/7] phy: qcom-qmp: Add QMP V3 USB3 UNI PHY support " Manu Gautam
2018-03-29 11:04 ` [PATCH v4 6/7] dt-bindings: phy-qcom-usb2: Add support to override tuning values Manu Gautam
2018-03-29 20:38   ` Doug Anderson
2018-04-09 20:18     ` Rob Herring
2018-04-10  7:16       ` Manu Gautam
2018-04-12 20:47         ` Doug Anderson
2018-04-16  1:36           ` Manu Gautam
2018-03-29 11:04 ` [PATCH v4 7/7] phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845 Manu Gautam
2018-03-29 20:38   ` Doug Anderson
2018-04-10  6:55     ` Manu Gautam

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).