public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Amit Blay" <ablay@codeaurora.org>
To: "Sarah Sharp" <sarah.a.sharp@linux.intel.com>
Cc: "Tatyana Brokhman" <tlinder@codeaurora.org>,
	greg@kroah.com, linux-usb@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, balbi@ti.com,
	ablay@codeaurora.org, "Amit Blay" <ablay@qualcomm.com>,
	"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC 5/5] usb: Add support for streams alloc/dealloc to  devio.c
Date: Tue, 19 Jul 2011 02:12:39 -0700 (PDT)	[thread overview]
Message-ID: <8bcfda19cbc633e011e6b28a6183e68b.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <20110630174538.GA7979@xanatos>

Hi Sarah,

I apologize for the delay responding to the thread. Thanks for your
comments. I would like to continue and fix the previous patch according to
the comments.
Also, I would like to split this patch, and implement the actual usage of
streams for bulk EP transfers (passing the stream ID with the URB) to a
different patch.

>
> It looks like userspace doesn't have a way to specify the number of
> streams USBFS needs to allocate.  Not all userspace applications are

> You probably also need a way to communicate back to userspace how many
> streams were actually allocated.  The program could choose to free

> So you're just taking the max_streams from the first endpoint that has
> streams?  What if other endpoints have varying numbers of max streams?

> What if you have endpoints on an interface that don't support streams?

> So it seems like you also need a way for userspace to specify which
> endpoints get streams, and which endpoints have streams freed.  I will

What I have in mind is user space passing a structure holding:

1. Interface number [IN]
2. Bitmap indicating which EP to allocate streams for [IN]
3. Number of streams to allocate, one number [IN}
4. Number of streams actually allocated, one number  [OUT]

The devio alloc function will double check if all EPs belong to the
interface passed by the user space.
Then it will call the HCI alloc function with the required number of
streams. It will return the number of streams actually allocated by the
HCD. Items 3 & 4 can be merged to one IN/OUT parameter.

No error checking will be done in devio for number of required streams
(i.e, comparing it with the reported max streams). This kind of error
checking is already done by the xHCI driver.

Please let me know if the solution is acceptable.

Thanks,
Amit.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


  parent reply	other threads:[~2011-07-19  9:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 13:31 [PATCH/RFC 1/5] usb:tools: usb unittests framework Tatyana Brokhman
2011-06-16 13:31 ` [PATCH/RFC 2/5] usb:dummy_hcd: connect/disconnect test support Tatyana Brokhman
2011-06-16 15:06   ` Alan Stern
2011-06-16 16:16     ` Felipe Balbi
2011-06-16 17:06       ` Alan Stern
2011-06-16 17:19         ` Alan Stern
2011-06-16 15:17   ` Alan Stern
2011-06-16 16:18   ` Felipe Balbi
2011-06-16 13:31 ` [PATCH/RFC 3/5] usb:g_zero: bulk in/out unittest support Tatyana Brokhman
2011-06-16 16:25   ` Felipe Balbi
2011-06-16 13:31 ` [PATCH/RFC 4/5] usb:dummy_hcd: Disable single-request fifo in dummy hcd Tatyana Brokhman
2011-06-16 15:09   ` Alan Stern
2011-06-16 13:31 ` [PATCH/RFC 5/5] usb: Add support for streams alloc/dealloc to devio.c Tatyana Brokhman
2011-06-16 15:20   ` Alan Stern
2011-06-16 16:28   ` Felipe Balbi
2011-06-16 18:21     ` Greg KH
2011-06-17  8:55       ` ablay
2011-06-17 14:35         ` Alan Stern
2011-06-30 17:45   ` Sarah Sharp
2011-06-30 18:39     ` William Gulland
2011-06-30 18:41     ` Tanya Brokhman
2011-07-19  9:12     ` Amit Blay [this message]
2011-07-19  9:18       ` Oliver Neukum
2011-07-19 10:07         ` Amit Blay
2011-07-19 10:26           ` Oliver Neukum
2011-07-19 10:36             ` Amit Blay
2011-07-27  6:21       ` Amit Blay
2011-08-17  7:06         ` Hans Petter Selasky
2011-08-18 22:47         ` Sarah Sharp
2011-08-21 10:18           ` Amit Blay
2011-08-22  7:58             ` Hans Petter Selasky
2011-08-22  7:56           ` Hans Petter Selasky
2011-08-22 16:41             ` Sarah Sharp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8bcfda19cbc633e011e6b28a6183e68b.squirrel@www.codeaurora.org \
    --to=ablay@codeaurora.org \
    --cc=ablay@qualcomm.com \
    --cc=balbi@ti.com \
    --cc=greg@kroah.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    --cc=tlinder@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox