Re: [PATCH v1] clk: qcom: Skip halt checks on gcc_pcie_0_pipe_clk for 8998

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/11/2019 1:18 AM, Stephen Boyd wrote:
> Quoting Manu Gautam (2019-10-10 00:33:32)
>> Hi,
>>
>> On 10/10/2019 9:45 AM, Stephen Boyd wrote:
>>> Quoting Manu Gautam (2019-10-09 01:31:09)
>> [snip]
>>>> I have followed this up with QMP PHY hardware designers and they have
>>>> confirmed that QMP PHY must have pipe clock enabled at the beginning
>>>> of initialization sequence i.e. before bringing it out of reset and starting it.
>>> Awesome, thanks for following up.
>>>
>>>> Otherwise there is possibility of incorrect locking of pipe_interface/
>>>> retime buffers in PHY.
>>>> Hence, for both USB and PCIe we have to continue to use HALT_SKIP flag.
>>> Does anything go wrong if we just leave these clks enabled forever out
>>> of boot? I'm inclined to rip the clks out and just slam the branch
>>> enable bit on all the time in gcc driver probe and return NULL to the
>>> callers of clk_get() for these clks. I don't see how this would be a
>>> problem because when the upstream phy is disabled this clk is disabled
>>> and so we aren't wasting power. It should also save us time and memory
>>> because now we don't have to call into the clk framework to turn it on
>>> and sequence that just right in the phy driver.
>> That might work, however on some platforms gcc_pipe_clk parent is changed to
>> XO and back to phy_pipe_clk across low power mode.
>> It requires PHY driver to use clk_set_parent().
>>
> Hm ok. Where is the call to clk_set_parent()? I don't see this in the
> kernel.
>
>  $ git grep clk_set_parent -- drivers/usb/phy drivers/phy | wc -l
>  0
>
> What platforms do this? Are they upstream?

They are some recent platforms and not on upstream yet.

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux