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