[U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep

[Marek Vasut]

On Thursday, June 12, 2014 at 10:36:55 AM, Jörg Krause wrote:
> On 06/10/2014 09:34 PM, Stephen Warren wrote:
> > On 06/02/2014 05:02 PM, Jörg Krause wrote:
> >> Sorry, my previous post was not shown correctly. The raw text was
> >> missing. I removed the annotation.
> >> 
> >> Since this commit my Ethernet Gadget on a custom Freescale i.MX28 board
> >> is
> > 
> >> broken. Using tftp to download files I get in almost all cases a timeout:
> > Sorry for the slow response; for some reason I didn't get a copy of the
> > message so I didn't notice it.
> > 
> > Could you tell me which include/config/xxx.h file you're using? I guess
> > if it's a custom board, perhaps that file isn't upstream. If so, I'm
> > particularly interested in whether you have CONFIG_USB_GADGET or
> > CONFIG_USB_ETHER enabled.
> 
> You're right, it's not upstream. This is a part of my config:
> 
> #    define CONFIG_CI_UDC     /* ChipIdea CI13xxx UDC */
> #    define CONFIG_USB_REG_BASE    0x80080000
> #    define CONFIG_USBD_HS    /* High speed support for usb device and
> usbtty. */
> #    define CONFIG_USB_GADGET_DUALSPEED
> #    define CONFIG_USB_ETHER
> #    define CONFIG_USB_ETH_CDC
> 
> > I wonder if applying the following series rather than reverting this
> > commits solves the issue?
> > 
> > [U-Boot,1/4] usb: ci_udc: detect queued requests on ep0
> > http://patchwork.ozlabs.org/patch/353926/
> > 
> > [U-Boot,2/4] usb: ci_udc: use a single descriptor for ep0
> > http://patchwork.ozlabs.org/patch/353932/
> > 
> > [U-Boot,3/4] usb: ci_udc: pre-allocate ep0 req
> > http://patchwork.ozlabs.org/patch/353931/
> > 
> > [U-Boot,4/4] usb: ci_udc: complete ep0 direction handling
> > http://patchwork.ozlabs.org/patch/353941/
> 
> Applied, but the error still exists.
> 
> > The only other thing I can think of is that there's some issue with the
> > bounce buffer alignment or size being wrong somehow. Perhaps try
> > increasing those?
> 
> I checked this and I found that ARCH_DMA_MINALIGN is set to 64, which is
> not true for Freescale i.MX28. This processor has an ARM926EJ-S, which
> has an cache line size of 32.
> 
> In arch/arm/include/asm/cache.h the macro ARCH_DMA_MINALIGN is defined
> as followed:
> 
> #ifdef CONFIG_SYS_CACHELINE_SIZE
> #define ARCH_DMA_MINALIGN    CONFIG_SYS_CACHELINE_SIZE
> #else
> #define ARCH_DMA_MINALIGN    64
> #endif
> 
> And in /arch/arm/cpu/arm926ejs/cache.c as followed:
> 
> #ifndef CONFIG_SYS_CACHELINE_SIZE
> #define CONFIG_SYS_CACHELINE_SIZE    32
> #endif
> 
> arch/arm/include/asm/cache.h does not see the definition of
> CONFIG_SYS_CACHELINE_SIZE in /arch/arm/cpu/arm926ejs/cache.c, so it's a
> bad place to put it in there.
> 
> I defined CONFIG_SYS_CACHELINE_SIZE to 32 in my config header file and
> it works under the following circumstances: I have to disable the macro
> CONFIG_USB_GADGET_DUALSPEED. But, and this is strange, it works only the
> first time of a tftp download after a reset of the board. If I try to
> use tftp a second time, I get the same timeout error as before.
> 
> So, in short:
> 
>     => reset
>     => run update_rootfs
>     [...]
>     done
>     => reset
>     => run update_rootfs
>     [...]
>     done
> 
> works and
> 
>     => reset
>     => run update_rootfs
>     [...]
>     done
>     => run update_rootfs
>     [...]
>     timeout sending packets to usb ethernet
> 
> results in a timeout. Strange.
> 
> Lastly, I changed CONFIG_SYS_CACHELINE_SIZE to 16 and this works for me
> in normal mode an in dual speed mode.
> 
> > Or, perhaps req->actual ends up being wrong, so ci_debounce() isn't
> > cache-invalidating or copying enough data? Perhaps try rounding up
> > req->len instead of req->actual when performing the cache invalidate?
> 
> I tried this, but with no success.
> 
> > I'm slightly confused by this log. Do you have 2 boards running U-Boot,
> > one running the USB controller in device mode, and this is the log from
> > some other board that's talking to that first board?
> 
> I have one board connect to a PC. The log shows two different errors
> happening on the board. The first log shows a tftp command on the board
> stopping with a timeout after receiving some packets. The second log
> shows a tftp command on the same board throwing an error before
> receiving any packet.

I sense buffer alignment issue. MXS aligns some buffer to 32b , but the CI block 
expects the buffer to be aligned to 64b or somesuch weird stuff.