Re: MIDI gadget allocating too much from coherent pool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux