public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom <Tom.Rix@windriver.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] MUSB-UDC issues and fixes
Date: Tue, 12 Jan 2010 07:50:30 -0600	[thread overview]
Message-ID: <4B4C7E26.5080906@windriver.com> (raw)
In-Reply-To: <a46a26fd1001111200x155b0419p987c7e851dbab73d@mail.gmail.com>

Juha Kuikka wrote:
> Hi,
> 
> I ran into some issues with the MUSB-UDC support while adding a new
> Davinci DM850/OMAP-L138 board:
> 
> 1. Move endpoint count into SoC specific musb-header file. This
> implementation only has 4 instead of 15 OMAP2/3 has.
> 2. On DM850 the MUSB interrupts are read from a wrapper, not from MUSB
> block . Add optional interface function to read-and-clear interrupts.
> 3. Problem setting FADDR - in udc_irq() the
> musb_peri_ep0_set_address() gets called on the same run as the ep0
> SET_ADDRESS request is handled. This causes the FADDR to change before
> the status stage interrupt is received and USB session fails. Fixed by
> removing extra call to musb_peri_ep0() from udc_irq(). It should only
> be called when EP0 interrupt is present.
> 4. udc_setup_ep() has a problem when id != 0, epinfo[] is indexed too
> far, this results in wrong EPs configured.
> 
> This is not a final patch, just asking for comments.
> 
> I am investigating another issue where rx endpoint stops receiving
> data when CDC ACM console is used. This happens under heavy inbound
> data conditions, namely using "loads".
> 
> -------------------------
> diff --git a/drivers/usb/musb/musb_udc.c b/drivers/usb/musb/musb_udc.c
> index fc43cf4..b6f9bff 100644
> --- a/drivers/usb/musb/musb_udc.c
> +++ b/drivers/usb/musb/musb_udc.c
> @@ -65,8 +65,6 @@
>  /* #define MUSB_DEBUG */
>  #include "musb_debug.h"
> 
> -#define MAX_ENDPOINT 15
> -
>  #define GET_ENDPOINT(dev,ep)						\
>  (((struct usb_device_instance *)(dev))->bus->endpoint_array + ep)
> 
> @@ -157,6 +155,17 @@ static void musb_db_regs(void)
>  #define musb_db_regs()
>  #endif /* DEBUG_MUSB */
> 
> +#ifndef CONFIG_MUSB_SOC_IRQ
> +static void musb_get_interrupts(u8 *usb, u16 *rx, u16 *tx)
> +{
> +	*usb = readb(&musbr->intrusb);
> +	*rx = readw(&musbr->intrrx);
> +	*tx = readw(&musbr->intrtx);
> +}
> +#else
> +extern void musb_get_interrupts(u8 *usb, u16 *rx, u16 *tx);
> +#endif
> +

The reading of INT registers clears them.
If all you want in the usb INT's, you will wipe out the rx/tx to
get them.

Tom

      parent reply	other threads:[~2010-01-12 13:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-11 20:00 [U-Boot] [RFC] MUSB-UDC issues and fixes Juha Kuikka
2010-01-11 21:35 ` Mike Frysinger
2010-01-12 13:50 ` Tom [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=4B4C7E26.5080906@windriver.com \
    --to=tom.rix@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox