> > 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.) Thanks for the review and valuable comments. As we have to change the current implementation in accordance with standard DMA APIs, we will take above comments and post it in next RFC. Regards, Ajay > > > 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
