linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
Date: Wed, 17 Apr 2013 10:11:32 -0700	[thread overview]
Message-ID: <20130417171132.GY10155@atomide.com> (raw)
In-Reply-To: <516E94FA.9060606@compulab.co.il>

* Igor Grinberg <grinberg@compulab.co.il> [130417 05:31]:
> On 04/17/13 11:38, Roger Quadros wrote:
> > On 04/17/2013 10:56 AM, Igor Grinberg wrote:
> >> On 04/17/13 04:30, Robert Nelson wrote:
> >>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>>> * Roger Quadros <rogerq@ti.com> [130415 05:44]:
> >>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
> >>>>>> Provide RESET and Power regulators for the USB PHY,
> >>>>>> the USB Host port mode and the PHY device.
> >>>>>>
> >>>>>> Also provide pin multiplexer information for USB host
> >>>>>> pins.
> >>>>>>
> >>>>>> This will not work for Rev Cx boards because of reversed logic
> >>>>>> for USB_POWER_Enable.
> >>>>>>
> >>>>>> CC: Beno?t Cousson <b-cousson@ti.com>
> >>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >>>>>> ---
> >>>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
> >>>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> index 5a31964..d394c51 100644
> >>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >>>>>> @@ -57,6 +57,60 @@
> >>>>>>             ti,mcbsp = <&mcbsp2>;
> >>>>>>             ti,codec = <&twl_audio>;
> >>>>>>     };
> >>>>>> +
> >>>>>> +   /* HS USB Port 2 RESET */
> >>>>>> +   hsusb2_reset: hsusb2_reset_reg {
> >>>>>> +           compatible = "regulator-fixed";
> >>>>>> +           regulator-name = "hsusb2_reset";
> >>>>>> +           regulator-min-microvolt = <3300000>;
> >>>>>> +           regulator-max-microvolt = <3300000>;
> >>>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
> >>>>>> +           startup-delay-us = <70000>;
> >>>>>> +           enable-active-high;
> >>>>>> +   };
> >>>>>> +
> >>>>>> +   /* HS USB Port 2 Power */
> >>>>>> +   hsusb2_power: hsusb2_power_reg {
> >>>>>> +           compatible = "regulator-fixed";
> >>>>>> +           regulator-name = "hsusb2_vbus";
> >>>>>> +           regulator-min-microvolt = <3300000>;
> >>>>>> +           regulator-max-microvolt = <3300000>;
> >>>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
> >>>>>> +           startup-delay-us = <70000>;
> >>>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
> >>>>>
> >>>>> Benoit & Tony,
> >>>>>
> >>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
> >>>>
> >>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
> >>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
> >>>
> >>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
> >>> there is the "rev c" variant of the original beagle...
> >>>
> >>> It's too bad we can't read the 3 gpio pin states in the device tree
> >>> and make a decision.
> >>
> >> I would recommend to move the detection to the boot loader and
> >> adjust the DT blob at run time (in the boot loader).
> >> This way, we will not need to deal with all the (sub)revision stuff.
> >>
> >>
> > Moving the detection to bootloader is fine, but modifying the DT at
> > runtime would create a debug/maintenance issue. Instead it could just
> > pick one of the .DTBs and pass it to kernel.
> 
> Like this will not create create any debug/maintenance issues.... ;-)
> We have no problem with debug, as all the DT nodes can be seen in
> both U-Boot (with fdt commands) and Linux through procfs...
> 
> I've just dropped my 2 cents and I don't really insist...

The dynamic configuration from the bootloader can also be done too, I
don't think they are mutually exclusive. 
 
> > Since most users will be using rev-c, I think we should keep the original
> > file 'omap3-beagle-xm.dts" as it is for rev-c boards.
> > I can just create a new dts file for Revisions A and B that will be
> > like so.
> > 
> > +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
> > @@ -0,0 +1,6 @@
> > +/include/ "omap3-beagle-xm.dts"
> > +
> > +/* On Rev A/B USBHOST_PWR_EN is active high */
> > +&hsusb2_power {
> > +       enable-active-high;
> > +};
> > 
> > Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
> > quite many differences, I don't think it is a good idea to create a common
> > file between the two.

Sounds good to me. But please also add the revision info to the compatible
flags for both .dts files.

Regards,

Tony

      reply	other threads:[~2013-04-17 17:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-15 12:35 [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx Roger Quadros
2013-04-15 12:39 ` Roger Quadros
2013-04-17  0:52   ` Tony Lindgren
2013-04-17  1:30     ` Robert Nelson
2013-04-17  7:56       ` Igor Grinberg
2013-04-17  8:38         ` Roger Quadros
2013-04-17 12:26           ` Igor Grinberg
2013-04-17 17:11             ` Tony Lindgren [this message]

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=20130417171132.GY10155@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).