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 <rog...@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 <rog...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
