On 06/20/2013 01:40 AM, Benoit Cousson wrote:
> On 06/19/2013 09:05 AM, Roger Quadros wrote:
>> 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@xxxxxx> [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@xxxxxx>
>>>>>>>>>> ---
>>>>>>>>>> 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.
>
> OK, I've just done it myself while applying your series.
>
Great !! Thanks.
There is a similar patch for beagle-xm. But I will resend it to you with the disclaimer.
cheers,
-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
