Hi Steve,
thanks for the answer. Here is the part of the code which handles the
IN-transfer. I used the same code on an Olimex (Atmel AT91 cpu)
development board using linux 2.6.23 and it worked well.
====
extern int own_udp_send(char* ext_buf, int size);
static void read_bulk_callback (struct urb *urb)
{
if (urb->status)
{
printk(KERN_ERR "read_callback: error %d \n", urb->status);
return;
}
if( urb->actual_length != 64)
printk(KERN_ERR "read_callback: ERROR: wrong packet size: %d
\n",urb->actual_length);
// This function sends the data over the ethernet port using udp.
own_udp_send(urb->transfer_buffer,urb->actual_length);
kfree(urb->transfer_buffer);
usb_free_urb(urb);
return;
}
====
void create_IN_urb(void){
struct urb *inurb = NULL;
int buffer_size=64;
int retval;
char *buf = NULL;
inurb = usb_alloc_urb(0, GFP_KERNEL);
if (!inurb)
{
ret = -ENOMEM;
goto error;
}
buffer_size = 64;
buf = kmalloc(buffer_size, GFP_KERNEL);
if (!buf)
{
ret = -ENOMEM;
goto error;
}
usb_fill_bulk_urb(inurb, skel_dev->udev,
usb_rcvbulkpipe(skel_dev->udev, skel_dev->bulk_in_endpointAddr),
buf, buffer_size, read_bulk_callback, skel_dev);
ret = usb_submit_urb (inurb, GFP_ATOMIC);
if (retval)
{
printk(KERN_ERR "failed resubmitting read urb");
}
error:
return;
}
====
-The device operates in full-speed
-The packets on the bus are checked with a Beagle USB protocol analyzer
and contain the right data
-The return status of the urb is 0
-Actual length is 64 byte, as it should be
-If the buffer contains wrong data, always the 32 lower and/or the 32
higher bytes in the 64 bytes buffer are corrupted.
-I want to receive 10 data packets with each 64 bytes
-If I crate 10 urbs, 20-30% of the data is corrupted
-If I only use one urb and resubmit it in the completion handler for the
next transfer only a few packets are corrupted.
-I don't access the buffer after submitting it to the usb endpoint
-To test the buffer I initialized the whole buffer with f. ex. 0xEE.
After transfer the corrupted packets contained this value always 32 or
64 bytes of 0xEE).
How can I figure out the cache line size?
Regards
Johannes
Steve Calfee wrote:
On Thu, Jul 23, 2009 at 2:20 AM, Johannes<joh.schrimpf@xxxxxxxxx> wrote:
Hi,
I am writing an USB driver and have a problem with the bulk-IN transfer. I
create some urbs and send them to the IN-endpoint with a buffer created by
kmalloc. The buffer size is 64 byte, which is the same size as the packets
which are send over the USB-connection. The status of the urb in the
callback function is 0 and the actual_length is 64, but I figured out that
the data in the buffer is not correct. In most packets, parts of the buffer,
either the first 32 bytes or the second 32 bytes, still contain the
initialization values of the buffer.
I am using linux-omap3-2.6.29 on a Gumstix overo board.
Do you have an idea what the problem could be?
For more help, include more info. A copy of your driver would really help.
The arm processor is not cache coherent. What is the cache line size?
Check your kmalloc args. Don't touch (debug print) a buffer once the
urb is submitted to the core, it will put initial data into the cpu
cache and you will not read the dma'ed data from memory after
completion. Usbmon or an analyzer will help determine that a bus
operation occurred.
Regards, Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
