From: Martin Fuzzey <mfuzzey@gmail.com>
To: Derald Woods <woods.rt@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: i.MX21 USB OTG
Date: Sat, 24 Mar 2012 15:10:25 +0100 [thread overview]
Message-ID: <CALBypN7p2uP0=ShSUfN3CsxZLZHrQZAfjfKDBsDDaLiMRXXSEw@mail.gmail.com> (raw)
In-Reply-To: <CAPhRStYbTCD6Lzhcfna4WRqYZhQRJrmiEyFm6egFovYdVso59g@mail.gmail.com>
Hi Derald,
On Fri, Mar 23, 2012 at 2:09 PM, Derald Woods <woods.rt@gmail.com> wrote:
> Hello Martin,
>
> I have an existing design that uses the i.MX21 ARM9 processor. The
> design currently uses an external USB OTG chip. The chip is now
> end-of-life. I know that this is an older ARM processor. It still meets
> most of the design needs. Is the i.MX21 OTG functionality considered
> reliable? I have not seen any real success stories with the i.MX21 USB
> OTG implementation. Our board currently utilizes the USB OTG chip at
> the bootloader and Linux kernel level.
>
It depends what you mean by OTG.
The i.MX21 silicon has 3 USB ports, two of which can only be used as
USB hosts and one which is configurable as host only, function
(device) only or OTG (dynamic switching).
Somewhat confusingly the Freescale documentation refers to the whole
module as "USB-OTG".
However the mainline code only supports host mode (there is no
function driver nor OTG support)
I mainlined the i.MX21 HCD driver for 2.6.34 and fixed a few bugs for
2.6.37 (in particular problems with non aligned buffers causing usbnet
to fail).
Since then I haven't had any bug reports, the driver also passes the
USB test suite (which I updated to check the buffer alignment
behaviour).
> I would appreciate being pointed in the right direction or warned of
> impending danger. Basically I want to know if the mx21 USB OTG has
> performed well for other embedded Linux designs.
>
Something very close to the original code on which I based the driver
was shipped with the Chumby (which uses a heavily patched 2.6.16
kernel). However that code had quite a few bugs and didn't support
isochronous transfers at all.
I don't have any direct feedback myself of real world use of the
driver however since we ended up not shipping an iMX21 based Linux
product for non technical reasons.
> I had originally posted to the Barebox mailing list.
>
Ah I'm not subscribed to that list - adding it as a CC hoping it's not
subscriber only
Cheers,
Martin Fuzzey
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next parent reply other threads:[~2012-03-24 14:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPhRStYbTCD6Lzhcfna4WRqYZhQRJrmiEyFm6egFovYdVso59g@mail.gmail.com>
2012-03-24 14:10 ` Martin Fuzzey [this message]
2012-03-24 16:15 ` Derald D. Woods
2012-03-22 23:25 Derald D. Woods
2012-03-23 8:36 ` Sascha Hauer
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='CALBypN7p2uP0=ShSUfN3CsxZLZHrQZAfjfKDBsDDaLiMRXXSEw@mail.gmail.com' \
--to=mfuzzey@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=woods.rt@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox