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

maitysanchayan at gmail.com
2015-11-06T07:00:01Z

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