From: Tony Lindgren <tony@atomide.com>
To: Antti P Miettinen <ananaza@iki.fi>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: USB gadget driver
Date: Fri, 3 Mar 2006 11:10:53 -0800 [thread overview]
Message-ID: <20060303191053.GI4398@atomide.com> (raw)
In-Reply-To: <p2gy81d4tnj.fsf@doris.dna.fi>
* Antti P Miettinen <ananaza@iki.fi> [060118 04:24]:
> While doing development for an OMAP2420 board I noticed that the
> "workaround for seemingly-lost IRQs for RX ACKs" in omap_udc.c needs a
> little tweak in order to prevent NFS root over usbnet from hanging.
> According to the documentation the status flag register should only be
> accessed when endpoint select bit is set in the EP_NUM register. See
> e.g. SPRU761A, end of page 78 (about STAT_FLG register):
>
> "This register cannot be read if EP_NUM.EP_SEL bit is not asserted for the
> endpoint."
>
> Similar statement seems to be in the specs for other OMAPs too.
>
> As a change for the workaround seem to have an effect it seems that
> there is indeed an underlying "IRQs get lost" problem?
>
> In principle reading the status flag in proc_ep_show() would need
> similar change, but I'm not sure how the EP selection would interact
> with interrupt processing. Actually I'm not sure how this change
> interacts with interrupt processing either but at least it cured the
> hangs for the 2420.
>
> It seems that usbnet with Nokia 770 is also a bit unreliable but this
> change does not seem to have an effect. Does someone have an OMAP
> based system where usbnet is reliable?
>
> --- drivers/usb/gadget/omap_udc.c~ 2005-12-13 14:49:29.000000000 +0200
> +++ drivers/usb/gadget/omap_udc.c 2006-01-16 15:20:52.000000000 +0200
> @@ -1897,7 +1897,7 @@
>
> spin_lock_irqsave(&ep->udc->lock, flags);
> if (!list_empty(&ep->queue) && ep->ackwait) {
> - use_ep(ep, 0);
> + use_ep(ep, UDC_EP_SEL);
> stat_flg = UDC_STAT_FLG_REG;
>
> if ((stat_flg & UDC_ACK) && (!(stat_flg & UDC_FIFO_EN)
> @@ -1907,12 +1907,14 @@
> VDBG("%s: lose, %04x\n", ep->ep.name, stat_flg);
> req = container_of(ep->queue.next,
> struct omap_req, queue);
> - UDC_EP_NUM_REG = ep->bEndpointAddress | UDC_EP_SEL;
> (void) read_fifo(ep, req);
> UDC_EP_NUM_REG = ep->bEndpointAddress;
> UDC_CTRL_REG = UDC_SET_FIFO_EN;
> ep->ackwait = 1 + ep->double_buf;
> }
> + else {
> + deselect_ep();
> + }
> }
> mod_timer(&ep->timer, PIO_OUT_TIMEOUT);
> spin_unlock_irqrestore(&ep->udc->lock, flags);
>
Thanks & sorry for the long delay with this patch. Pushing this one today.
Regards,
Tony
prev parent reply other threads:[~2006-03-03 19:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 12:17 USB gadget driver Antti P Miettinen
2006-03-03 19:10 ` Tony Lindgren [this message]
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=20060303191053.GI4398@atomide.com \
--to=tony@atomide.com \
--cc=ananaza@iki.fi \
--cc=linux-omap-open-source@linux.omap.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