[PATCH v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY
Tony Lindgren
tony at atomide.com
Mon Mar 10 14:03:42 EDT 2014
* Florian Vaussard <florian.vaussard at 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
>
More information about the linux-arm-kernel
mailing list