On Wed, Sep 23, 2015 at 12:39 PM, Felipe Tonello <eu@xxxxxxxxxxxxxxxxx> wrote: > Hi Peter, > > On Wed, Sep 23, 2015 at 4:09 AM, Peter Chen <peter.chen@xxxxxxxxxxxxx> wrote: >> On Tue, Sep 22, 2015 at 07:51:34PM +0100, Felipe Tonello wrote: >>> Hi all, >>> >>> On Tue, Sep 22, 2015 at 10:13 AM, Felipe Tonello <eu@xxxxxxxxxxxxxxxxx> wrote: >>> > Hi Peter, >>> > >>> > On Tue, Sep 22, 2015 at 8:03 AM, Peter Chen <peter.chen@xxxxxxxxxxxxx> wrote: >>> >> On Tue, Sep 22, 2015 at 09:07:23AM +0100, Felipe Tonello wrote: >>> >>> On Tue, Sep 22, 2015 at 12:41 AM, Peter Chen <peter.chen@xxxxxxxxxxxxx> wrote: >>> >>> > On Mon, Sep 21, 2015 at 03:25:28PM +0100, Felipe Tonello wrote: >>> >>> >> Hi all, >>> >>> >> >>> >>> >> I actually found the problem but can't really understand. The ci_irq() >>> >>> >> handler (from core.c) is not been called after a ep_queue() from >>> >>> >> f_midi_transmit(). >>> >>> >> >>> >>> >> Is there any reason for that? >>> >>> >> >>> >>> >> I used mass_storage gadget, made file transfers and others, and the >>> >>> >> interrupt handler was been called as expected. >>> >>> >> >>> >>> > >>> >>> > Which Soc are you using? And which kernel version are you using? >>> >>> >>> >>> i.MX6Q (industrial temp) and v4.2. We are using the imx6 REX module[1]. >>> >>> >>> >>> We checked the errata and didn't seem to have anything relevant. >>> >>> >>> >>> I wonder: was f_midi ever working properly, ie, complete callback ever called? >>> >>> >>> >> >>> >> Would you give your cpu revision number, and show me >>> >> how to reproduce it? I can test at my board. >>> > >>> > MCIMX6QAVT10AC >>> > >>> > To reproduce: >>> > * add this line to the f_midi_complete() function under the "case 0": >>> > >>> > VDBG(cdev, "%s normal completion (%d), %d/%d\n", ep->name, status, >>> > req->actual, req->length); >>> > >>> > * build a kernel with verbose debug enabled on USB gadget subsystem >>> > * load g_ether module (this will create an ALSA card and device) >>> > * connect device to host via usb otg cable. >>> > * to list the ALSA device, run `amidi -l', use the device listed as "f_midi" >>> > * send midi message using `amidi -p hw:1,0 -S 901010', my device is >>> > hw:1,0, check the output of amidi -l. >>> > * run `dmesg' you should see the message above, but if doesn't then >>> > probably the complete callback wasn't called as well. >>> > >>> > OBS: We have set the OTG_ID pin to type B (device), so no need to OTG >>> > cable on our side. >>> >>> I realized that when the device is connected to the host but the host >>> is not reading data, the device's interrupt will never be triggered. >>> Is that what is supposed to happen? >>> >>> For example: if I send lots of data via `amidi -s' from the device to >>> the host, but until I run `amidi -d' (which dumps data from buffer) on >>> the host the interrupt on the device is never triggered. >>> >>> I will send two or three small patches that improve the situation. >>> Freeing the request when not needed any more. >>> >> >> No, it is supposed. If the device does not queue request before host >> sends data, the device can't know when the host sends data. > > That's why my patch 2 is necessary. Sorry, patch number 3. Although I feel that number 2 is also an improvement, but not bug fix. Felipe -- 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
