From: Mauro Carvalho Chehab <m.chehab@samsung.com>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>,
linux-usb@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>,
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 09:33:54 -0300 [thread overview]
Message-ID: <20131002093354.507cd24d@samsung.com> (raw)
In-Reply-To: <20131001204554.GB15395@xanatos>
Hi Sarah,
Em Tue, 1 Oct 2013 13:45:54 -0700
Sarah Sharp <sarah.a.sharp@linux.intel.com> escreveu:
> On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
> > Hi Sarah,
> >
> > I read the mail on 'possible conflict between xhci_hcd and a patched
> > usbhid'.
>
> For reference to others:
> http://marc.info/?l=linux-usb&m=138064948726038&w=2
> http://marc.info/?l=linux-usb&m=138065201426880&w=2
>
> > I looked in xhci and the problem arises in xhci_queue_intr_tx() when
> > if (xhci_interval != ep_interval) {
> > ...
> > urb->interval = xhci_interval;
> > }
> >
> > right?
>
> Yes. The underlying problem is that the xHCI host sets up the endpoint
> contexts during the Configure Endpoint command, using the interval from
> the device's endpoint descriptors. It also uses the endpoint descriptor
> wMaxPacketSize, which can be wrong as well. If the device driver wants
> to use a different urb->interval than is in the endpoint descriptor, the
> xHCI driver will simply ignore it.
>
> (I'm Ccing the linux-media list, as I've discussed some of these devices
> with broken descriptors before.)
>
> > When you say a new API, what do you mean? New functions in usbcore
> > to be used by usb device drivers?
>
> Yes. You would export the function in the USB core, and put a prototype
> in a USB include file (probably in include/linux/usb.h). Let's say that
> function is called usb_change_ep_bandwidth.
>
> Drivers could call into that function when they needed to change either
> the bInterval or wMaxPacketSize of a particular endpoint. This could be
> during the driver's probe function, or before switching alternate
> interface settings, or even after the alt setting is in place, but
> userspace dictates the driver use a different bandwidth.
>
> Drivers should pass usb_change_ep_bandwidth a pointer to the endpoint
> they need to change, along with the bInterval and wMaxPacketSize values
> they would like the endpoint to have. Those values could be stored as
> new values in struct usb_host_endpoint.
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:
Bus 003 Device 002: ID 2040:6600 Hauppauge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2040 Hauppauge
idProduct 0x6600
bcdDevice 0.69
iManufacturer 16
iProduct 32 HVR900H
iSerial 64 4031932745
...
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:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.11
iManufacturer 3 Linux 3.11.2-201.fc19.x86_64 xhci_hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:14.0
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().
If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
or wMaxPacketSize were improperly filled.
Right?
--
Cheers,
Mauro
next prev parent reply other threads:[~2013-10-02 12:34 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 [this message]
2013-10-02 15:00 ` Alan Stern
2013-10-02 16:15 ` Mauro Carvalho Chehab
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=20131002093354.507cd24d@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