changing XCLK value changes the maximum speed of the
stream.

At the tests, it were possible to produce up to 32 fps, using a 30 MHz
XCLK. However, at that rate, the artifacts happen even at 320x240. Lower
values of XCLK produces artifacts only at 640x480.

At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is
possible to see an invalid sucession of artifacts with this pattern:

.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(where the dots represent the blanked pixels)

So, it seems that a waveform in the format of a ramp is interferring at
the image.

The cause of this interference is currently unknown. Some possibilities
are:
	- electrical interference (maybe this device is broken?);
	- some issue at mt9v011 programming;
	- some bug at em28xx chip.

So, for now, let's be conservative and use a value of XCLK that we know
for sure that it won't cause artifacts.

As I'm waiting for more of such devices with different em28xx chipset
revisions, I'll have the opportunity to double check the issue with
other pieces of hardware.

Later patches can vary XCLK depending on the vertical resolutions, if a
proper fix is not discovered.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
j��v�,x