Re: [PATCH 1/2] clk: tegra: remove USB from clk init table

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 01/28/2013 12:23 PM, Lucas Stach wrote:
> Am Montag, den 28.01.2013, 12:13 -0700 schrieb Stephen Warren:
>> On 01/28/2013 11:45 AM, Lucas Stach wrote:
>>> Am Montag, den 28.01.2013, 11:37 -0700 schrieb Stephen Warren:
>>>> On 01/27/2013 03:17 PM, Lucas Stach wrote:
>>>>> The USB clocks are just clock gates, so no need to set a specific clock.
>>>>> In fact trying to set a specific clock is just a NOP if the requested
>>>>> clockrate is the same as those of the parent (clk_m) or will trigger a
>>>>> WARN_ON() if rates don't match up.
>>>>>
>>>>> As we are not setting a specific rate, nor activating the clocks at
>>>>> init, there is no point in keeping the the usb entries in the clock init
>>>>> table.
>>>>
>>>> I'm not convinced here; aren't the USB clocks supposed to be driven by
>>>> PLL U?
>>>>
>>>> Prashant, Peter, Venu, can you please comment here.
>>>
>>> I was a bit confused at first, too. But what I am removing here is the
>>> clockgate init for the USB controllers. The clocks driven by PLL_U are
>>> the USB PHY clocks, which are a separate set of clocks.
>>
>> I don't think these are always separate.
>>
>> If you look at the USB driver drivers/usb/phy/tegra_usb_phy.c, you'll
>> see that for UTMI there's a clk_get_sys("utmip-pad"), which per
>> drivers/clk/tegra/clk-tegra20.c is an alias for clock "usbd" which is
>> the USB1 controller clock (it's also aliased to "tegra-ehci.0").
>> However, for ULPI, there's a clk_get_sys(ulpi_config->clk), which is
>> "cdev2", which is separate from any USB controller clock.
>>
> I'm not sure here. The TRM is not really clear on that one, but if you
> look at the schematic diagram of the USB complex PLL_U is really only
> used for the PHYs, not the controllers itself. Though I don't know if
> the controller gets it's clock from the PHY in the UTMI case (like
> ULPI). So I also would like some NVIDIA clock expert to comment on this.

> In either case the explicit init isn't needed.

My suspicion is that the usb* clocks are actually driven by pll_u_out*
rather than clk_m as the clock driver currently states. In which case,
these initializations are probably intended to have the side-effect of
filtering up and configuring pll_u itself. Perhaps the answer is still
to remove those entries and replace them with a pll_u initialization.

Anyway, hopefully Prashant can shed some light here.