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

[Tony Lindgren <tony@atomide.com>]

* Benoit Cousson <b-cousson@ti.com> [130619 05:30]:
> On 06/19/2013 07:05 AM, Florian Vaussard wrote:
> >>>>>>>+
> >>>>>>>+    /* 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.

If it's a reset, then yeah it's not a regulator. If the GPIO line is
really used to control the regulator in the external device, then it
makes sense to set it up as a regulator.

> >>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.

Good to hear about the gpio-controlled reset lines :)
 
> 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.

We need some solution for v3.11 for omap4 USB on panda so people can
use it with DT.

Regards,

Tony