[PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
req->actual == req->length means that there is no data left to enqueue,
so free the request.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index edb84ca..93212ca 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request *req)
/* We received stuff. req is queued again, below */
f_midi_handle_out_data(ep, req);
} else if (ep == midi->in_ep) {
- /* Our transmit completed. See if there's more to go.
-* f_midi_transmit eats req, don't queue it again. */
- f_midi_transmit(midi, req);
+ /* Our transmit completed. Don't queue it again. */
+ free_ep_req(ep, req);
return;
}
break;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Felipe Tonello wrote:
> req->actual == req->length means that there is no data left to enqueue,
This condition is not checked in the patch.
> so free the request.
>
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/usb/gadget/function/f_midi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> diff --git a/drivers/usb/gadget/function/f_midi.c
> b/drivers/usb/gadget/function/f_midi.c
> index edb84ca..93212ca 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
> *req)
> /* We received stuff. req is queued again, below */
> f_midi_handle_out_data(ep, req);
> } else if (ep == midi->in_ep) {
> - /* Our transmit completed. See if there's more to go.
> - * f_midi_transmit eats req, don't queue it again. */
> - f_midi_transmit(midi, req);
> + /* Our transmit completed. Don't queue it again. */
> + free_ep_req(ep, req);
> return;
> }
> break;
The ALSA framework will give you a notification _once_. If the
resulting data is larger than midi->buflen, then you have to continue
sending packets. This is exactly what the call to f_midi_transmit()
does.
(To decrease latency, it might be a good idea to queue multiple requests,
but you wouldn't want to continue piling up requests if the host isn't
listening. sound/usb/midi.c just allocates a fixed number of requests,
and always reuses them.)
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Hi,
Clemens Ladisch writes:
> Felipe Tonello wrote:
>> req->actual == req->length means that there is no data left to enqueue,
>
> This condition is not checked in the patch.
>
>> so free the request.
>>
>> Signed-off-by: Felipe F. Tonello
>> ---
>> drivers/usb/gadget/function/f_midi.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>> b/drivers/usb/gadget/function/f_midi.c
>> index edb84ca..93212ca 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
>> *req)
>> /* We received stuff. req is queued again, below */
>> f_midi_handle_out_data(ep, req);
>> } else if (ep == midi->in_ep) {
>> -/* Our transmit completed. See if there's more to go.
>> - * f_midi_transmit eats req, don't queue it again. */
>> -f_midi_transmit(midi, req);
>> +/* Our transmit completed. Don't queue it again. */
>> +free_ep_req(ep, req);
>> return;
>> }
>> break;
>
> The ALSA framework will give you a notification _once_. If the
> resulting data is larger than midi->buflen, then you have to continue
> sending packets. This is exactly what the call to f_midi_transmit()
> does.
>
> (To decrease latency, it might be a good idea to queue multiple requests,
> but you wouldn't want to continue piling up requests if the host isn't
> listening. sound/usb/midi.c just allocates a fixed number of requests,
> and always reuses them.)
so, should I drop this series from my TODO queue ?
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Felipe Balbi wrote:
> Clemens Ladisch writes:
>> Felipe Tonello wrote:
>>> req->actual == req->length means that there is no data left to enqueue,
>>
>> This condition is not checked in the patch.
>>
>>> so free the request.
>>>
>>> Signed-off-by: Felipe F. Tonello
>>> ---
>>> drivers/usb/gadget/function/f_midi.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>> diff --git a/drivers/usb/gadget/function/f_midi.c
>>> b/drivers/usb/gadget/function/f_midi.c
>>> index edb84ca..93212ca 100644
>>> --- a/drivers/usb/gadget/function/f_midi.c
>>> +++ b/drivers/usb/gadget/function/f_midi.c
>>> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
>>> *req)
>>> /* We received stuff. req is queued again, below */
>>> f_midi_handle_out_data(ep, req);
>>> } else if (ep == midi->in_ep) {
>>> - /* Our transmit completed. See if there's more to go.
>>> -* f_midi_transmit eats req, don't queue it again. */
>>> - f_midi_transmit(midi, req);
>>> + /* Our transmit completed. Don't queue it again. */
>>> + free_ep_req(ep, req);
>>> return;
>>> }
>>> break;
>>
>> The ALSA framework will give you a notification _once_. If the
>> resulting data is larger than midi->buflen, then you have to continue
>> sending packets. This is exactly what the call to f_midi_transmit()
>> does.
>
> so, should I drop this series from my TODO queue ?
Yes, this patch needs to be dropped.
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Hi Clemens
On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch wrote:
> Felipe Tonello wrote:
>> req->actual == req->length means that there is no data left to enqueue,
>
> This condition is not checked in the patch.
>
>> so free the request.
>>
>> Signed-off-by: Felipe F. Tonello
>> ---
>> drivers/usb/gadget/function/f_midi.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>> b/drivers/usb/gadget/function/f_midi.c
>> index edb84ca..93212ca 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
>> *req)
>> /* We received stuff. req is queued again, below */
>> f_midi_handle_out_data(ep, req);
>> } else if (ep == midi->in_ep) {
>> - /* Our transmit completed. See if there's more to go.
>> - * f_midi_transmit eats req, don't queue it again. */
>> - f_midi_transmit(midi, req);
>> + /* Our transmit completed. Don't queue it again. */
>> + free_ep_req(ep, req);
>> return;
>> }
>> break;
>
> The ALSA framework will give you a notification _once_. If the
> resulting data is larger than midi->buflen, then you have to continue
> sending packets. This is exactly what the call to f_midi_transmit()
> does.
That's true. But what it will also happen is that f_midi_transmit()
will potentially eat up data from an unrelated ALSA trigger.
In the end it is all fine, because the function will realise the
request->len == 0 so it will free the request. But logically speaking
it is incorrect and error prone.
>
> (To decrease latency, it might be a good idea to queue multiple requests,
> but you wouldn't want to continue piling up requests if the host isn't
> listening. sound/usb/midi.c just allocates a fixed number of requests,
> and always reuses them.)
I believe that is the best way to implement. Create multiple requests
until the ALSA substreams buffer are empty and free the request on
completion.
The problem of having requests when host isn't listening will happen
anyway because there is no way to know that until completion.
What do you think?
Felipe Tonello
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Hi Balbi,
On Sun, Oct 11, 2015 at 8:08 PM, Clemens Ladisch wrote:
> Felipe Balbi wrote:
>> Clemens Ladisch writes:
>>> Felipe Tonello wrote:
req->actual == req->length means that there is no data left to enqueue,
>>>
>>> This condition is not checked in the patch.
>>>
so free the request.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index edb84ca..93212ca 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -256,9 +256,8 @@ f_midi_complete(struct usb_ep *ep, struct usb_request
*req)
/* We received stuff. req is queued again, below */
f_midi_handle_out_data(ep, req);
} else if (ep == midi->in_ep) {
- /* Our transmit completed. See if there's more to go.
-* f_midi_transmit eats req, don't queue it again. */
- f_midi_transmit(midi, req);
+ /* Our transmit completed. Don't queue it again. */
+ free_ep_req(ep, req);
return;
}
break;
>>>
>>> The ALSA framework will give you a notification _once_. If the
>>> resulting data is larger than midi->buflen, then you have to continue
>>> sending packets. This is exactly what the call to f_midi_transmit()
>>> does.
>>
>> so, should I drop this series from my TODO queue ?
>
> Yes, this patch needs to be dropped.
You don't need to drop the whole series. Just this patch needs more
work, the rest are fine (including bug fixes).
Felipe Tonello
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Felipe Tonello wrote:
> On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch wrote:
>> Felipe Tonello wrote:
>>> } else if (ep == midi->in_ep) {
>>> - /* Our transmit completed. See if there's more to go.
>>> - * f_midi_transmit eats req, don't queue it again. */
>>> - f_midi_transmit(midi, req);
>>> + /* Our transmit completed. Don't queue it again. */
>>> + free_ep_req(ep, req);
>>> return;
>>> }
>>> break;
>>
>> The ALSA framework will give you a notification _once_. If the
>> resulting data is larger than midi->buflen, then you have to continue
>> sending packets. This is exactly what the call to f_midi_transmit()
>> does.
>
> That's true. But what it will also happen is that f_midi_transmit()
> will potentially eat up data from an unrelated ALSA trigger.
The triggers are for some MIDI port of the _same_ USB endpoint, so
they're not unrelated. f_midi_transmit() collects data from all ports
anyway; separating the data from different ports into different USB
packets would just needlessly introduce additional latency.
> In the end it is all fine, because the function will realise the
> request->len == 0 so it will free the request. But logically speaking
> it is incorrect and error prone.
It is _not_ incorrect if you realize that f_midi_transmit() applies to
the endpoint, not to any particular port.
>> (To decrease latency, it might be a good idea to queue multiple requests,
>> but you wouldn't want to continue piling up requests if the host isn't
>> listening. sound/usb/midi.c just allocates a fixed number of requests,
>> and always reuses them.)
>
> I believe that is the best way to implement. Create multiple requests
> until the ALSA substreams buffer are empty and free the request on
> completion.
I believe a better way to implement this is to allocate a fixed number
of requests, and to always reuse them.
> The problem of having requests when host isn't listening will happen
> anyway because there is no way to know that until completion.
But if you have no upper limit on the number of queues requests, you
will eventually run out of (DMA) memory.
Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Hi Clemens
On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch wrote:
> Felipe Tonello wrote:
>> On Fri, Oct 9, 2015 at 10:23 AM, Clemens Ladisch wrote:
>>> Felipe Tonello wrote:
} else if (ep == midi->in_ep) {
- /* Our transmit completed. See if there's more to go.
- * f_midi_transmit eats req, don't queue it again. */
- f_midi_transmit(midi, req);
+ /* Our transmit completed. Don't queue it again. */
+ free_ep_req(ep, req);
return;
}
break;
>>>
>>> The ALSA framework will give you a notification _once_. If the
>>> resulting data is larger than midi->buflen, then you have to continue
>>> sending packets. This is exactly what the call to f_midi_transmit()
>>> does.
>>
>> That's true. But what it will also happen is that f_midi_transmit()
>> will potentially eat up data from an unrelated ALSA trigger.
>
> The triggers are for some MIDI port of the _same_ USB endpoint, so
> they're not unrelated. f_midi_transmit() collects data from all ports
> anyway; separating the data from different ports into different USB
> packets would just needlessly introduce additional latency.
Ok.
>
>> In the end it is all fine, because the function will realise the
>> request->len == 0 so it will free the request. But logically speaking
>> it is incorrect and error prone.
>
> It is _not_ incorrect if you realize that f_midi_transmit() applies to
> the endpoint, not to any particular port.
>
>>> (To decrease latency, it might be a good idea to queue multiple requests,
>>> but you wouldn't want to continue piling up requests if the host isn't
>>> listening. sound/usb/midi.c just allocates a fixed number of requests,
>>> and always reuses them.)
>>
>> I believe that is the best way to implement. Create multiple requests
>> until the ALSA substreams buffer are empty and free the request on
>> completion.
>
> I believe a better way to implement this is to allocate a fixed number
> of requests, and to always reuse them.
How many?
>
>> The problem of having requests when host isn't listening will happen
>> anyway because there is no way to know that until completion.
>
> But if you have no upper limit on the number of queues requests, you
> will eventually run out of (DMA) memory.
And that's what happening at the moment. One of my patches are to fix
a memory leak when that happens.
But it would be ideal to have a FIFO of requests and perhaps ignore
new requests if the FIFO is full.
So, allocate (pre-allocate?) new requests until the FIFO is full. Upon
completion, remove the request from FIFO, but still reuse it on
f_midi_transmit() and queue it on the FIFO again if there is still
data from ALSA, otherwise just free the request.
What do you think?
Felipe Tonello
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] usb: gadget: f_midi: free usb request when done
Felipe Tonello wrote: > On Mon, Oct 12, 2015 at 11:16 AM, Clemens Ladisch wrote: >> Felipe Tonello wrote: >>> I believe that is the best way to implement. Create multiple requests >>> until the ALSA substreams buffer are empty and free the request on >>> completion. >> >> I believe a better way to implement this is to allocate a fixed number >> of requests, and to always reuse them. > > How many? Enough to get proper pipelining. At least two, maybe not more. (Depends on how fast those tiny CPUs can queue the next request.) >>> The problem of having requests when host isn't listening will happen >>> anyway because there is no way to know that until completion. >> >> But if you have no upper limit on the number of queues requests, you >> will eventually run out of (DMA) memory. > > And that's what happening at the moment. One of my patches are to fix > a memory leak when that happens. > > But it would be ideal to have a FIFO of requests and perhaps ignore > new requests if the FIFO is full. > > So, allocate (pre-allocate?) new requests until the FIFO is full. Upon > completion, remove the request from FIFO, but still reuse it on > f_midi_transmit() and queue it on the FIFO again if there is still > data from ALSA, otherwise just free the request. Yes, that's exactly what I'm proposing. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
