Re: [U-Boot] [PATCH v3 3/3] imx:mx6slevk add board level support for usb

2014-11-07 Thread Peng Fan



在 11/7/2014 7:10 PM, Marek Vasut 写道:

On Friday, November 07, 2014 at 12:08:03 PM, Peng Fan wrote:

在 11/7/2014 4:26 PM, Marek Vasut 写道:

On Friday, November 07, 2014 at 02:08:14 AM, Peng Fan wrote:

Add pinmux settings, implement board_ehci_hcd_init, board_usb_phy_mode

There are two usb port on mx6slevk board:
1. otg port
2. host port
The following are the connection between usb controller and board usb
interface, host port has not ID pin set:
otg1 core <---> board otg port
otg2 core <---> board host port
In order to make host port work, board_usb_phy_mode return 0 to let
ehci-mx6.c driver decide otg2 core to works in host mode.

Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
---


[...]


@@ -150,6 +151,63 @@ static int setup_fec(void)

   }
   #endif

+#ifdef CONFIG_USB_EHCI_MX6
+#define USB_OTHERREGS_OFFSET   0x800
+#define USBPHY_CTRL0x30
+#define UCTRL_PWR_POL  (1 << 9)
+#define USBPHY_CTRL_OTG_ID 0x0800


This looks like an duplication. Aren't those bits defined somewhere in
generic code already ?


If this way 'int board_usb_phy_mode(int port, enum usb_init_type *type)'
can be accpeted, these bits are not needed and I'll move these bits in
the seperate PHY register struct access patch. Anyway, after the board
level usb support patch.


What about abstracting that stuff into a function which returns the PHY's
idea of the current mode instead. That way, you can determine the PHY's
idea of the mode from both board code and the driver code.

struct phy register is good, but I prefer not to include this in board 
level code, see my reply in this patch "usb:ehci-mx6 add 
board_usb_phy_mode function" just as "board_ehci_power" and 
"board_ehci_hcd_init" do. I think it is good to make it a seperate patch.

Best regards,
Marek Vasut


Regards,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] imx:mx6slevk add board level support for usb

2014-11-07 Thread Marek Vasut
On Friday, November 07, 2014 at 12:08:03 PM, Peng Fan wrote:
> 在 11/7/2014 4:26 PM, Marek Vasut 写道:
> > On Friday, November 07, 2014 at 02:08:14 AM, Peng Fan wrote:
> >> Add pinmux settings, implement board_ehci_hcd_init, board_usb_phy_mode
> >> 
> >> There are two usb port on mx6slevk board:
> >> 1. otg port
> >> 2. host port
> >> The following are the connection between usb controller and board usb
> >> interface, host port has not ID pin set:
> >> otg1 core <---> board otg port
> >> otg2 core <---> board host port
> >> In order to make host port work, board_usb_phy_mode return 0 to let
> >> ehci-mx6.c driver decide otg2 core to works in host mode.
> >> 
> >> Signed-off-by: Peng Fan 
> >> Signed-off-by: Ye Li 
> >> ---
> > 
> > [...]
> > 
> >> @@ -150,6 +151,63 @@ static int setup_fec(void)
> >> 
> >>   }
> >>   #endif
> >> 
> >> +#ifdef CONFIG_USB_EHCI_MX6
> >> +#define USB_OTHERREGS_OFFSET  0x800
> >> +#define USBPHY_CTRL   0x30
> >> +#define UCTRL_PWR_POL (1 << 9)
> >> +#define USBPHY_CTRL_OTG_ID0x0800
> > 
> > This looks like an duplication. Aren't those bits defined somewhere in
> > generic code already ?
> 
> If this way 'int board_usb_phy_mode(int port, enum usb_init_type *type)'
> can be accpeted, these bits are not needed and I'll move these bits in
> the seperate PHY register struct access patch. Anyway, after the board
> level usb support patch.

What about abstracting that stuff into a function which returns the PHY's
idea of the current mode instead. That way, you can determine the PHY's
idea of the mode from both board code and the driver code.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] imx:mx6slevk add board level support for usb

2014-11-07 Thread Peng Fan



在 11/7/2014 4:26 PM, Marek Vasut 写道:

On Friday, November 07, 2014 at 02:08:14 AM, Peng Fan wrote:

Add pinmux settings, implement board_ehci_hcd_init, board_usb_phy_mode

There are two usb port on mx6slevk board:
1. otg port
2. host port
The following are the connection between usb controller and board usb
interface, host port has not ID pin set:
otg1 core <---> board otg port
otg2 core <---> board host port
In order to make host port work, board_usb_phy_mode return 0 to let
ehci-mx6.c driver decide otg2 core to works in host mode.

Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
---


[...]


@@ -150,6 +151,63 @@ static int setup_fec(void)
  }
  #endif

+#ifdef CONFIG_USB_EHCI_MX6
+#define USB_OTHERREGS_OFFSET   0x800
+#define USBPHY_CTRL0x30
+#define UCTRL_PWR_POL  (1 << 9)
+#define USBPHY_CTRL_OTG_ID 0x0800


This looks like an duplication. Aren't those bits defined somewhere in
generic code already ?
If this way 'int board_usb_phy_mode(int port, enum usb_init_type *type)' 
can be accpeted, these bits are not needed and I'll move these bits in 
the seperate PHY register struct access patch. Anyway, after the board 
level usb support patch.

[...]
Best regards,
Marek Vasut


Regards,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] imx:mx6slevk add board level support for usb

2014-11-07 Thread Marek Vasut
On Friday, November 07, 2014 at 02:08:14 AM, Peng Fan wrote:
> Add pinmux settings, implement board_ehci_hcd_init, board_usb_phy_mode
> 
> There are two usb port on mx6slevk board:
> 1. otg port
> 2. host port
> The following are the connection between usb controller and board usb
> interface, host port has not ID pin set:
> otg1 core <---> board otg port
> otg2 core <---> board host port
> In order to make host port work, board_usb_phy_mode return 0 to let
> ehci-mx6.c driver decide otg2 core to works in host mode.
> 
> Signed-off-by: Peng Fan 
> Signed-off-by: Ye Li 
> ---

[...]

> @@ -150,6 +151,63 @@ static int setup_fec(void)
>  }
>  #endif
> 
> +#ifdef CONFIG_USB_EHCI_MX6
> +#define USB_OTHERREGS_OFFSET 0x800
> +#define USBPHY_CTRL  0x30
> +#define UCTRL_PWR_POL(1 << 9)
> +#define USBPHY_CTRL_OTG_ID   0x0800

This looks like an duplication. Aren't those bits defined somewhere in
generic code already ?
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot