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. 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
