From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Roger Quadros <rogerq@ti.com>
Cc: bcousson@baylibre.com, Tony Lindgren <tony@atomide.com>,
Enric Balletbo i Serra <eballetbo@gmail.com>,
linux-omap@vger.kernel.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support
Date: Mon, 07 Oct 2013 11:13:05 +0200 [thread overview]
Message-ID: <52527B21.5040602@collabora.co.uk> (raw)
In-Reply-To: <5252799A.5030301@ti.com>
On 10/07/2013 11:06 AM, Roger Quadros wrote:
> +devicetree
>
> Javier,
>
> On 10/07/2013 11:50 AM, Javier Martinez Canillas wrote:
>> On Mon, Oct 7, 2013 at 10:33 AM, Roger Quadros <rogerq@ti.com> wrote:
>>> Hi Javier,
>>>
>>> On 10/05/2013 03:04 AM, Javier Martinez Canillas wrote:
>>>> Add device nodes for the HS USB Host port 1, USB PHY and its
>>>> required regulator and also pin mux setup for HS USB1 pins.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>>> ---
>>>> arch/arm/boot/dts/omap3-igep.dtsi | 22 ++++++++++++++++++++++
>>>> arch/arm/boot/dts/omap3-igep0020.dts | 25 +++++++++++++++++++++++++
>>>> 2 files changed, 47 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
>> b/arch/arm/boot/dts/omap3-igep.dtsi
>>>> index 0f92224..ec2ecd2 100644
>>>> --- a/arch/arm/boot/dts/omap3-igep.dtsi
>>>> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
>>>> @@ -27,6 +27,11 @@
>>>> };
>>>>
>>>> &omap3_pmx_core {
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <
>>>> + &hsusbb1_pins
>>>> + >;
>>>> +
>>>> uart1_pins: pinmux_uart1_pins {
>>>> pinctrl-single,pins = <
>>>> 0x152 (PIN_INPUT | MUX_MODE0) /*
>> uart1_rx.uart1_rx */
>>>> @@ -78,6 +83,23 @@
>>>> >;
>>>> };
>>>>
>>>> + hsusbb1_pins: pinmux_hsusbb1_pins {
>>>> + pinctrl-single,pins = <
>>>> + 0x5aa (PIN_OUTPUT | MUX_MODE3) /*
>> etk_ctl.hsusb1_clk */
>>>> + 0x5a8 (PIN_OUTPUT | MUX_MODE3) /*
>> etk_clk.hsusb1_stp */
>>>> + 0x5bc (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d8.hsusb1_dir */
>>>> + 0x5be (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d9.hsusb1_nxt */
>>>> + 0x5ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d0.hsusb1_data0 */
>>>> + 0x5ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d1.hsusb1_data1 */
>>>> + 0x5b0 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d2.hsusb1_data2 */
>>>> + 0x5b2 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d3.hsusb1_data7 */
>>>> + 0x5b4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d4.hsusb1_data4 */
>>>> + 0x5b6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d5.hsusb1_data5 */
>>>> + 0x5b8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d6.hsusb1_data6 */
>>>> + 0x5ba (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
>> etk_d7.hsusb1_data3 */
>>>> + >;
>>>> + };
>>>> +
>>>
>>> Is this pin config required for igep0030 as well? If not then you should move
>> these pinmux
>>> definitions to omap3-igep0020.dts.
>>>
>>> All else looks good to me.
>>>
>>
>> Hi Roger,
>>
>> Well that's a very good question indeed.
>>
>> The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
>> conjunction with expansion boards and some of them have USB HOST support such as
>> IGEP Paris [2] and IGEP Berlin [3].
>>
>> Support for this expansion boards is still not in mainline but there are plans
>> to add them using Device Tree overlays [4] once/if this land on mainline.
>>
>
> Why would your boards need Device Tree overlays? From the looks of it, the configuration
> of SOM + base board don't seem to change at runtime.
>
Indeed, a static configuration (DTS) would be enough now that I think about it.
>> So, answering your question right now this is not required but I thought it
>> would be good to have it configured by default in case someone using an IGEP0030
>> and a expansion board wants to extend omap3-igep0030.dts to add support for its
>> expansion board.
>
> I think all you need is a .dts file for each expansion board that extends
> omap3-iegp0030.dts.
>
> That way, the pinmux for USB host pins will come only in those boards that have the USB host port.
>
>>
>> I've no strong opinion on this though and I can send a new patch with those pins
>> moved to omap3-igep0020.dts though if you think that would be better.
>
> If you don't put it in omap3-igep0020.dts, how will you handle the case when a omap3-igep0030
> SOM is used with an expansion board that doesn't have USB host port and uses it for something
> else?
>
You are right, will change and post a v2 of the patch-set, thanks a lot for your
feedback!
>>
>>>> leds_pins: pinmux_leds_pins { };
>>>> };
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
>> b/arch/arm/boot/dts/omap3-igep0020.dts
>>>> index 903e944..180b186 100644
>>>> --- a/arch/arm/boot/dts/omap3-igep0020.dts
>>>> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>>>> @@ -55,6 +55,23 @@
>>>> regulator-name = "vdd33a";
>>>> regulator-always-on;
>>>> };
>>>> +
>>>> + /* HS USB Port 1 Power */
>>>> + hsusb1_power: hsusb1_power_reg {
>>>> + compatible = "regulator-fixed";
>>>> + regulator-name = "hsusb1_vbus";
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + gpio = <&twl_gpio 18 GPIO_ACTIVE_LOW>; /* GPIO LEDA */
>>>> + startup-delay-us = <70000>;
>>>> + };
>>>> +
>>>> + /* HS USB Host PHY on PORT 1 */
>>>> + hsusb1_phy: hsusb1_phy {
>>>> + compatible = "usb-nop-xceiv";
>>>> + reset-gpios = <&gpio1 24 GPIO_ACTIVE_LOW>; /* gpio_24 */
>>>> + vcc-supply = <&hsusb1_power>;
>>>> + };
>>>> };
>>>>
>>>> &leds_pins {
>>>> @@ -173,3 +190,11 @@
>>>> mode = <3>;
>>>> power = <50>;
>>>> };
>>>> +
>>>> +&usbhshost {
>>>> + port1-mode = "ehci-phy";
>>>> +};
>>>> +
>>>> +&usbhsehci {
>>>> + phys = <&hsusb1_phy>;
>>>> +};
>>>>
>>>
>
> cheers,
> -roger
>
>>> --
>>
>> Thanks a lot and best regards,
>> Javier
>>
>> [1]: http://www.isee.biz/products/processor-boards/igep-com-module
>> [2]: http://www.isee.biz/products/expansion-boards/product-igep-paris
>> [3]: http://www.isee.biz/products/expansion-boards/product-igep-berlin
>> [4]:
>> http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays
>>
>
Best regards,
Javier
next prev parent reply other threads:[~2013-10-07 9:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1380931479-16142-1-git-send-email-javier.martinez@collabora.co.uk>
[not found] ` <1380931479-16142-3-git-send-email-javier.martinez@collabora.co.uk>
[not found] ` <525271D5.9070009@ti.com>
[not found] ` <525275C8.2050208@collabora.co.uk>
[not found] ` <525275C8.2050208-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2013-10-07 9:06 ` [PATCH 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support Roger Quadros
2013-10-07 9:13 ` Javier Martinez Canillas [this message]
2013-10-07 10:22 ` Javier Martinez Canillas
2013-10-07 10:42 ` Roger Quadros
2013-10-07 11:53 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52527B21.5040602@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=eballetbo@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=rogerq@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).