On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote: > > On Mon, Nov 02, 2009 at 09:51:13AM +0530, Gupta, Ajay Kumar wrote: > > > Is there any updated patch on cppi4.1 core also? > > > > Is there _any_ cppi4.1 core patch anywhere? Not according to google. > > Russell, > > Here is the latest version of cppi4.1 core. > http://patchwork.kernel.org/patch/46698/ A few points come up about this. 1. alloc_queue() - this is a find_next_zero_bit loop coupled with a check for the excluded bitmap. end = start + count; do { bit = find_next_zero_bit(allocated, end, start); if (bit >= end) return -ENOSPC; start = bit + 1; } while (test_bit(bit, excluded)); __set_bit(bit, allocated); return bit; Note that 'allocated' and 'excluded' both need to be arrays of unsigned long. 2. alloc_queue() again - it looks to me like the existing implementation is racy - who ensures that we don't have two people searching and allocating the same bit? A solution to that without adding locking would be: end = start + count; do { bit = find_next_zero_bit(allocated, end, start); if (bit >= end) return -ENOSPC; start = bit + 1; } while (test_bit(bit, excluded) || test_and_set_bit(bit, allocated)); return bit; 3. linking_ram - cppi41_queue_mgr_init() seems to be the only user. I don't see why linking_ram would be necessary. 4. debugging printks via pr_debug() please (and define DEBUG at the top of the file to enable debugging.) > > If it's a USB DMA device (from the patches I can find, that seems to be > > the case) then why can't it live in drivers/usb or drivers/dma ? > > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though > currently only USB is using it but in future even Ethernet devices may use it. drivers/dma does seem to be the right place for this. -- 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
