public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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

      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