diff mbox

[U-Boot,v3,3/3] arm: odroid: usb: add support for usb host including ethernet

Message ID 1414599763-15861-3-git-send-email-suriyan.r@gmail.com
State Accepted
Delegated to: Minkyu Kang
Headers show

Commit Message

Suriyan Ramasami Oct. 29, 2014, 4:22 p.m. UTC
This change adds support for enabling the USB host features of the board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>

---

Changes in v3:
* removed set_usb_ethaddr() and related code as the GUID registers do not
  seem to be documented anywhere. This is sad, as this mechanism allows
  for each Odroid to boot up with the same MAC address every time, but no
  two odroids shall have the same MAC address on boot. This ensures multiple
  odroids in the same LAN to come up without conflicting MAC addresses.
* Minkyu - Do not mix cpu_is... and proid_is...

Changes in v2:
* Jaehoon - Split power.[ch] as a separate patch
* Removed an unneeded header file from ehci-exynos.c
* Jaehoon - Fix indentation in the dts file

Changes in v1:
* First try

 arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
 arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
 board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
 drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
 include/configs/odroid.h                | 13 ++++++++
 5 files changed, 116 insertions(+), 8 deletions(-)

Comments

Jaehoon Chung Oct. 30, 2014, 1:17 a.m. UTC | #1
On 10/30/2014 01:22 AM, Suriyan Ramasami wrote:
> This change adds support for enabling the USB host features of the board.
> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
> as well.
> 
> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
> 
> ---
> 
> Changes in v3:
> * removed set_usb_ethaddr() and related code as the GUID registers do not
>   seem to be documented anywhere. This is sad, as this mechanism allows
>   for each Odroid to boot up with the same MAC address every time, but no
>   two odroids shall have the same MAC address on boot. This ensures multiple
>   odroids in the same LAN to come up without conflicting MAC addresses.
> * Minkyu - Do not mix cpu_is... and proid_is...
> 
> Changes in v2:
> * Jaehoon - Split power.[ch] as a separate patch
> * Removed an unneeded header file from ehci-exynos.c
> * Jaehoon - Fix indentation in the dts file
> 
> Changes in v1:
> * First try
> 
>  arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>  arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>  board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>  drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>  include/configs/odroid.h                | 13 ++++++++
>  5 files changed, 116 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/dts/exynos4412-odroid.dts b/arch/arm/dts/exynos4412-odroid.dts
> index 4c5e2b3..2df1801 100644
> --- a/arch/arm/dts/exynos4412-odroid.dts
> +++ b/arch/arm/dts/exynos4412-odroid.dts
> @@ -67,4 +67,15 @@
>  		div = <0x3>;
>  		index = <4>;
>  	};
> +
> +	ehci@12580000 {
> +		compatible = "samsung,exynos-ehci";
> +		reg = <0x12580000 0x100>;
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		phy {
> +			compatible = "samsung,exynos-usb-phy";
> +			reg = <0x125B0000 0x100>;
> +		};
> +	};
>  };
> diff --git a/arch/arm/include/asm/arch-exynos/ehci.h b/arch/arm/include/asm/arch-exynos/ehci.h
> index d2d70bd..3800fa9 100644
> --- a/arch/arm/include/asm/arch-exynos/ehci.h
> +++ b/arch/arm/include/asm/arch-exynos/ehci.h
> @@ -12,6 +12,13 @@
>  
>  #define CLK_24MHZ		5
>  
> +#define PHYPWR_NORMAL_MASK_PHY0                 (0x39 << 0)
> +#define PHYPWR_NORMAL_MASK_PHY1                 (0x7 << 6)
> +#define PHYPWR_NORMAL_MASK_HSIC0                (0x7 << 9)
> +#define PHYPWR_NORMAL_MASK_HSIC1                (0x7 << 12)
> +#define RSTCON_HOSTPHY_SWRST                    (0xf << 3)
> +#define RSTCON_SWRST                            (0x1 << 0)
> +
>  #define HOST_CTRL0_PHYSWRSTALL			(1 << 31)
>  #define HOST_CTRL0_COMMONON_N			(1 << 9)
>  #define HOST_CTRL0_SIDDQ			(1 << 6)
> @@ -61,6 +68,12 @@ struct exynos_usb_phy {
>  	unsigned int usbotgtune;
>  };
>  
> +struct exynos4412_usb_phy {
> +	unsigned int usbphyctrl;
> +	unsigned int usbphyclk;
> +	unsigned int usbphyrstcon;
> +};
> +
>  /* Switch on the VBUS power. */
>  int board_usb_vbus_init(void);
>  
> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
> index 5edb250..d671f13 100644
> --- a/board/samsung/odroid/odroid.c
> +++ b/board/samsung/odroid/odroid.c
> @@ -453,9 +453,41 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
>  	.usb_phy_ctrl	= EXYNOS4X12_USBPHY_CONTROL,
>  	.usb_flags	= PHY0_SLEEP,
>  };
> +#endif
> +
> +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
>  
>  int board_usb_init(int index, enum usb_init_type init)
>  {
> +#ifdef CONFIG_CMD_USB
> +	struct pmic *p_pmic;
> +
> +	/* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
> +	/* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
> +	if (gd->board_type == ODROID_TYPE_U3)
> +		gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
> +	else
> +		gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
> +
> +	/* Disconnect, Reset, Connect */
> +	gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
> +	gpio_direction_output(EXYNOS4X12_GPIO_X35, 0);
> +	gpio_direction_output(EXYNOS4X12_GPIO_X35, 1);
> +	gpio_direction_output(EXYNOS4X12_GPIO_X34, 1);
> +
> +	/* Power off and on BUCK8 for LAN9730 */
> +	debug("LAN9730 - Turning power buck 8 OFF and ON.\n");
> +
> +	p_pmic = pmic_get("MAX77686_PMIC");
> +	if (p_pmic && !pmic_probe(p_pmic)) {
> +		max77686_set_buck_mode(p_pmic, 8, OPMODE_OFF);
> +		max77686_set_buck_voltage(p_pmic, 8, 750000);
> +		max77686_set_buck_voltage(p_pmic, 8, 3300000);
> +		max77686_set_buck_mode(p_pmic, 8, OPMODE_ON);
> +	}
> +
> +#endif
> +
>  	debug("USB_udc_probe\n");
>  	return s3c_udc_probe(&s5pc210_otg_data);
>  }
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index edd91a8..6fdbf57 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -85,15 +85,10 @@ static int exynos_usb_parse_dt(const void *blob, struct exynos_ehci *exynos)
>  }
>  #endif
>  
> -/* Setup the EHCI host controller. */
> -static void setup_usb_phy(struct exynos_usb_phy *usb)
> +static void exynos5_setup_usb_phy(struct exynos_usb_phy *usb)
>  {
>  	u32 hsic_ctrl;
>  
> -	set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
> -
> -	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
> -
>  	clrbits_le32(&usb->usbphyctrl0,
>  			HOST_CTRL0_FSEL_MASK |
>  			HOST_CTRL0_COMMONON_N |
> @@ -150,8 +145,34 @@ static void setup_usb_phy(struct exynos_usb_phy *usb)
>  			EHCICTRL_ENAINCR16);
>  }
>  
> -/* Reset the EHCI host controller. */
> -static void reset_usb_phy(struct exynos_usb_phy *usb)
> +static void exynos4412_setup_usb_phy(struct exynos4412_usb_phy *usb)
> +{
> +	writel(CLK_24MHZ, &usb->usbphyclk);
> +
> +	clrbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
> +		PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
> +		PHYPWR_NORMAL_MASK_PHY0));
> +
> +	setbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
> +	udelay(10);
> +	clrbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
> +}
> +
> +static void setup_usb_phy(struct exynos_usb_phy *usb)
> +{

Well, I didn't know exactly. but i think this is something strange.
is it always bypassed the "struct exynos_usb_phy"?

And don't need to modify the below code into exynos_usb_parse_dt()?
	
	/*
	 * Get the base address for usbphy from the device node
	 */
	exynos->usb = (struct exynos_usb_phy *)fdtdec_get_addr(blob, node,
								"reg");
	if (exynos->usb == NULL) {
		debug("Can't get the usbphy register address\n");
		return -ENXIO;
	}

Best Regards,
Jaehoon Chung

> +	set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
> +
> +	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
> +
> +	if (cpu_is_exynos5())
> +		exynos5_setup_usb_phy(usb);
> +	else if (cpu_is_exynos4())
> +		if (proid_is_exynos4412())
> +			exynos4412_setup_usb_phy((struct exynos4412_usb_phy *)
> +						 usb);
> +}
> +
> +static void exynos5_reset_usb_phy(struct exynos_usb_phy *usb)
>  {
>  	u32 hsic_ctrl;
>  
> @@ -171,6 +192,24 @@ static void reset_usb_phy(struct exynos_usb_phy *usb)
>  
>  	setbits_le32(&usb->hsicphyctrl1, hsic_ctrl);
>  	setbits_le32(&usb->hsicphyctrl2, hsic_ctrl);
> +}
> +
> +static void exynos4412_reset_usb_phy(struct exynos4412_usb_phy *usb)
> +{
> +	setbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
> +		PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
> +		PHYPWR_NORMAL_MASK_PHY0));
> +}
> +
> +/* Reset the EHCI host controller. */
> +static void reset_usb_phy(struct exynos_usb_phy *usb)
> +{
> +	if (cpu_is_exynos5())
> +		exynos5_reset_usb_phy(usb);
> +	else if (cpu_is_exynos4())
> +		if (proid_is_exynos4412())
> +			exynos4412_reset_usb_phy((struct exynos4412_usb_phy *)
> +						 usb);
>  
>  	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_DISABLE);
>  }
> diff --git a/include/configs/odroid.h b/include/configs/odroid.h
> index b928af8..807e96b 100644
> --- a/include/configs/odroid.h
> +++ b/include/configs/odroid.h
> @@ -198,6 +198,19 @@
>  
>  #define CONFIG_CMD_GPIO
>  
> +/* USB */
> +#define CONFIG_CMD_USB
> +#define CONFIG_USB_EHCI
> +#define CONFIG_USB_EHCI_EXYNOS
> +#define CONFIG_USB_STORAGE
> +
> +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS	3
> +#define CONFIG_CMD_NET
> +#define CONFIG_CMD_PING
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_USB_HOST_ETHER
> +#define CONFIG_USB_ETHER_SMSC95XX
> +
>  /*
>   * Supported Odroid boards: X3, U3
>   * TODO: Add Odroid X support
>
Suriyan Ramasami Oct. 30, 2014, 4:40 a.m. UTC | #2
Hello Jaehoon Chung,

On Wed, Oct 29, 2014 at 6:17 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> On 10/30/2014 01:22 AM, Suriyan Ramasami wrote:
>> This change adds support for enabling the USB host features of the board.
>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>> as well.
>>
>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>
>> ---
>>
>> Changes in v3:
>> * removed set_usb_ethaddr() and related code as the GUID registers do not
>>   seem to be documented anywhere. This is sad, as this mechanism allows
>>   for each Odroid to boot up with the same MAC address every time, but no
>>   two odroids shall have the same MAC address on boot. This ensures multiple
>>   odroids in the same LAN to come up without conflicting MAC addresses.
>> * Minkyu - Do not mix cpu_is... and proid_is...
>>
>> Changes in v2:
>> * Jaehoon - Split power.[ch] as a separate patch
>> * Removed an unneeded header file from ehci-exynos.c
>> * Jaehoon - Fix indentation in the dts file
>>
>> Changes in v1:
>> * First try
>>
>>  arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>  arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>  board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>  drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>>  include/configs/odroid.h                | 13 ++++++++
>>  5 files changed, 116 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/dts/exynos4412-odroid.dts b/arch/arm/dts/exynos4412-odroid.dts
>> index 4c5e2b3..2df1801 100644
>> --- a/arch/arm/dts/exynos4412-odroid.dts
>> +++ b/arch/arm/dts/exynos4412-odroid.dts
>> @@ -67,4 +67,15 @@
>>               div = <0x3>;
>>               index = <4>;
>>       };
>> +
>> +     ehci@12580000 {
>> +             compatible = "samsung,exynos-ehci";
>> +             reg = <0x12580000 0x100>;
>> +             #address-cells = <1>;
>> +             #size-cells = <1>;
>> +             phy {
>> +                     compatible = "samsung,exynos-usb-phy";
>> +                     reg = <0x125B0000 0x100>;
>> +             };
>> +     };
>>  };
>> diff --git a/arch/arm/include/asm/arch-exynos/ehci.h b/arch/arm/include/asm/arch-exynos/ehci.h
>> index d2d70bd..3800fa9 100644
>> --- a/arch/arm/include/asm/arch-exynos/ehci.h
>> +++ b/arch/arm/include/asm/arch-exynos/ehci.h
>> @@ -12,6 +12,13 @@
>>
>>  #define CLK_24MHZ            5
>>
>> +#define PHYPWR_NORMAL_MASK_PHY0                 (0x39 << 0)
>> +#define PHYPWR_NORMAL_MASK_PHY1                 (0x7 << 6)
>> +#define PHYPWR_NORMAL_MASK_HSIC0                (0x7 << 9)
>> +#define PHYPWR_NORMAL_MASK_HSIC1                (0x7 << 12)
>> +#define RSTCON_HOSTPHY_SWRST                    (0xf << 3)
>> +#define RSTCON_SWRST                            (0x1 << 0)
>> +
>>  #define HOST_CTRL0_PHYSWRSTALL                       (1 << 31)
>>  #define HOST_CTRL0_COMMONON_N                        (1 << 9)
>>  #define HOST_CTRL0_SIDDQ                     (1 << 6)
>> @@ -61,6 +68,12 @@ struct exynos_usb_phy {
>>       unsigned int usbotgtune;
>>  };
>>
>> +struct exynos4412_usb_phy {
>> +     unsigned int usbphyctrl;
>> +     unsigned int usbphyclk;
>> +     unsigned int usbphyrstcon;
>> +};
>> +
>>  /* Switch on the VBUS power. */
>>  int board_usb_vbus_init(void);
>>
>> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
>> index 5edb250..d671f13 100644
>> --- a/board/samsung/odroid/odroid.c
>> +++ b/board/samsung/odroid/odroid.c
>> @@ -453,9 +453,41 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
>>       .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
>>       .usb_flags      = PHY0_SLEEP,
>>  };
>> +#endif
>> +
>> +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
>>
>>  int board_usb_init(int index, enum usb_init_type init)
>>  {
>> +#ifdef CONFIG_CMD_USB
>> +     struct pmic *p_pmic;
>> +
>> +     /* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
>> +     /* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
>> +     if (gd->board_type == ODROID_TYPE_U3)
>> +             gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
>> +     else
>> +             gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
>> +
>> +     /* Disconnect, Reset, Connect */
>> +     gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
>> +     gpio_direction_output(EXYNOS4X12_GPIO_X35, 0);
>> +     gpio_direction_output(EXYNOS4X12_GPIO_X35, 1);
>> +     gpio_direction_output(EXYNOS4X12_GPIO_X34, 1);
>> +
>> +     /* Power off and on BUCK8 for LAN9730 */
>> +     debug("LAN9730 - Turning power buck 8 OFF and ON.\n");
>> +
>> +     p_pmic = pmic_get("MAX77686_PMIC");
>> +     if (p_pmic && !pmic_probe(p_pmic)) {
>> +             max77686_set_buck_mode(p_pmic, 8, OPMODE_OFF);
>> +             max77686_set_buck_voltage(p_pmic, 8, 750000);
>> +             max77686_set_buck_voltage(p_pmic, 8, 3300000);
>> +             max77686_set_buck_mode(p_pmic, 8, OPMODE_ON);
>> +     }
>> +
>> +#endif
>> +
>>       debug("USB_udc_probe\n");
>>       return s3c_udc_probe(&s5pc210_otg_data);
>>  }
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index edd91a8..6fdbf57 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -85,15 +85,10 @@ static int exynos_usb_parse_dt(const void *blob, struct exynos_ehci *exynos)
>>  }
>>  #endif
>>
>> -/* Setup the EHCI host controller. */
>> -static void setup_usb_phy(struct exynos_usb_phy *usb)
>> +static void exynos5_setup_usb_phy(struct exynos_usb_phy *usb)
>>  {
>>       u32 hsic_ctrl;
>>
>> -     set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
>> -
>> -     set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
>> -
>>       clrbits_le32(&usb->usbphyctrl0,
>>                       HOST_CTRL0_FSEL_MASK |
>>                       HOST_CTRL0_COMMONON_N |
>> @@ -150,8 +145,34 @@ static void setup_usb_phy(struct exynos_usb_phy *usb)
>>                       EHCICTRL_ENAINCR16);
>>  }
>>
>> -/* Reset the EHCI host controller. */
>> -static void reset_usb_phy(struct exynos_usb_phy *usb)
>> +static void exynos4412_setup_usb_phy(struct exynos4412_usb_phy *usb)
>> +{
>> +     writel(CLK_24MHZ, &usb->usbphyclk);
>> +
>> +     clrbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
>> +             PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
>> +             PHYPWR_NORMAL_MASK_PHY0));
>> +
>> +     setbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
>> +     udelay(10);
>> +     clrbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
>> +}
>> +
>> +static void setup_usb_phy(struct exynos_usb_phy *usb)
>> +{
>
> Well, I didn't know exactly. but i think this is something strange.
> is it always bypassed the "struct exynos_usb_phy"?
>
> And don't need to modify the below code into exynos_usb_parse_dt()?
>
>         /*
>          * Get the base address for usbphy from the device node
>          */
>         exynos->usb = (struct exynos_usb_phy *)fdtdec_get_addr(blob, node,
>                                                                 "reg");
>         if (exynos->usb == NULL) {
>                 debug("Can't get the usbphy register address\n");
>                 return -ENXIO;
>         }

Well, its a pointer and its cast to (exynos4412_usb_phy *) later on
(in function setup_usb_phy()).

If this cast looks funky, we could change exynos->usb to be of type
void * and cast it to appropriate (exynos4_usb_phy *)  or
(exynos4412_us_phy *) as needed.

I do not know which is preferable. As far as I see it, its a pointer,
and depending on the SoC we cast it differently.

Please let me know if you have any ideas of how you want to change it
for it to be less confusing (if that is indeed the case).

Thanks
- Suriyan

>
> Best Regards,
> Jaehoon Chung
>
>> +     set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
>> +
>> +     set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
>> +
>> +     if (cpu_is_exynos5())
>> +             exynos5_setup_usb_phy(usb);
>> +     else if (cpu_is_exynos4())
>> +             if (proid_is_exynos4412())
>> +                     exynos4412_setup_usb_phy((struct exynos4412_usb_phy *)
>> +                                              usb);
>> +}
>> +
>> +static void exynos5_reset_usb_phy(struct exynos_usb_phy *usb)
>>  {
>>       u32 hsic_ctrl;
>>
>> @@ -171,6 +192,24 @@ static void reset_usb_phy(struct exynos_usb_phy *usb)
>>
>>       setbits_le32(&usb->hsicphyctrl1, hsic_ctrl);
>>       setbits_le32(&usb->hsicphyctrl2, hsic_ctrl);
>> +}
>> +
>> +static void exynos4412_reset_usb_phy(struct exynos4412_usb_phy *usb)
>> +{
>> +     setbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
>> +             PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
>> +             PHYPWR_NORMAL_MASK_PHY0));
>> +}
>> +
>> +/* Reset the EHCI host controller. */
>> +static void reset_usb_phy(struct exynos_usb_phy *usb)
>> +{
>> +     if (cpu_is_exynos5())
>> +             exynos5_reset_usb_phy(usb);
>> +     else if (cpu_is_exynos4())
>> +             if (proid_is_exynos4412())
>> +                     exynos4412_reset_usb_phy((struct exynos4412_usb_phy *)
>> +                                              usb);
>>
>>       set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_DISABLE);
>>  }
>> diff --git a/include/configs/odroid.h b/include/configs/odroid.h
>> index b928af8..807e96b 100644
>> --- a/include/configs/odroid.h
>> +++ b/include/configs/odroid.h
>> @@ -198,6 +198,19 @@
>>
>>  #define CONFIG_CMD_GPIO
>>
>> +/* USB */
>> +#define CONFIG_CMD_USB
>> +#define CONFIG_USB_EHCI
>> +#define CONFIG_USB_EHCI_EXYNOS
>> +#define CONFIG_USB_STORAGE
>> +
>> +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS   3
>> +#define CONFIG_CMD_NET
>> +#define CONFIG_CMD_PING
>> +#define CONFIG_CMD_DHCP
>> +#define CONFIG_USB_HOST_ETHER
>> +#define CONFIG_USB_ETHER_SMSC95XX
>> +
>>  /*
>>   * Supported Odroid boards: X3, U3
>>   * TODO: Add Odroid X support
>>
>
Suriyan Ramasami Oct. 30, 2014, 5:11 a.m. UTC | #3
On Wed, Oct 29, 2014 at 9:40 PM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> Hello Jaehoon Chung,
>
> On Wed, Oct 29, 2014 at 6:17 PM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> On 10/30/2014 01:22 AM, Suriyan Ramasami wrote:
>>> This change adds support for enabling the USB host features of the board.
>>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>>> as well.
>>>
>>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>>
>>> ---
>>>
>>> Changes in v3:
>>> * removed set_usb_ethaddr() and related code as the GUID registers do not
>>>   seem to be documented anywhere. This is sad, as this mechanism allows
>>>   for each Odroid to boot up with the same MAC address every time, but no
>>>   two odroids shall have the same MAC address on boot. This ensures multiple
>>>   odroids in the same LAN to come up without conflicting MAC addresses.
>>> * Minkyu - Do not mix cpu_is... and proid_is...
>>>
>>> Changes in v2:
>>> * Jaehoon - Split power.[ch] as a separate patch
>>> * Removed an unneeded header file from ehci-exynos.c
>>> * Jaehoon - Fix indentation in the dts file
>>>
>>> Changes in v1:
>>> * First try
>>>
>>>  arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>>  arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>>  board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>>  drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>>>  include/configs/odroid.h                | 13 ++++++++
>>>  5 files changed, 116 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/exynos4412-odroid.dts b/arch/arm/dts/exynos4412-odroid.dts
>>> index 4c5e2b3..2df1801 100644
>>> --- a/arch/arm/dts/exynos4412-odroid.dts
>>> +++ b/arch/arm/dts/exynos4412-odroid.dts
>>> @@ -67,4 +67,15 @@
>>>               div = <0x3>;
>>>               index = <4>;
>>>       };
>>> +
>>> +     ehci@12580000 {
>>> +             compatible = "samsung,exynos-ehci";
>>> +             reg = <0x12580000 0x100>;
>>> +             #address-cells = <1>;
>>> +             #size-cells = <1>;
>>> +             phy {
>>> +                     compatible = "samsung,exynos-usb-phy";
>>> +                     reg = <0x125B0000 0x100>;
>>> +             };
>>> +     };
>>>  };
>>> diff --git a/arch/arm/include/asm/arch-exynos/ehci.h b/arch/arm/include/asm/arch-exynos/ehci.h
>>> index d2d70bd..3800fa9 100644
>>> --- a/arch/arm/include/asm/arch-exynos/ehci.h
>>> +++ b/arch/arm/include/asm/arch-exynos/ehci.h
>>> @@ -12,6 +12,13 @@
>>>
>>>  #define CLK_24MHZ            5
>>>
>>> +#define PHYPWR_NORMAL_MASK_PHY0                 (0x39 << 0)
>>> +#define PHYPWR_NORMAL_MASK_PHY1                 (0x7 << 6)
>>> +#define PHYPWR_NORMAL_MASK_HSIC0                (0x7 << 9)
>>> +#define PHYPWR_NORMAL_MASK_HSIC1                (0x7 << 12)
>>> +#define RSTCON_HOSTPHY_SWRST                    (0xf << 3)
>>> +#define RSTCON_SWRST                            (0x1 << 0)
>>> +
>>>  #define HOST_CTRL0_PHYSWRSTALL                       (1 << 31)
>>>  #define HOST_CTRL0_COMMONON_N                        (1 << 9)
>>>  #define HOST_CTRL0_SIDDQ                     (1 << 6)
>>> @@ -61,6 +68,12 @@ struct exynos_usb_phy {
>>>       unsigned int usbotgtune;
>>>  };
>>>
>>> +struct exynos4412_usb_phy {
>>> +     unsigned int usbphyctrl;
>>> +     unsigned int usbphyclk;
>>> +     unsigned int usbphyrstcon;
>>> +};
>>> +
>>>  /* Switch on the VBUS power. */
>>>  int board_usb_vbus_init(void);
>>>
>>> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
>>> index 5edb250..d671f13 100644
>>> --- a/board/samsung/odroid/odroid.c
>>> +++ b/board/samsung/odroid/odroid.c
>>> @@ -453,9 +453,41 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
>>>       .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
>>>       .usb_flags      = PHY0_SLEEP,
>>>  };
>>> +#endif
>>> +
>>> +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
>>>
>>>  int board_usb_init(int index, enum usb_init_type init)
>>>  {
>>> +#ifdef CONFIG_CMD_USB
>>> +     struct pmic *p_pmic;
>>> +
>>> +     /* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
>>> +     /* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
>>> +     if (gd->board_type == ODROID_TYPE_U3)
>>> +             gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
>>> +     else
>>> +             gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
>>> +
>>> +     /* Disconnect, Reset, Connect */
>>> +     gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
>>> +     gpio_direction_output(EXYNOS4X12_GPIO_X35, 0);
>>> +     gpio_direction_output(EXYNOS4X12_GPIO_X35, 1);
>>> +     gpio_direction_output(EXYNOS4X12_GPIO_X34, 1);
>>> +
>>> +     /* Power off and on BUCK8 for LAN9730 */
>>> +     debug("LAN9730 - Turning power buck 8 OFF and ON.\n");
>>> +
>>> +     p_pmic = pmic_get("MAX77686_PMIC");
>>> +     if (p_pmic && !pmic_probe(p_pmic)) {
>>> +             max77686_set_buck_mode(p_pmic, 8, OPMODE_OFF);
>>> +             max77686_set_buck_voltage(p_pmic, 8, 750000);
>>> +             max77686_set_buck_voltage(p_pmic, 8, 3300000);
>>> +             max77686_set_buck_mode(p_pmic, 8, OPMODE_ON);
>>> +     }
>>> +
>>> +#endif
>>> +
>>>       debug("USB_udc_probe\n");
>>>       return s3c_udc_probe(&s5pc210_otg_data);
>>>  }
>>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>>> index edd91a8..6fdbf57 100644
>>> --- a/drivers/usb/host/ehci-exynos.c
>>> +++ b/drivers/usb/host/ehci-exynos.c
>>> @@ -85,15 +85,10 @@ static int exynos_usb_parse_dt(const void *blob, struct exynos_ehci *exynos)
>>>  }
>>>  #endif
>>>
>>> -/* Setup the EHCI host controller. */
>>> -static void setup_usb_phy(struct exynos_usb_phy *usb)
>>> +static void exynos5_setup_usb_phy(struct exynos_usb_phy *usb)
>>>  {
>>>       u32 hsic_ctrl;
>>>
>>> -     set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
>>> -
>>> -     set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
>>> -
>>>       clrbits_le32(&usb->usbphyctrl0,
>>>                       HOST_CTRL0_FSEL_MASK |
>>>                       HOST_CTRL0_COMMONON_N |
>>> @@ -150,8 +145,34 @@ static void setup_usb_phy(struct exynos_usb_phy *usb)
>>>                       EHCICTRL_ENAINCR16);
>>>  }
>>>
>>> -/* Reset the EHCI host controller. */
>>> -static void reset_usb_phy(struct exynos_usb_phy *usb)
>>> +static void exynos4412_setup_usb_phy(struct exynos4412_usb_phy *usb)
>>> +{
>>> +     writel(CLK_24MHZ, &usb->usbphyclk);
>>> +
>>> +     clrbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
>>> +             PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
>>> +             PHYPWR_NORMAL_MASK_PHY0));
>>> +
>>> +     setbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
>>> +     udelay(10);
>>> +     clrbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
>>> +}
>>> +
>>> +static void setup_usb_phy(struct exynos_usb_phy *usb)
>>> +{
>>
>> Well, I didn't know exactly. but i think this is something strange.
>> is it always bypassed the "struct exynos_usb_phy"?
>>
>> And don't need to modify the below code into exynos_usb_parse_dt()?
>>
>>         /*
>>          * Get the base address for usbphy from the device node
>>          */
>>         exynos->usb = (struct exynos_usb_phy *)fdtdec_get_addr(blob, node,
>>                                                                 "reg");
>>         if (exynos->usb == NULL) {
>>                 debug("Can't get the usbphy register address\n");
>>                 return -ENXIO;
>>         }
>
> Well, its a pointer and its cast to (exynos4412_usb_phy *) later on
> (in function setup_usb_phy()).
>
> If this cast looks funky, we could change exynos->usb to be of type
> void * and cast it to appropriate (exynos4_usb_phy *)  or
> (exynos4412_us_phy *) as needed.
>
> I do not know which is preferable. As far as I see it, its a pointer,
> and depending on the SoC we cast it differently.
>
> Please let me know if you have any ideas of how you want to change it
> for it to be less confusing (if that is indeed the case).
>

Another thought is to change struct exynos_usb_phy  to be as follows
using a union which encompasses the exynos4412 usb register mappings:

/* Register map for PHY control */
struct exynos_usb_phy {
        union {
               unsigned int usbphyctrl0;
               unsigned int usbphyctrl;
        };
        union {
               unsigned int usbphytune0;
               unsigned int usbphyclk;
        };
        union {
               unsigned int reserved1[2];
               unsigned int usbphyrstcon;
        };
        unsigned int hsicphyctrl1;
        unsigned int hsicphytune1;
        unsigned int reserved2[2];
        unsigned int hsicphyctrl2;
        unsigned int hsicphytune2;
        unsigned int reserved3[2];
        unsigned int ehcictrl;
        unsigned int ohcictrl;
        unsigned int usbotgsys;
        unsigned int reserved4;
        unsigned int usbotgtune;
};

This to me, looks more confusing. Another approach would be to rename
struct exynos_usb_phy to exynos5_usb_phy as the register mapping is
more pertinent to exynos5 SoCs, and change more code to make it more
clean.

Your thoughts on this are welcome.
Regards
- Suriyan

> Thanks
> - Suriyan
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> +     set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
>>> +
>>> +     set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
>>> +
>>> +     if (cpu_is_exynos5())
>>> +             exynos5_setup_usb_phy(usb);
>>> +     else if (cpu_is_exynos4())
>>> +             if (proid_is_exynos4412())
>>> +                     exynos4412_setup_usb_phy((struct exynos4412_usb_phy *)
>>> +                                              usb);
>>> +}
>>> +
>>> +static void exynos5_reset_usb_phy(struct exynos_usb_phy *usb)
>>>  {
>>>       u32 hsic_ctrl;
>>>
>>> @@ -171,6 +192,24 @@ static void reset_usb_phy(struct exynos_usb_phy *usb)
>>>
>>>       setbits_le32(&usb->hsicphyctrl1, hsic_ctrl);
>>>       setbits_le32(&usb->hsicphyctrl2, hsic_ctrl);
>>> +}
>>> +
>>> +static void exynos4412_reset_usb_phy(struct exynos4412_usb_phy *usb)
>>> +{
>>> +     setbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
>>> +             PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
>>> +             PHYPWR_NORMAL_MASK_PHY0));
>>> +}
>>> +
>>> +/* Reset the EHCI host controller. */
>>> +static void reset_usb_phy(struct exynos_usb_phy *usb)
>>> +{
>>> +     if (cpu_is_exynos5())
>>> +             exynos5_reset_usb_phy(usb);
>>> +     else if (cpu_is_exynos4())
>>> +             if (proid_is_exynos4412())
>>> +                     exynos4412_reset_usb_phy((struct exynos4412_usb_phy *)
>>> +                                              usb);
>>>
>>>       set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_DISABLE);
>>>  }
>>> diff --git a/include/configs/odroid.h b/include/configs/odroid.h
>>> index b928af8..807e96b 100644
>>> --- a/include/configs/odroid.h
>>> +++ b/include/configs/odroid.h
>>> @@ -198,6 +198,19 @@
>>>
>>>  #define CONFIG_CMD_GPIO
>>>
>>> +/* USB */
>>> +#define CONFIG_CMD_USB
>>> +#define CONFIG_USB_EHCI
>>> +#define CONFIG_USB_EHCI_EXYNOS
>>> +#define CONFIG_USB_STORAGE
>>> +
>>> +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS   3
>>> +#define CONFIG_CMD_NET
>>> +#define CONFIG_CMD_PING
>>> +#define CONFIG_CMD_DHCP
>>> +#define CONFIG_USB_HOST_ETHER
>>> +#define CONFIG_USB_ETHER_SMSC95XX
>>> +
>>>  /*
>>>   * Supported Odroid boards: X3, U3
>>>   * TODO: Add Odroid X support
>>>
>>
Minkyu Kang Nov. 17, 2014, 2:02 p.m. UTC | #4
On 30/10/14 01:22, Suriyan Ramasami wrote:
> This change adds support for enabling the USB host features of the board.
> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
> as well.
> 
> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
> 
> ---
> 
> Changes in v3:
> * removed set_usb_ethaddr() and related code as the GUID registers do not
>   seem to be documented anywhere. This is sad, as this mechanism allows
>   for each Odroid to boot up with the same MAC address every time, but no
>   two odroids shall have the same MAC address on boot. This ensures multiple
>   odroids in the same LAN to come up without conflicting MAC addresses.
> * Minkyu - Do not mix cpu_is... and proid_is...
> 
> Changes in v2:
> * Jaehoon - Split power.[ch] as a separate patch
> * Removed an unneeded header file from ehci-exynos.c
> * Jaehoon - Fix indentation in the dts file
> 
> Changes in v1:
> * First try
> 
>  arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>  arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>  board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>  drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>  include/configs/odroid.h                | 13 ++++++++
>  5 files changed, 116 insertions(+), 8 deletions(-)
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
Suriyan Ramasami Nov. 18, 2014, 3:30 a.m. UTC | #5
Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,

Thanks for the commit.

    I just realized that the code in this particular patch is missing
the gpio_request() call before calling the gpio_direction_output()
call, and hence fails to initialize the USB3503A hub. This was pointed
out by Przemyslaw in another patch of mine (odroid: blue LED)

   So, my question is, this patch is in u-boot-samsung. To correct the
above mentioned error, do I submit a patch directed to u-boot-samsung?
If so how do I do it? I mean, do I elaborate this in the subject
/.body of the mail?

Thanks and regards,
- Suriyan


On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang <mk7.kang@samsung.com> wrote:
> On 30/10/14 01:22, Suriyan Ramasami wrote:
>> This change adds support for enabling the USB host features of the board.
>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>> as well.
>>
>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>
>> ---
>>
>> Changes in v3:
>> * removed set_usb_ethaddr() and related code as the GUID registers do not
>>   seem to be documented anywhere. This is sad, as this mechanism allows
>>   for each Odroid to boot up with the same MAC address every time, but no
>>   two odroids shall have the same MAC address on boot. This ensures multiple
>>   odroids in the same LAN to come up without conflicting MAC addresses.
>> * Minkyu - Do not mix cpu_is... and proid_is...
>>
>> Changes in v2:
>> * Jaehoon - Split power.[ch] as a separate patch
>> * Removed an unneeded header file from ehci-exynos.c
>> * Jaehoon - Fix indentation in the dts file
>>
>> Changes in v1:
>> * First try
>>
>>  arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>  arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>  board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>  drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>>  include/configs/odroid.h                | 13 ++++++++
>>  5 files changed, 116 insertions(+), 8 deletions(-)
>>
>
> applied to u-boot-samsung.
>
> Thanks,
> Minkyu Kang.
>
Minkyu Kang Nov. 18, 2014, 8:14 a.m. UTC | #6
Hi,

On 18/11/14 12:30, Suriyan Ramasami wrote:
> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
> 
> Thanks for the commit.
> 
>     I just realized that the code in this particular patch is missing
> the gpio_request() call before calling the gpio_direction_output()
> call, and hence fails to initialize the USB3503A hub. This was pointed
> out by Przemyslaw in another patch of mine (odroid: blue LED)
> 
>    So, my question is, this patch is in u-boot-samsung. To correct the
> above mentioned error, do I submit a patch directed to u-boot-samsung?

Yes. Please send new patch.

> If so how do I do it? I mean, do I elaborate this in the subject
> /.body of the mail?

sorry, I can't catch the point of your question.

> 
> Thanks and regards,
> - Suriyan

Thanks,
Minkyu Kang.
Przemyslaw Marczak Nov. 18, 2014, 11:09 a.m. UTC | #7
Hello Suriyan,

On 11/18/2014 04:30 AM, Suriyan Ramasami wrote:
> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>
> Thanks for the commit.
>
>      I just realized that the code in this particular patch is missing
> the gpio_request() call before calling the gpio_direction_output()
> call, and hence fails to initialize the USB3503A hub. This was pointed
> out by Przemyslaw in another patch of mine (odroid: blue LED)
>
>     So, my question is, this patch is in u-boot-samsung. To correct the
> above mentioned error, do I submit a patch directed to u-boot-samsung?
> If so how do I do it? I mean, do I elaborate this in the subject
> /.body of the mail?
>
> Thanks and regards,
> - Suriyan
>
>

Yes, the gpio_request() was missed in your code - it prints errors about 
it but the HUB works fine. So when you send the fixed version this 
should be okay. Please check ums command before send.

Please also check setting buck value at function board_usb_init(),
the buck is disabled and before enable - the value changes two times - 
probably by mistake.

And the gpio_request(...) you can put into board_gpio_init - request 
gpio only one.

The odroid is available on the market, so I would prefer keep some 
documentation in the doc/README.odroid.
Could you please add short section about the USB usage in U-Boot? This 
would be useful.

> On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang <mk7.kang@samsung.com> wrote:
>> On 30/10/14 01:22, Suriyan Ramasami wrote:
>>> This change adds support for enabling the USB host features of the board.
>>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>>> as well.
>>>
>>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>>
>>> ---
>>>
>>> Changes in v3:
>>> * removed set_usb_ethaddr() and related code as the GUID registers do not
>>>    seem to be documented anywhere. This is sad, as this mechanism allows
>>>    for each Odroid to boot up with the same MAC address every time, but no
>>>    two odroids shall have the same MAC address on boot. This ensures multiple
>>>    odroids in the same LAN to come up without conflicting MAC addresses.
>>> * Minkyu - Do not mix cpu_is... and proid_is...
>>>
>>> Changes in v2:
>>> * Jaehoon - Split power.[ch] as a separate patch
>>> * Removed an unneeded header file from ehci-exynos.c
>>> * Jaehoon - Fix indentation in the dts file
>>>
>>> Changes in v1:
>>> * First try
>>>
>>>   arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>>   arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>>   board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>>   drivers/usb/host/ehci-exynos.c          | 55 ++++++++++++++++++++++++++++-----
>>>   include/configs/odroid.h                | 13 ++++++++
>>>   5 files changed, 116 insertions(+), 8 deletions(-)
>>>
>>
>> applied to u-boot-samsung.
>>
>> Thanks,
>> Minkyu Kang.
>>
>

Best regards,
Przemyslaw Marczak Nov. 18, 2014, 11:14 a.m. UTC | #8
Dear Minkyu,

On 11/18/2014 09:14 AM, Minkyu Kang wrote:
> Hi,
>
> On 18/11/14 12:30, Suriyan Ramasami wrote:
>> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>>
>> Thanks for the commit.
>>
>>      I just realized that the code in this particular patch is missing
>> the gpio_request() call before calling the gpio_direction_output()
>> call, and hence fails to initialize the USB3503A hub. This was pointed
>> out by Przemyslaw in another patch of mine (odroid: blue LED)
>>
>>     So, my question is, this patch is in u-boot-samsung. To correct the
>> above mentioned error, do I submit a patch directed to u-boot-samsung?
>
> Yes. Please send new patch.
>
>> If so how do I do it? I mean, do I elaborate this in the subject
>> /.body of the mail?
>
> sorry, I can't catch the point of your question.
>
>>
>> Thanks and regards,
>> - Suriyan
>
> Thanks,
> Minkyu Kang.
>
>

Could you please wait for the test/ack next time before you merge the 
patches to the tree? It will prevent before making an additional work on 
testing or fixing some code.

Best regards,
Minkyu Kang Nov. 18, 2014, 2:05 p.m. UTC | #9
Dear Przemyslaw Marczak,

On 18/11/14 20:14, Przemyslaw Marczak wrote:
> Dear Minkyu,
> 
> On 11/18/2014 09:14 AM, Minkyu Kang wrote:
>> Hi,
>>
>> On 18/11/14 12:30, Suriyan Ramasami wrote:
>>> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>>>
>>> Thanks for the commit.
>>>
>>>      I just realized that the code in this particular patch is missing
>>> the gpio_request() call before calling the gpio_direction_output()
>>> call, and hence fails to initialize the USB3503A hub. This was pointed
>>> out by Przemyslaw in another patch of mine (odroid: blue LED)
>>>
>>>     So, my question is, this patch is in u-boot-samsung. To correct the
>>> above mentioned error, do I submit a patch directed to u-boot-samsung?
>>
>> Yes. Please send new patch.
>>
>>> If so how do I do it? I mean, do I elaborate this in the subject
>>> /.body of the mail?
>>
>> sorry, I can't catch the point of your question.
>>
>>>
>>> Thanks and regards,
>>> - Suriyan
>>
>> Thanks,
>> Minkyu Kang.
>>
>>
> 
> Could you please wait for the test/ack next time before you merge the patches to the tree? It will prevent before making an additional work on testing or fixing some code.
> 
> Best regards,

It's my bad that I didn't check it carefully.
I usually wait somebody's response.
But this patch is waited 18 days on the queue.
How long will I wait?

Thanks,
Minkyu Kang.
Przemyslaw Marczak Nov. 18, 2014, 2:33 p.m. UTC | #10
Hello Minkyu,

On 11/18/2014 03:05 PM, Minkyu Kang wrote:
> Dear Przemyslaw Marczak,
>
> On 18/11/14 20:14, Przemyslaw Marczak wrote:
>> Dear Minkyu,
>>
>> On 11/18/2014 09:14 AM, Minkyu Kang wrote:
>>> Hi,
>>>
>>> On 18/11/14 12:30, Suriyan Ramasami wrote:
>>>> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>>>>
>>>> Thanks for the commit.
>>>>
>>>>       I just realized that the code in this particular patch is missing
>>>> the gpio_request() call before calling the gpio_direction_output()
>>>> call, and hence fails to initialize the USB3503A hub. This was pointed
>>>> out by Przemyslaw in another patch of mine (odroid: blue LED)
>>>>
>>>>      So, my question is, this patch is in u-boot-samsung. To correct the
>>>> above mentioned error, do I submit a patch directed to u-boot-samsung?
>>>
>>> Yes. Please send new patch.
>>>
>>>> If so how do I do it? I mean, do I elaborate this in the subject
>>>> /.body of the mail?
>>>
>>> sorry, I can't catch the point of your question.
>>>
>>>>
>>>> Thanks and regards,
>>>> - Suriyan
>>>
>>> Thanks,
>>> Minkyu Kang.
>>>
>>>
>>
>> Could you please wait for the test/ack next time before you merge the patches to the tree? It will prevent before making an additional work on testing or fixing some code.
>>
>> Best regards,
>
> It's my bad that I didn't check it carefully.
> I usually wait somebody's response.
> But this patch is waited 18 days on the queue.
> How long will I wait?
>
> Thanks,
> Minkyu Kang.
>

It's easy to miss something without test on a hardware and this is the 
reason why the code should be tested before the merge.

The 18 days is quite long, I agree with you - but is this a reason for 
those patches to be merged, without the test?

You are a busy person at work, the same as I am, but I hope that "ping" 
somebody to check the code is a good manner.

And then I believe, we can provide stable and tested master tree as a 
maintainers of our boards.

Best regards,
Suriyan Ramasami Nov. 18, 2014, 5:34 p.m. UTC | #11
Hello Przemyslaw,

On Tue, Nov 18, 2014 at 3:09 AM, Przemyslaw Marczak
<p.marczak@samsung.com> wrote:
> Hello Suriyan,
>
> On 11/18/2014 04:30 AM, Suriyan Ramasami wrote:
>>
>> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>>
>> Thanks for the commit.
>>
>>      I just realized that the code in this particular patch is missing
>> the gpio_request() call before calling the gpio_direction_output()
>> call, and hence fails to initialize the USB3503A hub. This was pointed
>> out by Przemyslaw in another patch of mine (odroid: blue LED)
>>
>>     So, my question is, this patch is in u-boot-samsung. To correct the
>> above mentioned error, do I submit a patch directed to u-boot-samsung?
>> If so how do I do it? I mean, do I elaborate this in the subject
>> /.body of the mail?
>>
>> Thanks and regards,
>> - Suriyan
>>
>>
>
> Yes, the gpio_request() was missed in your code - it prints errors about it
> but the HUB works fine. So when you send the fixed version this should be
> okay. Please check ums command before send.
>

Sure, will do!

> Please also check setting buck value at function board_usb_init(),
> the buck is disabled and before enable - the value changes two times -
> probably by mistake.
>

I think there is an error in the implementation of
max77686_set_buck_mode(..., buck #, OPMODE_OFF), or I have some gap in
my understanding of it. I believe that when you set OPMODE_OFF it
should turn it OFF right? as in no voltage? This does not seem to be
the case.
I have to turn the power off and then on, on BUCK8 (LAN9730 feeds off
of it), to reset the LAN when a usb reset is issued, else it will not
be detected again when usb start is re-issued.
Initially, I had max77686_set_buck_mode(p_pmic, 9, OPMODE_OFF); delay;
max77686(set_buck_mode(p_pmic, 9, OPMODE_ON); but it did not power
recycle the LAN9730 chip.
I do not have access to the MAX77686 data sheets to debug this. Hence,
in my current code I set the voltage to the lowest possible value, and
then bring it back up to 3.3V to simulate a reset. In fact, I can
remove the OPMODE_OFF and OPMODE_ON code, and it works.
Please let me know if there is any change needed in the OPMODE_OFF
code for it to work the way it should, or correct my understanding of
what it is supposed to do.

Currently, I am thinking of just having:
                max77686_set_buck_voltage(p_pmic, 8, 750000);
                max77686_set_buck_voltage(p_pmic, 8, 3300000);
and leave the OPMODE_OFF and OPMODE_ON out of it.

> And the gpio_request(...) you can put into board_gpio_init - request gpio
> only one.
>

Yes.

> The odroid is available on the market, so I would prefer keep some
> documentation in the doc/README.odroid.
> Could you please add short section about the USB usage in U-Boot? This would
> be useful.

OK!

>
>
>> On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang <mk7.kang@samsung.com> wrote:
>>>
>>> On 30/10/14 01:22, Suriyan Ramasami wrote:
>>>>
>>>> This change adds support for enabling the USB host features of the
>>>> board.
>>>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>>>> as well.
>>>>
>>>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>> * removed set_usb_ethaddr() and related code as the GUID registers do
>>>> not
>>>>    seem to be documented anywhere. This is sad, as this mechanism allows
>>>>    for each Odroid to boot up with the same MAC address every time, but
>>>> no
>>>>    two odroids shall have the same MAC address on boot. This ensures
>>>> multiple
>>>>    odroids in the same LAN to come up without conflicting MAC addresses.
>>>> * Minkyu - Do not mix cpu_is... and proid_is...
>>>>
>>>> Changes in v2:
>>>> * Jaehoon - Split power.[ch] as a separate patch
>>>> * Removed an unneeded header file from ehci-exynos.c
>>>> * Jaehoon - Fix indentation in the dts file
>>>>
>>>> Changes in v1:
>>>> * First try
>>>>
>>>>   arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>>>   arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>>>   board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>>>   drivers/usb/host/ehci-exynos.c          | 55
>>>> ++++++++++++++++++++++++++++-----
>>>>   include/configs/odroid.h                | 13 ++++++++
>>>>   5 files changed, 116 insertions(+), 8 deletions(-)
>>>>
>>>
>>> applied to u-boot-samsung.
>>>
>>> Thanks,
>>> Minkyu Kang.
>>>
>>
>
> Best regards,
> --
> Przemyslaw Marczak
> Samsung R&D Institute Poland
> Samsung Electronics
> p.marczak@samsung.com
Przemyslaw Marczak Nov. 19, 2014, 5:18 p.m. UTC | #12
Hello Suriyan,

On 11/18/2014 06:34 PM, Suriyan Ramasami wrote:
> Hello Przemyslaw,
>
> On Tue, Nov 18, 2014 at 3:09 AM, Przemyslaw Marczak
> <p.marczak@samsung.com> wrote:
>> Hello Suriyan,
>>
>> On 11/18/2014 04:30 AM, Suriyan Ramasami wrote:
>>>
>>> Hello Minkyu Kang/Przemyslaw and of course anyone else who can direct me,
>>>
>>> Thanks for the commit.
>>>
>>>       I just realized that the code in this particular patch is missing
>>> the gpio_request() call before calling the gpio_direction_output()
>>> call, and hence fails to initialize the USB3503A hub. This was pointed
>>> out by Przemyslaw in another patch of mine (odroid: blue LED)
>>>
>>>      So, my question is, this patch is in u-boot-samsung. To correct the
>>> above mentioned error, do I submit a patch directed to u-boot-samsung?
>>> If so how do I do it? I mean, do I elaborate this in the subject
>>> /.body of the mail?
>>>
>>> Thanks and regards,
>>> - Suriyan
>>>
>>>
>>
>> Yes, the gpio_request() was missed in your code - it prints errors about it
>> but the HUB works fine. So when you send the fixed version this should be
>> okay. Please check ums command before send.
>>
>
> Sure, will do!
>
>> Please also check setting buck value at function board_usb_init(),
>> the buck is disabled and before enable - the value changes two times -
>> probably by mistake.
>>
>
> I think there is an error in the implementation of
> max77686_set_buck_mode(..., buck #, OPMODE_OFF), or I have some gap in
> my understanding of it. I believe that when you set OPMODE_OFF it
> should turn it OFF right? as in no voltage? This does not seem to be
> the case.
> I have to turn the power off and then on, on BUCK8 (LAN9730 feeds off
> of it), to reset the LAN when a usb reset is issued, else it will not
> be detected again when usb start is re-issued.
> Initially, I had max77686_set_buck_mode(p_pmic, 9, OPMODE_OFF); delay;
> max77686(set_buck_mode(p_pmic, 9, OPMODE_ON); but it did not power
> recycle the LAN9730 chip.
> I do not have access to the MAX77686 data sheets to debug this. Hence,
> in my current code I set the voltage to the lowest possible value, and
> then bring it back up to 3.3V to simulate a reset. In fact, I can
> remove the OPMODE_OFF and OPMODE_ON code, and it works.
> Please let me know if there is any change needed in the OPMODE_OFF
> code for it to work the way it should, or correct my understanding of
> what it is supposed to do.
>
> Currently, I am thinking of just having:
>                  max77686_set_buck_voltage(p_pmic, 8, 750000);
>                  max77686_set_buck_voltage(p_pmic, 8, 3300000);
> and leave the OPMODE_OFF and OPMODE_ON out of it.
>
Ok, now I see the issue. So I looked into the documentation and there is 
a "ENB8" pin in PMIC package - this pin allows steering BUCK8 ON/OFF by 
the hardware. If ENB8 is set to "low", then you can do on/off - when 
"high" then you can't change it's state by I2C write. This PMIC has a 
lot of such gpio for setting the default power-on state of ldo/buck 
regulators.

The signal of ENB8 in OdroidU3 schematic is missed, I can suppose that 
it is connected to one of SOC RST signal as it is on Odroid X2.

So doing the reset by setting low/high voltage value - seems to be good 
in this case.

>> And the gpio_request(...) you can put into board_gpio_init - request gpio
>> only one.
>>
>
> Yes.
>
>> The odroid is available on the market, so I would prefer keep some
>> documentation in the doc/README.odroid.
>> Could you please add short section about the USB usage in U-Boot? This would
>> be useful.
>
> OK!
>
>>
>>
>>> On Mon, Nov 17, 2014 at 6:02 AM, Minkyu Kang <mk7.kang@samsung.com> wrote:
>>>>
>>>> On 30/10/14 01:22, Suriyan Ramasami wrote:
>>>>>
>>>>> This change adds support for enabling the USB host features of the
>>>>> board.
>>>>> This includes the USB3503A hub and the SMC LAN9730 ethernet controller
>>>>> as well.
>>>>>
>>>>> Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v3:
>>>>> * removed set_usb_ethaddr() and related code as the GUID registers do
>>>>> not
>>>>>     seem to be documented anywhere. This is sad, as this mechanism allows
>>>>>     for each Odroid to boot up with the same MAC address every time, but
>>>>> no
>>>>>     two odroids shall have the same MAC address on boot. This ensures
>>>>> multiple
>>>>>     odroids in the same LAN to come up without conflicting MAC addresses.
>>>>> * Minkyu - Do not mix cpu_is... and proid_is...
>>>>>
>>>>> Changes in v2:
>>>>> * Jaehoon - Split power.[ch] as a separate patch
>>>>> * Removed an unneeded header file from ehci-exynos.c
>>>>> * Jaehoon - Fix indentation in the dts file
>>>>>
>>>>> Changes in v1:
>>>>> * First try
>>>>>
>>>>>    arch/arm/dts/exynos4412-odroid.dts      | 11 +++++++
>>>>>    arch/arm/include/asm/arch-exynos/ehci.h | 13 ++++++++
>>>>>    board/samsung/odroid/odroid.c           | 32 +++++++++++++++++++
>>>>>    drivers/usb/host/ehci-exynos.c          | 55
>>>>> ++++++++++++++++++++++++++++-----
>>>>>    include/configs/odroid.h                | 13 ++++++++
>>>>>    5 files changed, 116 insertions(+), 8 deletions(-)
>>>>>
>>>>
>>>> applied to u-boot-samsung.
>>>>
>>>> Thanks,
>>>> Minkyu Kang.
>>>>
>>>
>>
>> Best regards,
>> --
>> Przemyslaw Marczak
>> Samsung R&D Institute Poland
>> Samsung Electronics
>> p.marczak@samsung.com

Best regards,
diff mbox

Patch

diff --git a/arch/arm/dts/exynos4412-odroid.dts b/arch/arm/dts/exynos4412-odroid.dts
index 4c5e2b3..2df1801 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@ 
 		div = <0x3>;
 		index = <4>;
 	};
+
+	ehci@12580000 {
+		compatible = "samsung,exynos-ehci";
+		reg = <0x12580000 0x100>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		phy {
+			compatible = "samsung,exynos-usb-phy";
+			reg = <0x125B0000 0x100>;
+		};
+	};
 };
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@ 
 
 #define CLK_24MHZ		5
 
+#define PHYPWR_NORMAL_MASK_PHY0                 (0x39 << 0)
+#define PHYPWR_NORMAL_MASK_PHY1                 (0x7 << 6)
+#define PHYPWR_NORMAL_MASK_HSIC0                (0x7 << 9)
+#define PHYPWR_NORMAL_MASK_HSIC1                (0x7 << 12)
+#define RSTCON_HOSTPHY_SWRST                    (0xf << 3)
+#define RSTCON_SWRST                            (0x1 << 0)
+
 #define HOST_CTRL0_PHYSWRSTALL			(1 << 31)
 #define HOST_CTRL0_COMMONON_N			(1 << 9)
 #define HOST_CTRL0_SIDDQ			(1 << 6)
@@ -61,6 +68,12 @@  struct exynos_usb_phy {
 	unsigned int usbotgtune;
 };
 
+struct exynos4412_usb_phy {
+	unsigned int usbphyctrl;
+	unsigned int usbphyclk;
+	unsigned int usbphyrstcon;
+};
+
 /* Switch on the VBUS power. */
 int board_usb_vbus_init(void);
 
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 5edb250..d671f13 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -453,9 +453,41 @@  struct s3c_plat_otg_data s5pc210_otg_data = {
 	.usb_phy_ctrl	= EXYNOS4X12_USBPHY_CONTROL,
 	.usb_flags	= PHY0_SLEEP,
 };
+#endif
+
+#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
 
 int board_usb_init(int index, enum usb_init_type init)
 {
+#ifdef CONFIG_CMD_USB
+	struct pmic *p_pmic;
+
+	/* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
+	/* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
+	if (gd->board_type == ODROID_TYPE_U3)
+		gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
+	else
+		gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
+
+	/* Disconnect, Reset, Connect */
+	gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
+	gpio_direction_output(EXYNOS4X12_GPIO_X35, 0);
+	gpio_direction_output(EXYNOS4X12_GPIO_X35, 1);
+	gpio_direction_output(EXYNOS4X12_GPIO_X34, 1);
+
+	/* Power off and on BUCK8 for LAN9730 */
+	debug("LAN9730 - Turning power buck 8 OFF and ON.\n");
+
+	p_pmic = pmic_get("MAX77686_PMIC");
+	if (p_pmic && !pmic_probe(p_pmic)) {
+		max77686_set_buck_mode(p_pmic, 8, OPMODE_OFF);
+		max77686_set_buck_voltage(p_pmic, 8, 750000);
+		max77686_set_buck_voltage(p_pmic, 8, 3300000);
+		max77686_set_buck_mode(p_pmic, 8, OPMODE_ON);
+	}
+
+#endif
+
 	debug("USB_udc_probe\n");
 	return s3c_udc_probe(&s5pc210_otg_data);
 }
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index edd91a8..6fdbf57 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -85,15 +85,10 @@  static int exynos_usb_parse_dt(const void *blob, struct exynos_ehci *exynos)
 }
 #endif
 
-/* Setup the EHCI host controller. */
-static void setup_usb_phy(struct exynos_usb_phy *usb)
+static void exynos5_setup_usb_phy(struct exynos_usb_phy *usb)
 {
 	u32 hsic_ctrl;
 
-	set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
-
-	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
-
 	clrbits_le32(&usb->usbphyctrl0,
 			HOST_CTRL0_FSEL_MASK |
 			HOST_CTRL0_COMMONON_N |
@@ -150,8 +145,34 @@  static void setup_usb_phy(struct exynos_usb_phy *usb)
 			EHCICTRL_ENAINCR16);
 }
 
-/* Reset the EHCI host controller. */
-static void reset_usb_phy(struct exynos_usb_phy *usb)
+static void exynos4412_setup_usb_phy(struct exynos4412_usb_phy *usb)
+{
+	writel(CLK_24MHZ, &usb->usbphyclk);
+
+	clrbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
+		PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
+		PHYPWR_NORMAL_MASK_PHY0));
+
+	setbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
+	udelay(10);
+	clrbits_le32(&usb->usbphyrstcon, (RSTCON_HOSTPHY_SWRST | RSTCON_SWRST));
+}
+
+static void setup_usb_phy(struct exynos_usb_phy *usb)
+{
+	set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
+
+	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
+
+	if (cpu_is_exynos5())
+		exynos5_setup_usb_phy(usb);
+	else if (cpu_is_exynos4())
+		if (proid_is_exynos4412())
+			exynos4412_setup_usb_phy((struct exynos4412_usb_phy *)
+						 usb);
+}
+
+static void exynos5_reset_usb_phy(struct exynos_usb_phy *usb)
 {
 	u32 hsic_ctrl;
 
@@ -171,6 +192,24 @@  static void reset_usb_phy(struct exynos_usb_phy *usb)
 
 	setbits_le32(&usb->hsicphyctrl1, hsic_ctrl);
 	setbits_le32(&usb->hsicphyctrl2, hsic_ctrl);
+}
+
+static void exynos4412_reset_usb_phy(struct exynos4412_usb_phy *usb)
+{
+	setbits_le32(&usb->usbphyctrl, (PHYPWR_NORMAL_MASK_HSIC0 |
+		PHYPWR_NORMAL_MASK_HSIC1 | PHYPWR_NORMAL_MASK_PHY1 |
+		PHYPWR_NORMAL_MASK_PHY0));
+}
+
+/* Reset the EHCI host controller. */
+static void reset_usb_phy(struct exynos_usb_phy *usb)
+{
+	if (cpu_is_exynos5())
+		exynos5_reset_usb_phy(usb);
+	else if (cpu_is_exynos4())
+		if (proid_is_exynos4412())
+			exynos4412_reset_usb_phy((struct exynos4412_usb_phy *)
+						 usb);
 
 	set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_DISABLE);
 }
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index b928af8..807e96b 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -198,6 +198,19 @@ 
 
 #define CONFIG_CMD_GPIO
 
+/* USB */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_EXYNOS
+#define CONFIG_USB_STORAGE
+
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS	3
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+
 /*
  * Supported Odroid boards: X3, U3
  * TODO: Add Odroid X support