Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934489Ab3FSKLt (ORCPT ); Wed, 19 Jun 2013 06:11:49 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:44942 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933830Ab3FSKLr (ORCPT ); Wed, 19 Jun 2013 06:11:47 -0400 Message-ID: <51C183AC.8040801@ti.com> Date: Wed, 19 Jun 2013 05:10:52 -0500 From: Benoit Cousson Organization: Texas Instruments User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tony Lindgren CC: Roger Quadros , , , , Subject: Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support References: <1371571487-14389-1-git-send-email-rogerq@ti.com> <1371571487-14389-2-git-send-email-rogerq@ti.com> <51C106A1.9030001@ti.com> <51C15F7E.5020305@ti.com> <20130619074605.GW5523@atomide.com> In-Reply-To: <20130619074605.GW5523@atomide.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3757 Lines: 95 On 06/19/2013 02:46 AM, Tony Lindgren wrote: > * Roger Quadros [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 >>>> --- >>>> 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. >>I couldn't find a better >> way to represent this. It gives us a way to specify not only the GPIO line but also >> the polarity. I know mostly reset is active low but still there is flexibility as you never >> know for sure. Mmm, and what about just controlling the gpio from the driver? > I think it's really a mux + a comparator. But from Linux driver point of view > a regulator fits well as we don't have anything better. After all, the pin > voltage changes, and then something can be done based on the comparator > value. > >> Do you have any better ideas? > > We have a similar issue with the MMC1 PBIAS. I think in the long run we > should expand regulator (and possibly pinctrl) framework(s) to handle > comparators. We could just assume that a comparatator is a regulator, > and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. >> FYI. The USB PHY driver is already treating reset as a regulator and is into 3.10. Reworking that >> will take some time. Not getting these in will prevent USB host/ethernet support on panda. That's not because we did some mistake in the past that we have to keep doing that :-) > Yes and we need to have some solution for v3.11 as we've dropped the > legacy data for omap4. Otherwise things won't work properly. I'm fine taking it as soon as big disclaimer is added to avoid mis-using the regulator in the future for controlling a gpio line. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/