Enabling USBH1 on mx53qsb

Arnaud Patard (Rtp) arnaud.patard at rtp-net.org
Thu Jul 25 10:03:10 EDT 2013


Fabio Estevam <festevam at gmail.com> writes:

> Hi,

Hi,
>
> I am trying to get USBH1 port to work on mx53qsb (with Dialog pmic)
> with the following patch against linux-next-20130724:

I've been trying to reach the same goal for quite some time without
success (on the same version of the mx53qsb).
>
> --- a/arch/arm/boot/dts/imx53-qsb.dts
> +++ b/arch/arm/boot/dts/imx53-qsb.dts
> @@ -93,6 +93,15 @@
>                         regulator-max-microvolt = <3200000>;
>                         regulator-always-on;
>                 };
> +
> +               reg_usb_vbus: usb_vbus {
> +                       compatible = "regulator-fixed";
> +                       regulator-name = "usb_vbus";
> +                       regulator-min-microvolt = <5000000>;
> +                       regulator-max-microvolt = <5000000>;
> +                       gpio = <&gpio7 8 0>;
> +                       enable-active-high;
> +               };
>         };
>
>         sound {
> @@ -145,6 +154,7 @@
>                                 MX53_PAD_EIM_DA12__GPIO3_12       0x80000000
>                                 MX53_PAD_EIM_DA13__GPIO3_13       0x80000000
>                                 MX53_PAD_PATA_DA_0__GPIO7_6       0x80000000
> +                               MX53_PAD_PATA_DA_2__GPIO7_8       0x80000000
>                                 MX53_PAD_GPIO_16__GPIO7_11        0x80000000
>                         >;
>                 };
> @@ -302,7 +312,8 @@
>  };
>
>  &usbh1 {
> -       status = "okay";
> +       vbus-supply = <&reg_usb_vbus>;
> +       status = "okay";

I tried also with:
+       phy_type = "utmi_wide";
+       dr_mode = "host";

but nothing.

>  };
>
>  &usbotg {
>
>
> mx53qsb board has two USB host ports:
>
> - The top port is USBH1
> - The bottom port is OTG (also shared with J3 connector)
>
> After applying the above patch the OTG port does work, but the USBH1
> does not.

Given that the same gpio controls vbus for both ports, my current guess
is something on port configuration side (I guess the board would freeze
hard if a clock is not enabled).


Arnaud



More information about the linux-arm-kernel mailing list