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. 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
