From: maitysanchayan at gmail.com <maitysanchayan@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Doubt in USB driver for Vybrid vf610
Date: Sat, 24 Oct 2015 23:49:36 +0530 [thread overview]
Message-ID: <20151024181814.GA24793@Sanchayan-Arch> (raw)
In-Reply-To: <201510241950.13497.marex@denx.de>
On 15-10-24 19:50:13, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 06:23:44 PM, maitysanchayan at gmail.com wrote:
> > On 15-10-24 18:16:20, Marek Vasut wrote:
> > > On Saturday, October 24, 2015 at 06:08:57 PM, maitysanchayan at gmail.com
> wrote:
> > > > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > > > On Saturday, October 24, 2015 at 05:23:05 PM,
> > > > > maitysanchayan at gmail.com
> > >
> > > wrote:
> > > > > > Hello,
> > > > > >
> > > > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > > > Hi Marek,
> > > > > > >
> > > > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > > > >> Any inputs on the below?
> > > > > > > >
> > > > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > > >
> > > > > > > I don't have access to a Vybrid board either.
> > > > > > >
> > > > > > > Sanchayan,
> > > > > > >
> > > > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > > >
> > > > > > No.
> > > > > >
> > > > > > I included the particular piece of code below
> > > > > >
> > > > > > if (init == USB_INIT_DEVICE && index == 1)
> > > > > >
> > > > > > return -ENODEV;
> > > > > >
> > > > > > if (init == USB_INIT_HOST && index == 0)
> > > > > >
> > > > > > return -ENODEV;
> > > > > >
> > > > > > in the ehci-vf driver because our requirement was to have one port
> > > > > > as client and other as host. Since on USB start both ports get
> > > > > > configured as host as it iterates depending on USB EHCI controller
> > > > > > count, the above was meant to stop the port required as client to
> > > > > > be configured as host and vice versa while using client
> > > > > > functionality such as DFU.
> > > > > >
> > > > > > I made the mistake of not thinking that this is not a generic use
> > > > > > case, someone might want it the other way around or such.
> > > > > >
> > > > > > So coming to the main question, what would be the correct way to
> > > > > > fix this? I tested that even if the above four lines are removed
> > > > > > and USB start configures both ports as host, calling dfu later
> > > > > > will still result in correct functioning. So is this ok and the
> > > > > > four lines should be nuked or a more appropriate way would be to
> > > > > > add something like board_ehci_hcd_init_with_type(int index, enum
> > > > > > usb_init _type init) which would be a weak function and have the
> > > > > > board specific code call this to do the above which is currently
> > > > > > done in ehci-vf.
> > > > > >
> > > > > > I wasn't sure about the right approach to take so I asked.
> > > > >
> > > > > Brief glare over the driver tells me that those four lines are
> > > > > complete nonsense and should be removed.
> > > >
> > > > Yes very much so. But is removing just ok or it would be better to
> > > > actually restrict as per a board's requirement what gets configured as
> > > > host and what gets configured as client by adding the weak function
> > > > hook I was talking about?
> > >
> > > The mx6 ones does board_usb_phy_mode() to determine this restriction. But
> > > (!) it'd be even better if this information was obtained from DT. It'd
> > > be nice if someone started working on converting i.MX to DT.
> >
> > Yes, that's how iMX6 does it. However note that Vybrid USB is not a true
> > OTG.
> >
> > I quote the Vybrid TRM here,
> >
> > "The USB is not a true OTG. It can be configured by software to function
> > either as a peripheral or as host. The ID pin, which is unique for OTG
> > operation, is not present in this implementation. There are no five pin
> > interface. The user will get four pin host/device interface."
>
> Can't the user use a GPIO instead of dedicated OTG switch pin ?
Yes. In fact in Linux we use the extcon framework along with the GPIO to have
automatic switch over between client and host.
I will send a patch by Monday to remove the incorrect code. Will later send
a patch to incoporate the correct fix. Since all boards might not have a GPIO
to do this I had not considered this option but if this is acceptable it is
fine by me.
Thanks.
- Sanchayan.
next prev parent reply other threads:[~2015-10-24 18:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 16:20 [U-Boot] Doubt in USB driver for Vybrid vf610 Santhosh
2015-10-17 16:29 ` maitysanchayan at gmail.com
2015-10-19 5:28 ` maitysanchayan at gmail.com
2015-10-19 6:21 ` Santhosh
2015-10-23 5:18 ` maitysanchayan at gmail.com
2015-10-23 18:23 ` Marek Vasut
2015-10-24 14:09 ` Fabio Estevam
2015-10-24 15:23 ` maitysanchayan at gmail.com
2015-10-24 16:08 ` Marek Vasut
2015-10-24 16:08 ` maitysanchayan at gmail.com
2015-10-24 16:16 ` Marek Vasut
2015-10-24 16:23 ` maitysanchayan at gmail.com
2015-10-24 17:50 ` Marek Vasut
2015-10-24 18:19 ` maitysanchayan at gmail.com [this message]
2015-10-24 18:34 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151024181814.GA24793@Sanchayan-Arch \
--to=maitysanchayan@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.