Hi, On 08/07/2012 02:57 PM, Rajaram R wrote: > On Tue, Aug 7, 2012 at 5:26 PM, Rajaram R <rajaram.officemail@xxxxxxxxx> wrote: >> Hi Robert/Felipie >> >> On Thu, Aug 2, 2012 at 1:41 PM, Roger Quadros <rogerq@xxxxxx> wrote: >>> >>> Do not rely on any hints from gadget drivers and use DMA mode 1 >>> whenever we expect more data than the endpoint's packet size and >>> have not yet received a short packet. >>> >>> The last packet if short is always transferred using DMA mode 0. >>> >>> This patch fixes USB throughput issues in mass storage mode for >>> host to device transfers. >>> >>> Signed-off-by: Roger Quadros <rogerq@xxxxxx> >>> --- >>> drivers/usb/musb/musb_gadget.c | 30 ++++-------------------------- >>> 1 files changed, 4 insertions(+), 26 deletions(-) >>> >>> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c >>> index f7194cf..9c94655 100644 >>> --- a/drivers/usb/musb/musb_gadget.c >>> +++ b/drivers/usb/musb/musb_gadget.c >>> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct musb_request *req) >>> len = musb_readw(epio, MUSB_RXCOUNT); >>> >>> /* >>> - * Enable Mode 1 on RX transfers only when short_not_ok flag >>> - * is set. Currently short_not_ok flag is set only from >>> - * file_storage and f_mass_storage drivers >>> + * use mode 1 only if we expect data larger than ep packet_sz >>> + * and we have not yet received a short packet >>> */ >>> - >>> - if (request->short_not_ok && len == musb_ep->packet_sz) >>> + if ((request->length - request->actual > musb_ep->packet_sz) && >>> + (len >= musb_ep->packet_sz)) >> >> If the request length is 512 it can go in mode. Please add that while pushing. > > If the request length is 512 it can go in mode1. Please add that while pushing. > Do you mean that condition should be if ((request->length - request->actual >= musb_ep->packet_sz) && (len >= musb_ep->packet_sz)) use_mode_1 = 1; else use_mode_1 = 0; regards, -roger -- 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