On Wed, May 27, 2009 at 8:54 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > Em Sat, 23 May 2009 03:48:21 +0200 (CEST) > BOUWSMA Barry <freebeer.bouwsma@xxxxxxxxx> escreveu: > >> On Thu, 21 May 2009, Devin Heitmueller wrote: >> >> > em28xx: Don't let device work unless connected to a high speed USB port >> >> (grrr, dyndns addresses that are actually dynamically changing) >> >> | The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs >> | nearly 200 Mbps for analog support, so users would see garbage video, >> | and on >> | the DVB/ATSC side scanning is likely to work but if the user tried to >> | tune it >> | would certainly appear to have failed. >> | It's better to fail explicity up front and tell the user to plug into a >> | USB 2.0 >> >> Hi Devin, >> >> I've spent the last night trying to wrap my brane around the >> DVB code and how it reflects on the ability of hardware to >> perform PID filtering or not, thereby the expected load due >> to interrupts and filtering in the CPU. >> >> If my current machine is being fed a single stream from a >> lower-bandwidth source (not sure where the filtering to a >> crummy audio stream is being performed, but even the full >> bandwidth available from a 1,5MHz-wide chunk of spectrum is >> well within USB1.1), load is negligible. Multicasting the >> filtered data back out over a USB1.1 net adapter bumps up >> the interrupt load somewhat, but `top' idle time remains >> high. > > There are some cases where USB 1.1 is fine, being the most trivial example the > FM radio reception. > > The trouble with em28xx and 1.5 Mbps or 12 Mbps is that, currently, em28xx > doesn't limit its usage to fit into lower bus bandwidth. > > So, it would accept users call to provide non-compressed analog TV, at maximum > resolution and at 30 fps even without having enough bandwidth at USB. It won't > even generate a warning at dmesg. The problem will be noticed only due to the > video garbage. > > So, the right solution to support 12 Mbps (or even 1.5 Mbps) would be to have > some routines there to estimate the maximum bus bandwidth and to deny requests > that would exceed it. Another alternative would be to have a whitelist for > those devices that works fine with usb 1.1 (for example ISDB-T 1 seg and DVB-H > devices without analog). > > I don't think it would be a worthy trial to do such patch (since USB 3.0 is > arriving the market and USB 1.1 is an old standard), but if someone write such > patch, we may later revert this one. > > While we don't have this, it is better to just deny rates lower than 480 Mbps. > > That's said, the reasons given at the patch for nacking USB low speed (on both > the driver and the patch descriptions) are not ok, since the problem is not > that em28xx only works with usb 2.0 or that all DVB streams will fail. > > Instead of: > > + /* Make sure they are connected to a USB 2.0 port. If the device is > + connected to a USB 1.1 port at 12 Mbps, things like dvb scanning > + will work but tuning will fail, and attempts to watch analog will > + show garbage video. Better to just fail explicitly... */ > > So, it should be saying, instead: > > /* > * Make sure we have 480 Mbps of bandwidth, otherwise things like > * video stream wouldn't likely work, since 12 Mbps is generally > * not enough even for most Digital TV streams. > */ > > Devin, > > Could you please change the comment and the patch description and resubmit the > pull request? > > > > Cheers, > Mauro > Hello Mauro, I certainly agree that when we start supporting ISDB-T, we may need to revisit the logic (if we actually care about supporting 12Mbps). I will update the comment and issue a new PULL request, as you proposed. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
