public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans Petter Selasky <hselasky@c2i.net>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH] Alternate setting 1 must be selected for interface 0 on the model that I received. Else the rest is identical.
Date: Mon, 23 May 2011 21:52:49 +0200	[thread overview]
Message-ID: <201105232152.49155.hselasky@c2i.net> (raw)
In-Reply-To: <4DDAB9ED.1020309@redhat.com>

On Monday 23 May 2011 21:47:57 Mauro Carvalho Chehab wrote:
> Em 23-05-2011 16:17, Hans Petter Selasky escreveu:
> > On Monday 23 May 2011 21:06:32 Mauro Carvalho Chehab wrote:
> >> Em 23-05-2011 15:48, Hans Petter Selasky escreveu:
> >>> On Monday 23 May 2011 20:14:45 Mauro Carvalho Chehab wrote:
> >>>> Em 23-05-2011 11:37, Hans Petter Selasky escreveu:
> >>>> 
> >>>> I don't have any ttusb device here, but I doubt that this would work.
> >>> 
> >>> Hi,
> >>> 
> >>> It is already tested and works fine.
> >> 
> >> This will work for you, but it will likely break for the others. Your
> >> patch is assuming that returning an error if selecting alt 1 is enough
> >> to know that alt 0 should be used.
> >> 
> >>> What I see is that interface 1 does not have an alternate setting like
> >>> the driver code expects, while interface 0 does. So it is the opposite
> >>> of what the driver expects. Maybe the manufacturer changed something.
> >>> Endpoints are still the same.
> >> 
> >> That sometimes happen. Or maybe you just need a different size.
> >> 
> >>> Please find attached an USB descriptor dump from this device.
> >> 
> >> Int 0, endpoint 0:
> >>     Interface 0
> >>     
> >>       bLength = 0x0009
> >>       bDescriptorType = 0x0004
> >>       bInterfaceNumber = 0x0000
> >>       bAlternateSetting = 0x0000
> >>       bNumEndpoints = 0x0003
> >>       bInterfaceClass = 0x0000
> >>       bInterfaceSubClass = 0x0000
> >>       bInterfaceProtocol = 0x0000
> >>       iInterface = 0x0000  <no string>
> >> 
> >> ...
> >> 
> >>      Endpoint 2
> >>      
> >>         bLength = 0x0007
> >>         bDescriptorType = 0x0005
> >>         bEndpointAddress = 0x0082  <IN>
> >>         bmAttributes = 0x0001  <ISOCHRONOUS>
> >>         wMaxPacketSize = 0x0000
> >>         bInterval = 0x0001
> >>         bRefresh = 0x0000
> >>         bSynchAddress = 0x0000
> >> 
> >> ...
> >> 
> >>     Interface 0 Alt 1
> >>     
> >>       bLength = 0x0009
> >>       bDescriptorType = 0x0004
> >>       bInterfaceNumber = 0x0000
> >>       bAlternateSetting = 0x0001
> >>       bNumEndpoints = 0x0003
> >>       bInterfaceClass = 0x0000
> >>       bInterfaceSubClass = 0x0000
> >>       bInterfaceProtocol = 0x0000
> >>       iInterface = 0x0000  <no string>
> >> 
> >> ...
> >> 
> >>      Endpoint 2
> >>      
> >>         bLength = 0x0007
> >>         bDescriptorType = 0x0005
> >>         bEndpointAddress = 0x0082  <IN>
> >>         bmAttributes = 0x0001  <ISOCHRONOUS>
> >>         wMaxPacketSize = 0x0390
> >>         bInterval = 0x0001
> >>         bRefresh = 0x0000
> >>         bSynchAddress = 0x0000
> > 
> > Hi,
> > 
> >> Hmm... assuming that the driver is using ISOC transfers, the difference
> >> between alt 0 and alt 1 is that, on alt0, the mwMaxPacketSize is 0 (so,
> >> you can't use it for isoc transfers), while, on alt 1, wMaxPacketSize is
> >> 0x390.
> >> 
> >> What the driver should be doing is to select an alt mode where the
> >> wMaxPacketSize is big enough to handle the transfer.
> > 
> > I can write the code to do that. Summed up:
> > 
> > 1) Search interface 0, for alternate settings that have an ISOC-IN and
> > wMaxPacket != 0. Select this alternate setting.
> > 
> > 2) Search interface 1, for alternate settings that have an ISOC-IN and
> > wMaxPacket != 0. Select this alternate setting.
> > 
> > 3) Done.
> > 
> > Do you think this will work better?
> > 
> >> Calculating what "big enough"   is device-dependent, but, basically, a
> >> 480 Mbps USB bus is capable of providing 800 isoc slots per interval.
> >> If the packets are bigger, the max bandwidth is bigger.
> > 
> > This is a FULL speed device, max 10MBit/second.
> 
> Hmm... USB 1.1 devices are even more limited on the amount of used
> bandwidth. The above procedure is better than the one you've proposed, but
> yet you may not be able to receive channels with higher bandwidths.
> 
> The usb "max" limit is lower than the maximum bandwidth. I think that full
> speed provides 900 isoc slots per interval, but the interval for usb 1.1 is
> higher (1s, while the interval for usb 2.0 is 125 us), but you need to
> double check such constraints at the USB 1.1 and 2.0 specs, as I may be
> wrong on that, as I read it a long time ago ;)

Hi,

There are 1000 frames per second when using Full Speed USB. I know the device 
cannot receive all streams, but it is very well suited for DVB radio.

--HPS

  reply	other threads:[~2011-05-23 19:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-23 14:37 [PATCH] Alternate setting 1 must be selected for interface 0 on the model that I received. Else the rest is identical Hans Petter Selasky
2011-05-23 18:14 ` Mauro Carvalho Chehab
2011-05-23 18:48   ` Hans Petter Selasky
2011-05-23 19:06     ` Mauro Carvalho Chehab
2011-05-23 19:17       ` Hans Petter Selasky
2011-05-23 19:47         ` Mauro Carvalho Chehab
2011-05-23 19:52           ` Hans Petter Selasky [this message]
2011-05-23 20:04             ` Mauro Carvalho Chehab
2011-05-23 20:07               ` Hans Petter Selasky

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=201105232152.49155.hselasky@c2i.net \
    --to=hselasky@c2i.net \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    /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