[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100915105641.GO3393@legolas.emea.dhcp.ti.com>
Date: Wed, 15 Sep 2010 13:56:41 +0300
From: Felipe Balbi <balbi@...com>
To: Ming Lei <tom.leiming@...il.com>
Cc: Sergei Shtylyov <sshtylyov@...sta.com>,
"Balbi, Felipe" <balbi@...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: [Discussion] USB: musb-gadget: how to fix ZLP issue in
musb_g_tx
Hi,
On Wed, Sep 15, 2010 at 05:53:10AM -0500, Ming Lei wrote:
>1), why is the check for "is_dma" needed here?
>
> if (is_dma || request->actual == request->length) {
> ....
> }
if you programmed dma to request->length (and assuming it worked just
fine) mode1 will only interrupt you when the entire request has been
sent.
>2), why is a zlp needed in the case below?
>
> #ifdef CONFIG_USB_INVENTRA_DMA
> || (is_dma && (!dma->desired_mode ||
> (request->actual & (musb_ep->packet_sz - 1))))
> #endif
in that case, it's not a zlp, it's short packet. Inventra will *NOT*
transfer short packets, you need to set txpktrdy by hand to get it
transfered.
>IMO, it is not difficult to give a good fix for the ZLP problem
>if the two questions are clear.
true, but some re-work needs to be done.
--
balbi
--
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