From: Mauro Carvalho Chehab <m.chehab@samsung.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Xenia Ragiadakou <burzalodowa@gmail.com>,
linux-usb@vger.kernel.org, linux-input@vger.kernel.org,
linux-media@vger.kernel.org
Subject: Re: New USB core API to change interval and max packet size
Date: Wed, 02 Oct 2013 13:15:50 -0300 [thread overview]
Message-ID: <20131002131550.38f90611@samsung.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1310021057250.1293-100000@iolanthe.rowland.org>
Em Wed, 02 Oct 2013 11:00:13 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> escreveu:
> On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
>
> > Let me see if I understand the changes at the media drivers. So, please
> > correct me if I got it wrong.
> >
> > I'm yet to get any USB 3.0 media device, although it is common to connect
> > an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
> >
> > So, for example, on this device:
>
> > ...
> > Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x83 EP 3 IN
> > bmAttributes 3
> > Transfer Type Interrupt
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0004 1x 4 bytes
> > bInterval 1
> > ...
> >
> > connected via this BUS device:
>
> ...
>
> > In such situation, and assuming that the USB tables are correct, there's
> > nothing that needs to be done there, as bInterval/wMaxPacketSize are
> > correct for USB 2.0.
> >
> > So, there's no need to call usb_change_ep_bandwidth().
>
> That's right.
>
> > If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> > or wMaxPacketSize were improperly filled.
> >
> > Right?
>
> Or if the values are correct, but the driver wants to use something
> different for its own reasons (for example, to get lower latency or
> because it knows that it will never use packets as large as the
> descriptor allows). Right.
Ok, so, in this case, usb_change_ep_bandwidth() could be called
just before usb_alloc_urb(), in order to make it to use the packet
size that would be expected for that kind of ISOC traffic that
userspace indirectly selected, by adjusting the streaming
video resolution selected, right?
Regards,
Mauro
next prev parent reply other threads:[~2013-10-02 16:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <524B1BF4.6000305@gmail.com>
2013-10-01 20:45 ` New USB core API to change interval and max packet size Sarah Sharp
2013-10-01 21:16 ` Xenia Ragiadakou
2013-10-02 18:26 ` Sarah Sharp
2013-10-02 12:33 ` Mauro Carvalho Chehab
2013-10-02 15:00 ` Alan Stern
2013-10-02 16:15 ` Mauro Carvalho Chehab [this message]
2013-10-02 16:38 ` Alan Stern
2013-10-02 17:11 ` Mauro Carvalho Chehab
2013-10-02 14:22 ` Alan Stern
2013-10-02 18:39 ` Sarah Sharp
2013-10-02 19:08 ` Alan Stern
2013-10-02 19:37 ` Alan Stern
2013-10-07 15:25 ` Hans de Goede
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=20131002131550.38f90611@samsung.com \
--to=m.chehab@samsung.com \
--cc=burzalodowa@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
--cc=stern@rowland.harvard.edu \
/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