Re: [PATCH v3 1/3] usb: dwc3: msm: Add device tree binding information

From: Stephen Boyd
Date: Mon Aug 19 2013 - 12:30:29 EST


On 08/19/13 05:27, Ivan T. Ivanov wrote:
> Hi,
>
> On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote:
>> On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote:
>>> From: "Ivan T. Ivanov" <iivanov@xxxxxxxxxx>
>>>
>>> MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
>>> (SNPS) and HS, SS PHY's control and configuration registers.
>>>
>>> It could operate in device mode (SS, HS, FS) and host
>>> mode (SS, HS, FS, LS).
>>> diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
>>> +- clock-names :
>> ...
>>> + "sleep_a_clk" : Sleep clock, used when USB3 core goes into low
>> ...
>>> + "ref_clk" : Reference clock - used in host mode.
>> ...
>>> + "core_clk" : Master/Core clock, have to be >= 125 MHz for SS
>> ...
>>> + "iface_clk" : System bus AXI clock
>>> + "sleep_clk" : Sleep clock, used when USB3 core goes into low
>> ...
>>> + "utmi_clk" : Generated by HS-PHY. Used to clock the low power
>> I think it makes sense to remove "_clk" from all those names, unless the
>> HW documentation really talks about a clock named e.g. iface_clk yet
>> some other clock names in the documentation don't have the "_clk"
>> suffix, e.g. the "xo I didn't quote.
> From limited information that I have, I could not say how clock inputs
> are named from the controller perspective, but I agree that "_clk"
> suffix looks redundant.

In downstream trees we've tried to standardize the names on core_clk,
iface_clk, bus_clk, etc. Historically the hardware designers have used
the names from the clock controller instead of coming up with standard
names of their own when they put the clock inputs in their data sheets
(if they do at all).

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/