From: Sergei Shtylyov <sshtylyov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
To: balbi-l0cyMroinI0@public.gmane.org
Cc: Sergei Shtylyov
<sshtylyov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>,
Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org"
<greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
David Brownell
<dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
"Gadiyar, Anand" <gadiyar-l0cyMroinI0@public.gmane.org>,
Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Subject: Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
Date: Tue, 14 Sep 2010 21:51:09 +0400 [thread overview]
Message-ID: <4C8FB60D.1080906@ru.mvista.com> (raw)
In-Reply-To: <20100914105402.GD7554-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
Hello.
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.
>> 'ís_dma' condition above the patched code:
>> if (is_dma || request->actual == request->length) {
>> and then it will hit the code sending the final ZLP (above this
>> patched code too):
> but this was already there before the patch.
Yes, and here lies the problem.
>> /*
>> * First, maybe a terminating short packet.
>> Some DMA
>> * engines might handle this by themselves.
>> */
>> if ((request->zero && request->length
>> && request->length %
>> musb_ep->packet_sz == 0)
>> #ifdef CONFIG_USB_INVENTRA_DMA
>> || (is_dma && (!dma->desired_mode ||
>> (request->actual &
>> (musb_ep->packet_sz -
>> 1))))
>> #endif
>> ) {
>> before the transfer is complete while it should only be hit when and
>> only when
>> the whole transfer is complete. The current code doesn't look correct
>> as well
>> though, all due to this 'ís_dma' condition. Surely this needs fixing.
> 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?
> the problem is not on the extra if () added below the quoted code,
> it's on the quoted code itself, which wasn't changed in any way.
Let me repeat: in the PIO mode the added check is just duplicate, in the DMA
mode it's added too late in the code, after ZLP/short packet send is triggered.
We should modify the check at the top of that code instead.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@mvista.com>
To: balbi@ti.com
Cc: Sergei Shtylyov <sshtylyov@mvista.com>,
Ming Lei <tom.leiming@gmail.com>,
"greg@kroah.com" <greg@kroah.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Brownell <dbrownell@users.sourceforge.net>,
"Gadiyar, Anand" <gadiyar@ti.com>,
Mike Frysinger <vapier@gentoo.org>
Subject: Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over
Date: Tue, 14 Sep 2010 21:51:09 +0400 [thread overview]
Message-ID: <4C8FB60D.1080906@ru.mvista.com> (raw)
In-Reply-To: <20100914105402.GD7554@legolas.emea.dhcp.ti.com>
Hello.
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.
>> 'ís_dma' condition above the patched code:
>> if (is_dma || request->actual == request->length) {
>> and then it will hit the code sending the final ZLP (above this
>> patched code too):
> but this was already there before the patch.
Yes, and here lies the problem.
>> /*
>> * First, maybe a terminating short packet.
>> Some DMA
>> * engines might handle this by themselves.
>> */
>> if ((request->zero && request->length
>> && request->length %
>> musb_ep->packet_sz == 0)
>> #ifdef CONFIG_USB_INVENTRA_DMA
>> || (is_dma && (!dma->desired_mode ||
>> (request->actual &
>> (musb_ep->packet_sz -
>> 1))))
>> #endif
>> ) {
>> before the transfer is complete while it should only be hit when and
>> only when
>> the whole transfer is complete. The current code doesn't look correct
>> as well
>> though, all due to this 'ís_dma' condition. Surely this needs fixing.
> 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?
> the problem is not on the extra if () added below the quoted code,
> it's on the quoted code itself, which wasn't changed in any way.
Let me repeat: in the PIO mode the added check is just duplicate, in the DMA
mode it's added too late in the code, after ZLP/short packet send is triggered.
We should modify the check at the top of that code instead.
WBR, Sergei
next prev parent reply other threads:[~2010-09-14 17:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 15:23 [RESEND/PATCH 0/6] USB: musb-gadget: bug fix tom.leiming-Re5JQEeQqe8AvxtiuMwx3w
2010-09-07 15:23 ` tom.leiming
2010-09-07 15:23 ` [RESEND/PATCH 1/6] USB: musb-gadget: fix kernel panic if using out ep with FIFO_TXRX style(v1) tom.leiming
2010-09-07 15:23 ` [RESEND/PATCH 2/6] USB: musb-gadget: fix bulk IN infinite hangs in double buffer case tom.leiming
2010-09-07 15:23 ` [RESEND/PATCH 3/6] USB: musb-gadget: enable autoclear for OUT transfer in both DMA 0 and DMA 1 tom.leiming
[not found] ` <1283873014-32511-1-git-send-email-tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-09-07 15:23 ` [RESEND/PATCH 4/6] USB: musb-gadget: fix DMA length for OUT transfer tom.leiming-Re5JQEeQqe8AvxtiuMwx3w
2010-09-07 15:23 ` tom.leiming
2010-09-07 15:23 ` [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over tom.leiming-Re5JQEeQqe8AvxtiuMwx3w
2010-09-07 15:23 ` tom.leiming
2010-09-13 12:27 ` Sergei Shtylyov
2010-09-13 14:34 ` Ming Lei
2010-09-13 14:34 ` Ming Lei
2010-09-13 15:51 ` Sergei Shtylyov
2010-09-13 16:26 ` Sergei Shtylyov
2010-09-14 6:56 ` Felipe Balbi
[not found] ` <20100914065604.GD2601-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2010-09-14 10:46 ` Sergei Shtylyov
2010-09-14 10:46 ` Sergei Shtylyov
2010-09-14 10:54 ` Felipe Balbi
2010-09-14 10:54 ` Felipe Balbi
[not found] ` <20100914105402.GD7554-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2010-09-14 17:51 ` Sergei Shtylyov [this message]
2010-09-14 17:51 ` Sergei Shtylyov
2010-09-15 6:53 ` Felipe Balbi
2010-09-15 9:56 ` Ming Lei
2010-09-15 10:01 ` Sergei Shtylyov
2010-09-15 10:05 ` Felipe Balbi
2010-09-15 10:08 ` Sergei Shtylyov
2010-09-15 10:14 ` Ming Lei
2010-09-15 10:18 ` Sergei Shtylyov
[not found] ` <4C909D87.2090901-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
2010-09-15 10:22 ` Felipe Balbi
2010-09-15 10:22 ` Felipe Balbi
[not found] ` <20100915102256.GK3393-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2010-09-15 10:27 ` Sergei Shtylyov
2010-09-15 10:27 ` Sergei Shtylyov
2010-09-15 10:31 ` Felipe Balbi
2010-09-15 10:41 ` Sergei Shtylyov
2010-09-15 10:52 ` Felipe Balbi
2010-09-15 13:02 ` Sergei Shtylyov
2010-09-15 10:37 ` Ming Lei
2010-09-07 15:23 ` [RESEND/PATCH 6/6] USB: musb-gadget: fix dma length in txstate tom.leiming-Re5JQEeQqe8AvxtiuMwx3w
2010-09-07 15:23 ` tom.leiming
2010-09-14 17:43 ` Sergei Shtylyov
2010-09-15 7:09 ` Felipe Balbi
2010-09-08 2:19 ` [RESEND/PATCH 0/6] USB: musb-gadget: bug fix Greg KH
[not found] ` <20100908021939.GA20443-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2010-09-08 4:32 ` Ming Lei
2010-09-08 4:32 ` Ming Lei
[not found] ` <AANLkTim605xLy8LjaKO+wR+UX2_r-dEQr=bMasXLAk22-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-09-08 6:18 ` Greg KH
2010-09-08 6:18 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C8FB60D.1080906@ru.mvista.com \
--to=sshtylyov-igf4poytycdqt0dzr+alfa@public.gmane.org \
--cc=balbi-l0cyMroinI0@public.gmane.org \
--cc=dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=gadiyar-l0cyMroinI0@public.gmane.org \
--cc=greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.