[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN3PR0301MB08494846EDC5DB72C6E14A0D81B50@BN3PR0301MB0849.namprd03.prod.outlook.com>
Date: Tue, 2 Jun 2015 03:01:12 +0000
From: Peter Chen <Peter.Chen@...escale.com>
To: "Baxter, Jim" <jim_baxter@...tor.com>
CC: Robert Baldyga <r.baldyga@...sung.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"Zapolskiy, Vladimir" <Vladimir_Zapolskiy@...tor.com>,
"balbi@...com" <balbi@...com>
Subject: RE: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
> >>>>
> >>>> Thank you, that sounds like the best approach.
> >>>> In this case I think perhaps the long wait without any data is an
> >>>> problem with the imx6 Chipidea USB controller.
> >>>
> >>> What's the possible problem?
> >>
> >> Sorry for the delay in replying, I have been getting some more
> >> details with a USB Analyser.
> >>
> >> The scenario is that the NCM device is enumerating so we see the
> messages to:
> >>
> >> SetAddress (1)
> >> GetDescriptor (Device)
> >> GetDescriptor (StringN)
> >> GetDescriptor (Configuration)
> >> SetConfiguration (1)
> >> GetDescriptor (String iInterface)
> >> GetDescriptor (String iInterface)
> >>
> >> At this point the NCM host sends Writes to the F_FS EP0 but for some
> >> reason the host device does not respond and only issues SOF packets
> >> for hours. This happens occasionally and is fixed by turning the device off
> and on again.
> >>
> >>
> >
> > We may find this 'some reason', is it device error or host error?
> >
> > Do you have below patch in your code:
> >
> > commit 953c66469735aed8d2ada639a72b150f01dae605
> > Author: Abbas Raza <Abbas_Raza@...tor.com>
> > Date: Thu Jul 17 19:34:31 2014 +0800
> >
> > usb: chipidea: udc: Disable auto ZLP generation on ep0
> >
> > There are 2 methods for ZLP (zero-length packet) generation:
> > 1) In software
> > 2) Automatic generation by device controller
> >
> > 1) is implemented in UDC driver and it attaches ZLP to IN packet if
> > descriptor->size < wLength
> > 2) can be enabled/disabled by setting ZLT bit in the QH
> >
> > Peter
>
> Yes I have that patch, could that be a problem?
>
No, you need that patch.
Get to know which side has problem first.
Peter
> Jim
>
> >
> >> Unless I am mistaken from a NCM gadget point of view the attached
> >> device is working correctly and there is no way to know it has failed, is that
> correct?
> >>
> >>>
> >>>>
> >>>> I guess it should suspend and drop the connections if there is no
> >>>> traffic for more than 10ms?
> >>>>
> >>>
> >>> If the Device side NAK host's IN/OUT token continually, the pipe
> >>> will not be stopped, the host will send token continually until the
> >>> application cancel this request.
> >>>
--
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