From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY
Date: Mon, 10 Mar 2014 11:03:42 -0700 [thread overview]
Message-ID: <20140310180341.GC4882@atomide.com> (raw)
In-Reply-To: <531DD6A8.7010406@epfl.ch>
* Florian Vaussard <florian.vaussard@epfl.ch> [140310 08:17]:
> On 03/10/2014 11:30 AM, Roger Quadros wrote:
> >
> > If you don't use the OMAP3x30_CORE2_IOPAD() macro then these definitions can fit in omap3-overo-base.dtsi.
> > The offsets will be taken care of if you place them within &omap3_pmx_core2 {} . e.g.
> >
> > + 0x50 (PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */
> > + 0x52 (PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */
> > + 0x54 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d12.hsusb2_dir */
> > + 0x56 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d13.hsusb2_nxt */
> > + 0x58 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d14.hsusb2_data0 */
> > + 0x5a (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d15.hsusb2_data1 */
> >
> > Do you think this is better?
> >
>
> I do not think that this could work. Let's take for example hsusb2_clk
> et let's do the math. Here, 0x50 is the offset inside omap3_pmx_core2
> pinctrl, so:
>
> hsusb2_clk omap3_pmx_core2 hsusb2_clk
> offset base addr. PADCONF addr.
> ---- ---------- ----------
> OMAP34xx: 0x50 0x480025d8 0x48002628 *NO*
> OMAP36xx: 0x50 0x480025a0 0x480025F0 *ok*
>
> Looking at the TRM, the PADCONF address for hsusb2_clk is 0x480025F0 in
> both cases. Thus we will be wrong on OMAP34xx (offset should be 0x18
> instead of 0x50). Thus so far, I do not see any magical solution apart
> putting the omap3_pmx_core2 pins in a SoC-dependant .dtsi file.
>
> I already expressed my concerns [1] about having a different base
> address for omap3_pmx_core2 depending on the SoC (although I do
> understand the rational behind). This makes cross-SoC platforms more
> difficult to maintain.
Yeah the muxing should always be possible to do at board level.
Just the use of external pulls for some boards will make it hard
to have anything common. If you want something common, you can
have something like omap36xx-usb-xyz.dtsi as long as it's always
wired up the same way.
Regards,
Tony
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/289874
>
next prev parent reply other threads:[~2014-03-10 18:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 19:22 [PATCH v4 0/9] ARM: dts: Better support for Gumstix Overo (for 3.15?) Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 1/9] ARM: dts: overo: reorganize include files Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 2/9] ARM: dts: omap3-tobi: Add missing pinctrl Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 3/9] ARM: dts: omap3-overo: " Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 4/9] ARM: dts: omap3-overo: Enable WiFi/BT combo Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY Florian Vaussard
2014-03-10 10:30 ` Roger Quadros
2014-03-10 15:13 ` Florian Vaussard
2014-03-10 18:03 ` Tony Lindgren [this message]
2014-03-11 6:28 ` Florian Vaussard
2014-03-11 9:43 ` Roger Quadros
2014-03-12 17:19 ` Tony Lindgren
2014-03-13 8:29 ` Florian Vaussard
2014-03-11 9:43 ` Roger Quadros
2014-03-07 19:22 ` [PATCH v4 6/9] ARM: dts: omap: Add common file for SMSC9221 Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 7/9] ARM: dts: omap3-tobi: Use include file omap-gpmc-smsc9221 Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 8/9] ARM: dts: omap3-tobi: Add AT24C01 EEPROM Florian Vaussard
2014-03-07 19:22 ` [PATCH v4 9/9] ARM: dts: overo: Push uart3 pinmux down to expansion board Florian Vaussard
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=20140310180341.GC4882@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).