[PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support

[Roger Quadros]

On 06/19/2013 03:23 PM, Benoit Cousson wrote:
> On 06/19/2013 07:05 AM, Florian Vaussard wrote:
>> Hello,
>>
>> On 06/19/2013 01:03 PM, Roger Quadros wrote:
>>> On 06/19/2013 01:10 PM, Benoit Cousson wrote:
>>>> On 06/19/2013 02:46 AM, Tony Lindgren wrote:
>>>>> * Roger Quadros <rogerq at ti.com> [130619 00:42]:
>>>>>> Hi Benoit,
>>>>>>
>>>>>> On 06/19/2013 04:17 AM, Benoit Cousson wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> On 06/18/2013 11:04 AM, 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 at ti.com>
>>>>>>>> ---
>>>>>>>>     arch/arm/boot/dts/omap4-panda-common.dtsi |   62
>>>>>>>> +++++++++++++++++++++++++++++
>>>>>>>>     1 files changed, 62 insertions(+), 0 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>>>>>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>>>>>> index 00cbaa5..7a21e8e 100644
>>>>>>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>>>>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>>>>>> @@ -59,6 +59,42 @@
>>>>>>>>                 "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;
>>>>>>>> +    };
>>>>>>>
>>>>>>> Is this really a regulator? Or just a GPIO line used to reset the
>>>>>>> USB PHY?
>>>>>>
>>>>>> It is in fact a GPIO line used as reset.
>>>>>>>
>>>>>>> If this is the case, I don't think it should be represented as a
>>>>>>> regulator.
>>>>>>
>>>>>> Why not? I think it fits very well in the regulator device model.
>>>>
>>>> I'm not sure fitting very well is the correct term.
>>>> It works, for sure, but it is no different than when we were trying
>>>> to abuse the regulator fmwk to enable the 32k clock in phoenix.
>>>> It is just a hack.
>>>>
>>>
>>> The only difference is there is a dedicated framework for clocks.
>>> Since there is nothing specific to
>>> handle reset lines it is left to the driver writer how he wants to
>>> manage it.
>>>
>>
>> There is a proposed binding for gpio-controlled reset lines, but it is
>> not yet merged [1].
>> I guess it can fit most usage patterns, and it can be an interesting
>> move in the future.
> 
> I'm glad to see that I was not the only one thinking that the regulator was not the right fmwk to do that :-)
> 
> Thanks for the pointer Florian.

Thanks again Florian.
> 
> I guess that series should be merged for 3.11? Based on the thread, it should to through arm-soc.
> 
> Roger,
> 
> It might be tricky to have dependency on that series, but if this is possible, you should try. Otherwise, just keep the existing one, adding that a new solution will be available soon as a disclaimer.
> 

I will rework the PHY driver to use the new gpio-reset driver. But for 3.11 let's proceed the way it is.
I'll resend this one with a disclaimer.

cheers,
-roger