[U-Boot] USB-CDC with musb controller

[Vitaly Kuzmichev <vkuzmichev@mvista.com>]

Hi Remy,

I also have some fixes for ether.c.
How should I send them for review?
Through this mailing list or make 'git push' into private branch to
u-boot-usb.git repo?

On 08/11/2010 02:40 PM, Stefano Babic wrote:
> Remy Bohmer wrote:
>> Hi Stefano,
>>
> 
> Hi Remy,
> 
>> Indeed, this seems to be some debug logging that can be removed...
> 
> Ok, understood.
> 
>> We have tested it with the Atmel at91sam9261 core, and I have never
>> used it with any other hardware.
>> It is possible that you run into problems here that where not visible
>> on the Atmel core...
> 
> yes, this is what I have seen...
> 
>>
>>> I report the whole log, enabling debug output on both musb driver and
>>> ether.c. Do you have some hints to give me to go further ?
>>
>> This is my log when I do a (successful) ping to the host when I run on
>> a Atmel eval-kit.
>> Maybe you can use it as reference? Maybe it helps...
> 
> Thanks a lot, it really helped me ;-).
> 
> At least, I can now identify what a real problem is and what is not..
> 
> I can now complete the setup phase and the interface is working.
> I have found a couple of problems in ether.c that I will report to you.
> Of course, if you agree with my analyses, I will send patches to fix them.
> 
> 1. The status_req buffer is static allocated as u8. However, in
> eth_status_complete is referenced with a 32 bit pointer:
> 
>  __le32  *data = req->buf
> 
> In most case the buffer is not 32-bit aligned and causes an exception.
> 
> 2. In eth_bind a wrong ep is allocated.
> #if defined(DEV_CONFIG_CDC)
>         if (dev->status_ep) {
>                 dev->stat_req = usb_ep_alloc_request(gadget->ep0,
> GFP_KERNEL);
> 
> This should be:
> 
> dev->stat_req = usb_ep_alloc_request(dev->status_ep, GFP_KERNEL);
> 
> 3. Not sure about the handling in usb_eth_send. I do not know if the fix
> I propone works only for the musb driver or could be general and it was
> to me not clear as the packet_sent variable is managed:
> 
> 1834         while(!packet_sent)
> 1835         {
> 1836                 packet_sent=0;
> 1837         }
> 
> It seems there is no possibility to change packet_sent if we run in the
> loop....
> 
> I managed to call handle_interrupts() inside the loop to get it working.
> I can only assume that on your Atmel Core, tx_complete is called
> directly after running into usb_ep_queue, and then you have not this issue.
> But for most drivers, it should be required to call the interrupt
> routine (or something like that, but we have already
> handle_interrupts()) to manage all events.
> 
> Best regards,
> Stefano
>