On 11/11/2014 08:20 PM, Sebastian Reimers wrote: > Hi Sebastian, > Hi Daniel, > > after some debugging the 25 microseconds loop only catches <1% of early_tx > transfers (with your patch #1). Most of them are catched in the hrtimer (incl. re-loop) > between 30-60 microseconds. Any debug code suggestions to get reliable values? I`m > not sure if my current affects timing. protocol with trace_printk or measure max, min and avg with no output and have a sysfs / debugfs file for output. > With Daniels usb: musb: cppi41: tweak hrtimer > values its better. > The only negative is, that CPU usage is higher compared to PIO mode. > But maybe this is a restriction of DMA and smaller packet size. > > cppi41_channel->total_len is 40 bytes. It is higher because what happens now is very close to a busy loop. If you take 40/10 => 4 so you setup your timer in 4us. There is the slack of 20us but you see. And then you setup the next timer in 20us if I remember correctly. Given the "normal" runtime of everything the system has very little break between the reschedule. You could measure the time with ktime_get() and compare the time you need for setup DMA and "complete the DMA transfer" and compare it with the time you need in PIO mode. Since it is "just" 40 bytes I would assume that you might be better off without DMA. If so we could think about rejecting DMA requests for transfers < x bytes and let PIO handle it. In USB-storage the protocol makes it possible to enqueue 16KiB as one TX request where in PIO mode you would have to fill the FIFO 32 times. You see the difference. I've been browsing the manual and I don't see a possibility where I could enqueue multiple DMA requests for one endpoint and then once the first one completes, the next one would start on its own on the next interval (in case of ISO). Then we could have relaxed poll interval ;) > 48 kHz / 32 Bit - Stereo High Speed USB Host. Sebastian -- 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
