[PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Benoit Cousson
b-cousson at ti.com
Wed Jun 19 22:23:10 EST 2013
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.
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.
Regards,
Benoit
More information about the devicetree-discuss
mailing list