[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C909961.10001@ru.mvista.com>
Date: Wed, 15 Sep 2010 14:01:05 +0400
From: Sergei Shtylyov <sshtylyov@...sta.com>
To: balbi@...com
CC: Sergei Shtylyov <sshtylyov@...sta.com>,
Ming Lei <tom.leiming@...il.com>,
"greg@...ah.com" <greg@...ah.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Brownell <dbrownell@...rs.sourceforge.net>,
"Gadiyar, Anand" <gadiyar@...com>,
Mike Frysinger <vapier@...too.org>
Subject: Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if
data is transfered over
Hello.
On 15-09-2010 10:53, Felipe Balbi wrote:
>>>> If a DMA interrupt comes when the whole transfer is not yet
>>>> complete (and
>>>> other Ming Lei's patches are making this possible),
>> Oh, here I mixed some other patch with Ming Lei's ones...
>>>> it will pass due to the
>>> than this is the actual problem, no ? If we're using mode1 dma (as we
>>> are on tx path), we should only get dma interrupt when the whole
>>> transfer has been completed.
>> The Inventra DMA controller has serious DMA length limitation, so the whole
>> transfer may take more than one DMA.
> When I said 'whole transfer' I meant the transfer size you programmed
> dma to transfer, see that we have (not actual code):
> if (transfer_size > dma->max_len)
> transfer_size = dma->max_len;
> dma->channel_program(...,..., transfer_size,...);
Ah, I didn't mean the same thing -- I meant the transfer size as specified
by 'struct usb_request'.
> with mode1, we will only get irq when dma has transferred transfer_size
> bytes.
Sure.
>>> likewise, this was there before the patch. I don't think the real
>>> problem lies with this patch, it's been there for a while, don't you
>>> agree ?
>> Then what problem this patch fixes, if not this one?
> if request->length == 1MB and dma->max_len = 128KB, when is_dma is true,
> request->actual will be different from request->length for 7
> 'iterations', then only on the 8th it will be the same. I believe that's
> what Ming is trying to fix.
I repeat once again: it's too late to check this where Ming is inserting
the check.
> Ming, am I correct ?
>
>> Let me repeat: in the PIO mode the added check is just duplicate, in the DMA
> it is duplicate for PIO, but not for DMA.
I didn't say it was duplicate for DMA, just too late.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists