On 02/05/2013 01:15 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote:
>> Hi Rajendra,
>>
>> On 02/04/2013 05:58 PM, Roger Quadros wrote:
>>> Provide the RESET and Power regulators for the USB PHY,
>>> the USB Host port mode and the PHY device.
>>>
>>> Also provide pin multiplexer information for the USB host
>>> pins.
>>>
>>> Signed-off-by: Roger Quadros <rogerq@xxxxxx>
>>> ---
>>> arch/arm/boot/dts/omap4-panda.dts | 55 +++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 55 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
>>> index 4122efe..fe2d3d4 100644
>>> --- a/arch/arm/boot/dts/omap4-panda.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda.dts
>>> @@ -57,6 +57,35 @@
>>> "AFML", "Line In",
>>> "AFMR", "Line In";
>>> };
>>> +
>>> + /* HS USB Port 1 RESET */
>>> + hsusb1_reset: hsusb1_reset_reg {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "hsusb1_reset";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + gpio = <&gpio2 30 0>; /* gpio_62 */
>>> + startup-delay-us = <70000>;
>>> + enable-active-high;
>>> + };
>>> +
>>> + /* HS USB Port 1 Power */
>>> + hsusb1_power: hsusb1_power_reg {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "hsusb1_vbus";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + gpio = <&gpio1 1 0>; /* gpio_1 */
>>> + startup-delay-us = <70000>;
>>> + enable-active-high;
>>> + };
>>> +
>>> + /* HS USB Host PHY on PORT 1 */
>>> + hsusb1_phy: hsusb1_phy {
>>> + compatible = "usb-nop-xceiv";
>>> + reset-supply = <&hsusb1_reset>;
>>> + vcc-supply = <&hsusb1_power>;
>>> + };
>>
>> This is the patch I was discussing with you about before.
>>
>> Let me explain the problem again.
>>
>> The Pandaboard has a USB PHY whose reference clock is provided by
>> FREF_CLK3 pin which is a clock generated by the OMAP.
>> The PHY driver expects a reference to this clock in the PHY device node.
>
> Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is
> then able to either pick the reference from the PHY dt node or from a
> clkdev entry.
>
> The problem here seems to be that you are not able to add a clkdev entry
> because the device name wouldn't be fixed, since you have a node in
> the form of 'node: node {'. All other onchip OMAP devices don't have
> this issue because they have an entry in the form of 'node: node@addr'
> and hence have a fixed device name and hence can add a clkdev entry for
> the clocks they want to control.
>
> I don't know if there is any good way to define the DT node for the
> on board PHY in such a way that the device name is always fixed, in
> which case you can then add a clkdev entry for 'dev, main_clk' mapping
> to the onchip clock that provides the clock, but if there is one, then
> that should fix your problem.
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.
So you can't provide this information in some common clock data file.
The data has to come from a board specific location, which in the DT boot
case is the board's dts file.
I think all we need to do is register a clock provider using of_clk_add_provider()
and provide a clk_src_get() hook that can get the right clock.
usage e.g.
/* provider */
clks: omapclocks {
compatible = "ti,omapclocks";
#clock-cells = <1>;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
clocks = <&clks "auxclk3_ck">; /* FREF_CLK3 */
clock-names = "main-clk";
};
The only problem I see is that the argument to the clks phandle
cannot be a string. It needs to be u32.
In that case we need to map all clocks into a u32 index.
If we can do that only for auxclks, my problem is solved for panda.
The usage e.g then changes to
/* provider */
aux_clks: omap_aux_clocks {
compatible = "ti,omap_aux_clocks";
#clock-cells = <1>;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
clocks = <&aux_clks 3>; /* FREF_CLK3 */
clock-names = "main-clk";
};
Does this idea sound reasonable?
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
