Hello
> On Tue, Apr 10, 2012 at 08:29:54AM -0300, Mauro Carvalho Chehab wrote:
> > Em 10-04-2012 04:47, Dmitri Belimov escreveu:
> > > Hello
> > >
> > > Are you test work tm6000 devices with USB 3.0 controllers??
> > >
> > > Some our customers reported about problem.
>
> Have you tried running with the latest bleeding-edge kernel, 3.4-rc2?
> That kernel includes dynamic ring expansion, which should fix any
> problems you have with error messages like "No room on endpoint ring".
> I'd like to figure out if that solves you issue before we blame it on
> bandwidth claiming.
I use for get new kernel
git clone git://github.com/torvalds/linux.git v4l-dvb
cd v4l-dvb
git remote add linuxtv git://linuxtv.org/media_tree.git
git remote update
git checkout -b media-master remotes/linuxtv/staging/for_v3.5
dmesg
[ 9145.418290] Linux video capture interface: v2.00
[ 9145.451820] usb 3-1: ep 0x82 - rounding interval to 32768 microframes,
ep desc says 0 microframes
[ 9145.453686] tm6000: alt 0, interface 0, class 255
[ 9145.453691] tm6000: alt 0, interface 0, class 255
[ 9145.453694] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes)
[ 9145.453697] tm6000: alt 0, interface 0, class 255
[ 9145.453699] tm6000: alt 1, interface 0, class 255
[ 9145.453702] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes)
[ 9145.453705] tm6000: alt 1, interface 0, class 255
[ 9145.453707] tm6000: alt 1, interface 0, class 255
[ 9145.453710] tm6000: INT IN endpoint: 0x83 (max size=4 bytes)
[ 9145.453712] tm6000: alt 2, interface 0, class 255
[ 9145.453714] tm6000: alt 2, interface 0, class 255
[ 9145.453717] tm6000: alt 2, interface 0, class 255
[ 9145.453719] tm6000: alt 3, interface 0, class 255
[ 9145.453722] tm6000: alt 3, interface 0, class 255
[ 9145.453724] tm6000: alt 3, interface 0, class 255
[ 9145.453727] tm6000: New video device @ 480 Mbps (6000:dec3, ifnum 0)
[ 9145.453730] tm6000: Found Beholder Voyager Lite TV/FM USB2.0
[ 9145.460517] Found tm6010
[ 9146.080614] tm6000 #0: i2c eeprom 00: 42 59 54 45 12 01 00 02 00 00 00
40 00 60 c3 de BYTE.......@.`..
[ 9146.198613] tm6000 #0: i2c eeprom 10: 01 00 10 20 40 01 28 03 42 00 65
00 68 00 6f 00 ... @.(.B.e.h.o.
[ 9146.316710] tm6000 #0: i2c eeprom 20: 6c 00 64 00 65 00 72 00 20 00 49
00 6e 00 74 00 l.d.e.r. .I.n.t.
[ 9146.434810] tm6000 #0: i2c eeprom 30: 6c 00 2e 00 20 00 4c 00 74 00 64
00 2e 00 ff ff l... .L.t.d.....
[ 9146.552892] tm6000 #0: i2c eeprom 40: 2a 03 42 00 65 00 68 00 6f 00 6c
00 64 00 54 00 *.B.e.h.o.l.d.T.
[ 9146.670882] tm6000 #0: i2c eeprom 50: 56 00 20 00 56 00 6f 00 79 00 61
00 67 00 65 00 V. .V.o.y.a.g.e.
[ 9146.788983] tm6000 #0: i2c eeprom 60: 20 00 4c 00 69 00 74 00 65 00 1a
03 56 00 69 00 .L.i.t.e...V.i.
[ 9146.907076] tm6000 #0: i2c eeprom 70: 64 00 65 00 6f 00 43 00 61 00 70
00 74 00 75 00 d.e.o.C.a.p.t.u.
[ 9147.025175] tm6000 #0: i2c eeprom 80: 72 00 65 00 ff ff ff ff ff ff ff
ff ff ff ff ff r.e.............
[ 9147.143148] tm6000 #0: i2c eeprom 90: ff ff ff ff 16 03 30 00 30 00 30
00 30 00 30 00 ......0.0.0.0.0.
[ 9147.261247] tm6000 #0: i2c eeprom a0: 30 00 39 00 46 00 38 00 36 00 ff
ff ff ff ff ff 0.9.F.8.6.......
[ 9147.379343] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ................
[ 9147.497441] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ................
[ 9147.615544] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ................
[ 9147.733514] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ................
[ 9147.851612] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ................
[ 9148.021749] i2c-core: driver [tuner] using legacy suspend method
[ 9148.021751] i2c-core: driver [tuner] using legacy resume method
[ 9148.021941] tuner 1-0061: Tuner -1 found with type(s) Radio TV.
[ 9148.021948] xc5000 1-0061: creating new instance
[ 9148.047421] xc5000: Successfully identified at address 0x61
[ 9148.047424] xc5000: Firmware has not been loaded previously
[ 9148.101684] xc5000: waiting for firmware upload
(dvb-fe-xc5000-1.6.114.fw)...
[ 9148.112659] xc5000: firmware read 12401 bytes.
[ 9148.112661] xc5000: firmware uploading...
[ 9151.137162] xc5000: firmware upload complete...
[ 9152.758812] tm6000 #0: registered device video0
[ 9152.758838] tm6000 #0: registered device radio0
[ 9152.758840] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load
status: 0)
[ 9152.758870] usb 3-2: ep 0x82 - rounding interval to 32768 microframes,
ep desc says 0 microframes
[ 9152.759082] usb 3-2: Not enough bandwidth for new device state.
[ 9152.759087] usb 3-2: Not enough bandwidth for altsetting 1
[ 9152.759088] tm6000: Error -28 while registering
[ 9152.759112] tm6000: probe of 3-2:1.0 failed with error -28
[ 9152.759128] usbcore: registered new interface driver tm6000
[ 9152.820740] tm6000 #0: Initialized (TM6000 Audio Extension) extension
[ 9153.809026] usb 3-1: ep 0x82 - rounding interval to 32768 microframes,
ep desc says 0 microframes
[ 9154.417316] usb 3-1: ep 0x82 - rounding interval to 32768 microframes,
ep desc says 0 microframes
[ 9154.418865] usb 3-1: ep 0x82 - rounding interval to 32768 microframes,
ep desc says 0 microframes
Init second TV card is FAIL.
With my best regards, Dmitry.
> Sarah Sharp
>
> > Hi Dmitri,
> >
> > I don't have any system here with an USB 3.0 controller. I suspect,
> > however, that this may not work, due to the way the USB 3.0 core
> > reserves bandwidth for ISOC transfers. We had some discussions with
> > Sarah (the maintainer of the USB 3.0 stack) in the past (in
> > particular at the USB mini-summit), but I'm not sure if any changes
> > were applied at the USB 3.0 driver.
> >
> > This is the summary for the bandwidth discussions we had there:
> >
> > > Bandwidth discussions
> > > ---------------------
> > >
> > > I talked a bit with Hans and Mauro about what sorts of things
> > > media drivers might need if the USB core were to provide an
> > > interface to allow drivers to declare they use less bandwidth
> > > than the device advertises.
> > >
> > > I described one of the logitech cameras I have where the uvcvideo
> > > driver always attempts to use the most bandwidth-intensive
> > > interface (alt setting 11), and Hans suggested that the device
> > > might be falsely advertising that it needs alt setting 11 for all
> > > the video resolutions it provides. He suggested I look at the
> > > FIX_BANDWIDTH quirk in the uvcvideo driver.
> > >
> > > Alan already pointed out that for devices with non-zero
> > > "additional service opportunities per microframe", we can't
> > > reduce the packet size. I tried to explore whether devices that
> > > didn't fall into that categories could have their packet size
> > > reduced, or if the driver could use less extra service
> > > opportunities for those alt settings that do advertise it.
> > >
> > > Hans said that cameras will often want to send full packets in a
> > > burst, using all service opportunities, and then send a bunch of
> > > zero packets between frames. He said many of them will "barf" if
> > > the driver tries to use a smaller buffer size or less service
> > > opportunities to make the camera send a steady stream of bytes.
> > > It was unclear whether all the cameras suffer from this, so more
> > > experimentation on my part is probably needed.
> > >
> > > As for devices that have the wrong endpoint interval advertised
> > > (e.g. HS cameras specifying the interval in frames instead of
> > > microframes), Hans said that only a few devices have the wrong
> > > endpoint interval advertised.
> >
> > > With my best regards, Dmitry.
> >
> > Sarah,
> >
> > In the specific case of tm5600/6000/6010 chipsets, we found several
> > bugs on those chipsets, especially at the I2C part of it. I won't
> > doubt if it would have some bug at the USB part as well.
> >
> > Anyway, despite what it requests, the driver can estimate the
> > required bandwidth for it, as, for analog mode. A rough estimation
> > would would be to do something like: video_res = 2 bytes per pixel
> > * horizontal resolution * vertical resolution video_payload_header
> > = (video_res / 180) * 4 video_payload_bandwidth = frames_per_second
> > * (video_res + video_payload_header) audio_res = 48000 * 2 channels
> > * 2 bytes audio_payload_header = (audio_res / 180) * 4
> > audio_payload_bandwidth = 8 * (audio_res +
> > audio_payload_header)
> >
> >
> > If I didn't made any wrong calculus, the worse case is a net
> > bandwidth of 171 Mbps for the payload (due to USB headers, this is,
> > actually, about 240 Mbps).
> >
> > For digital mode, it is even lower than that. I couldn't find the
> > max bw on the TM6xxx datasheets, but, this is limited by the
> > digital standard, so, it is lower than 22 Mbps for terrestrial
> > transmissions like DVB-T and ISDB-T, as documented at the video
> > standard specifications. For DVB-C it is typically not bigger than
> > 44 Mbps. In any case, for digital TV, the driver can calculate it,
> > as it is a function of the spectrum bandwidth for the TV channel
> > and the video standard modulation.
> >
> > In any case, the USB core has no glue about the audio/video
> > resolutions or about the upper bandwidth limit found on a digital
> > TV standard. So, it is very likely that it is over-estimating the
> > maximum bandwidth causing troubles for the drivers.
> >
> > The right fix, IMHO, seems to have some way for the driver to
> > calculate the amount of needed bandwidth, overriding whatever
> > calculus is done by the USB core.
> >
> > Regards,
> > Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
