[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Russell King - ARM Linux]

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.