[U-Boot] [PATCH v3] colibri_vf: Add board_usb_phy_mode function

[maitysanchayan at gmail.com <maitysanchayan@gmail.com>]

On 15-10-30 14:20:29, Marek Vasut wrote:
> On Friday, October 30, 2015 at 01:26:59 PM, Sanchayan Maity wrote:
> > Add board_usb_phy_mode function for detecting whether a port is
> > being used as host or client using a GPIO. On Colibri Vybrid we
> > provide the GPIO 102 for this very same purpose.
> > 
> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> > ---
> > Changes since v1:
> > 
> > Move the GPIO request call to the board_init function as all
> > further calls to board_usb_phy_mode will actually result in the
> > gpio_request failing.
> > 
> > Changes since v2:
> > 
> > Instead of returning 0 from board_usb_phy_mode return it as
> > USB_INIT_HOST.
> > ---
> >  board/toradex/colibri_vf/colibri_vf.c | 23 ++++++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/toradex/colibri_vf/colibri_vf.c
> > b/board/toradex/colibri_vf/colibri_vf.c index a6d1c5b..9878671 100644
> > --- a/board/toradex/colibri_vf/colibri_vf.c
> > +++ b/board/toradex/colibri_vf/colibri_vf.c
> > @@ -21,6 +21,7 @@
> >  #include <i2c.h>
> >  #include <g_dnl.h>
> >  #include <asm/gpio.h>
> > +#include <usb.h>
> > 
> >  DECLARE_GLOBAL_DATA_PTR;
> > 
> > @@ -34,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >  			PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
> > 
> >  #define USB_PEN_GPIO           83
> > +#define USB_CDET_GPIO			102
> > 
> >  static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
> >  	/* levelling */
> > @@ -92,6 +94,7 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] =
> > {
> > 
> >  static const iomux_v3_cfg_t usb_pads[] = {
> >  	VF610_PAD_PTD4__GPIO_83,
> > +	VF610_PAD_PTC29__GPIO_102,
> >  };
> > 
> >  int dram_init(void)
> > @@ -280,7 +283,6 @@ static void setup_iomux_gpio(void)
> >  		VF610_PAD_PTB23__GPIO_93,
> >  		VF610_PAD_PTB26__GPIO_96,
> >  		VF610_PAD_PTB28__GPIO_98,
> > -		VF610_PAD_PTC29__GPIO_102,
> >  		VF610_PAD_PTC30__GPIO_103,
> >  		VF610_PAD_PTA7__GPIO_134,
> >  	};
> > @@ -509,6 +511,10 @@ int board_init(void)
> > 
> >  	setbits_le32(&scsc->sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
> > 
> > +#ifdef CONFIG_USB_EHCI_VF
> > +	gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
> > +#endif
> > +
> >  	return 0;
> >  }
> > 
> > @@ -554,4 +560,19 @@ int board_ehci_hcd_init(int port)
> >  	}
> >  	return 0;
> >  }
> > +
> > +int board_usb_phy_mode(int port)
> > +{
> > +	switch (port) {
> > +	case 0:
> > +		return gpio_get_value(USB_CDET_GPIO);
> 
> So what would happen to this code in case we re-number the USB_INIT_HOST
> and USB_INIT_DEVICE or in case the GPIO API starts returning something
> else but 0 or 1 here ?

Sorry for the delay in reply. Had got tied up elsewhere.

Currently USB_INIT_HOST and USB_INIT_DEVICE are defined with an enum. If we
were to switch this would not work as I intended. I guess this would be
more appropriate then

if (gpio_get_value(USB_CDET_GPIO))
	return USB_INIT_DEVICE;
else
	return USB_INIT_HOST;

For the GPIO, isn't gpio_get_value always suppose to return the actual state
of GPIO? Would we ever change the GPIO API to report otherwise?

Concerning the other thread from Stefan's query I will add the comments.

Thanks.

- Sanchayan.

> 
> > +		break;
> > +	case 1:
> > +		return USB_INIT_HOST;
> > +		break;
> > +	default:
> > +		return USB_INIT_HOST;
> > +		break;
> > +	}
> > +}
> >  #endif