| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The problem boils down to the order when the bit11
of the texture size is or'ed to the original width.
In the end each mipmap level has the same width or
height because of that 11 bit is ored to the scaled
down lod with and thus blows up the size again to the
full size or more due to the power of two rounding
afterwards.
The attached patch changes this order so that the
texture sizes are computed correct. Also the on error
the yet missing inputs to the size computation are
printed which helped me to find out where it really breaks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Original radeon didn't have a connector table in the
bios. Check for the CRT table and if we have one,
add a VGA connector.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Need to check the return type for the quirk function
to decide whether we add the connectors and encoders.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Sometimes we will get the incorrect display modeline when parsing the detailed
timing in EDID. For example:
>hsync/vsync width is zero
>sync is beyond the blank.
So add the basic check for the detailed timing in EDID to avoid the incorrect
display modeline.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
fixes fdo bug 24496
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
D1MODE_INTERLEAVE_EN was getting set in some cases
in the encoder quirks function due to the changes in
5a9bcacc0a56f0d9577494e834519480018a6cc3
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Based partly on a patch from
Christian Koenig <deathsimple@vodafone.de>
- fix several memory leaks in radeon_connector->edid handling
- store edid in radeon_connector->edid in detect() or get_modes()
- switch hdmi detect code to use radeon_connector->edid
- add support for oem boards multiple connectors that share
a ddc line.
- short circuit lvds_detect() if have a stored edid
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- crtc 0 routing was wrong
- need to clear various timing bits in FP_GEN_CNTL
- need to set FP_H/V2_SYNC_STRT_WID regs for crtc 1
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
radeon_encoder->active_device defines the active routing
between the encoder and connector. The encoder fixup and
dpms functions need to know the active_device to function
properly. Setting active_device in the prepare hook was
too late in some cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
drm modes are objects with indentifiers. Make sure to preserve
the mode id when copying mode params.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With the adjust table introduction, we need to fill out index
before getting the table version.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit 49c458e544ae14514209ed80ea6829ca1b18ddf0. It
seems to have some side effects in the non-kms cases.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In case the system has bad native mode info but
valid edid.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reduces the number of mode format conversions needed
and makes native panel mode support cleaner.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- clean up tv timing handling
- unify SetCRTC_Timing and SetCRTC_UsingDTDTiming
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
DCE3+ has an AdjustDisplayPll that will adjust the pixel
clock accordingly based on the encoder/transmitter to
handle special hw requirements.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Based on recommendation from bios docs.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If the panel data is bogus this can lead to problems
later when the hardware trys to set the mode. If the
data is invalid, report LVDS as disconnected.
Should fix fdo bug 24247.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
While investigating the cause of CRTC FIFO underruns, I noticed that when
converting the memory bandwidth calculation from the userspace X driver code,
an instance of '8.0' was apparently accidentally converted to '80'.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The hook may change the number of bytes per pixel being scanned out, which
affects the CRTC memory bandwidth requirements. E.g. booting in 8bpp and then
running X in 32bpp would result in the bandwidth requirements being
underestimated for the latter and consequently in CRTC FIFO underruns causing
visible artifacts with 3D intensive workloads.
ATOM changes only compile-tested.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The fb binding might be happening in a subsequent crtc setup call.
gets rid of some lut issues.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
[WATCHDOG] SBC-FITPC2 watchdog driver registration fix
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This patch fixes device registration process.
Signed-off-by: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (27 commits)
V4L/DVB (13314): saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150
V4L/DVB (13313): saa7134: add support for FORCE_TS_VALID mode for mpeg ts input
V4L/DVB (13311): uvcvideo: Fix compilation warning with 2.6.32 due to type mismatch with abs()
V4L/DVB (13309): uvcvideo: Ignore the FIX_BANDWIDTH for compressed video
V4L/DVB (13287): ce6230 - saa7164-cmd: Fix wrong sizeof
V4L/DVB (13286): pxa-camera: Fix missing sched.h
V4L/DVB (13264): gspca_mr97310a: Change vstart for CIF sensor type 1 cams
V4L/DVB (13257): gspca - m5602-s5k4aa: Add vflip for Fujitsu Amilo Xi 2528
V4L/DVB (13256): gspca - m5602-s5k4aa: Add another MSI GX700 vflip quirk
V4L/DVB (13255): gspca - m5602-s5k4aa: Add vflip quirk for the Bruneinit laptop
V4L/DVB (13240): firedtv: fix regression: tuning fails due to bogus error return
V4L/DVB (13237): firedtv: length field corrupt in ca2host if length>127
V4L/DVB (13230): s2255drv: Don't conditionalize video buffer completion on waiting processes
V4L/DVB (13202): smsusb: add autodetection support for three additional Hauppauge USB IDs
V4L/DVB (13190): em28xx: fix panic that can occur when starting audio streaming
V4L/DVB (13170): bttv: Fix reversed polarity error when switching video standard
V4L/DVB (13169): bttv: Fix potential out-of-order field processing
V4L/DVB (13167): pt1: Fix a compile error on arm
V4L/DVB (13132): fix use-after-free Oops, resulting from a driver-core API change
V4L/DVB (13131): pxa_camera: fix camera pixel format configuration
...
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The Hauppauge WinTV HVR-1150 retail boards require the FORCE_TS_VALID bit
to be set in order to function properly. This change will work on the early
revisions on the board as well, but the final revision will not function
without this change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When FORCE_TS_VALID mode is enabled, the saa713x will accept MPEG TS input
without requiring TS_VALID set high. This is required for some new boards
to function properly, due to the hardware design implementation.
The configuration is toggled within the board setup configuration. Boards
that do not have this bit set will function as before with no change.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
mismatch with abs()
The abs() macro has changed in 2.6.32 and returns a long instead of an
int. Fix the driver to avoid compilation warnings.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The FIX_BANDWIDTH quirk tries to work around cameras requesting the
maximum bandwidth regardless of the image size by computing a bandwidth
estimate. This works only for uncompressed frames.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Cc: Antti Palosaari <crope@iki.fi>
Acked-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Required for wakeup call.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
gspca_mr97310a: Change vstart for CIF sensor type 1 cams
This fixes the distortion at the end of the frame, and avoids the bad frame
dropping done because of this distortion, trippling the framerate!
Signed-off-by: Theodore Kilgore <kilgota@banach.math.auburn.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Adds a vflip quirk for the Fujitsu Amilo Xi 2528. Thanks to Evgeny for the report.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Adds another vflip quirk for the MSI GX700.
Thanks to John Katzmaier for reporting.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Adds a vflip quirk for the Bruneinit laptop. Thanks to Jörg for the report
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Since 2.6.32(-rc1), DVB core checks the return value of
dvb_frontend_ops.set_frontend. Now it becomes apparent that firedtv
always returned a bogus value from its set_frontend method.
CC: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This solves a problem in firedtv that has become major for Swedish DVB-T
users the last month or so. It will most likely solve issues seen by
other users as well.
If the length of an AVC message is greater than 127, the length field
should be encoded in LV mode instead of V mode. V mode can only be used
if the length is 127 or less. This patch ensures that the CA_PMT
message is always encoded in LV mode so PMT message of greater lengths
can be supported.
Signed-off-by: Henrik Kurelid <henrik@kurelid.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
waiting processes
The s2255 driver had logic which aborted processing of a video frame
if there was no process waiting on the video buffer in question. That
simply doesn't work when the application is doing things in an
asynchronous manner. If the application went to the trouble to queue
the buffer in the first place, then the driver should always attempt
to complete it - even if the application at that moment has its
attention turned elsewhere. Applications which always blocked waiting
for I/O on the capture device would not have been affected by this.
Applications which *mostly* blocked waiting for I/O on the capture
device probably only would have been somewhat affected (frame lossage,
at a rate which goes up as the application blocks less). Applications
which never blocked on the capture device (e.g. polling only) however
would never have been able to receive any video frames, since in that
case this "is anyone waiting on this?" check on the buffer never would
have evalutated true. This patch just deletes that harmful check
against the buffer's wait queue.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CC: stable@kernel.org
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Hauppauge USB IDs
Add support for three new Hauppauge Device USB IDs:
2040:b900
2040:b910
2040:c000
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Because the counters were not reset when starting up streaming, they would
be reused from the previous run. This can result in cases such that when the
second instance of streaming starts up, the "cnt" variable in
em28xx_audio_isocirq() can end up being negative, resulting in attempting to
write to memory before the start of runtime->dma_area (as well as having a
negative number of bytes to copy).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The bttv driver function which handles switching of the video standard
(set_tvnorm() in bttv-driver.c) includes a check which can optionally
also reset the cropping configuration to a default value. It is
"optional" based on a comparison of the cropcap parameters of the
previous vs the newly requested video standard. The comparison is
being done with a memcmp(), a function which only returns a true value
if the comparison actually fails.
This if-statement appears to have been written to assume wrong
memcmp() semantics. That is, it was re-initializing the cropping
configuration only if the new video standard did NOT have different
cropcap values. That doesn't make any sense. One definitely should
reset things if the cropcap parameters are different - if there's any
comparison to made at all.
The effect of this problem was that a transition from, say, PAL to
NTSC would leave in place old cropping setup that made sense for the
PAL geometry but not for NTSC. If the application doesn't care about
cropping it also won't try to reset the cropping configuration,
resulting in an improperly cropped video frame. In the case I was
testing this actually caused black video frames to be displayed.
Another interesting effect of this bug is that if one does something
which does NOT change the video standard and this function is run,
then the cropping setup gets reset anyway - again because of the
backwards comparison. It turns out that just running anything which
merely opens and closes the video device node (e.g. v4l-info) will
cause this to happen. One can argue that simply opening the device
node and not doing anything to it should not mess with any of its
state - but because of this behavior, any TV app which does such
things (e.g. xawtv) probably therefore doesn't see the problem.
The solution is to fix the sense of the if-statement. It's easy to
see how this mistake could have been made given how memcmp() works.
The patch is therefore removal of a single "!" character from the
if-statement in set_tvnorm in bttv-driver.c.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
There is a subtle interaction in the bttv driver which can result in
fields being repeatedly processed out of order. This is a problem
specifically when running in V4L2_FIELD_ALTERNATE mode (probably the
most common case).
1. The determination of which fields are associated with which buffers
happens in videobuf, before the bttv driver gets a chance to queue the
corresponding DMA. Thus by the point when the DMA is queued for a
given buffer, the algorithm has to do the queuing based on the
buffer's already assigned field type - not based on which field is
"next" in the video stream.
2. The driver normally tries to queue both the top and bottom fields
at the same time (see bttv_irq_next_video()). It tries to sort out
top vs bottom by looking at the field type for the next 2 available
buffers and assigning them appropriately.
3. However the bttv driver *always* actually processes the top field
first. There's even an interrupt set aside for specifically
recognizing when the top field has been processed so that it can be
marked done even while the bottom field is still being DMAed.
Given all of the above, if one gets into a situation where
bttv_irq_next_video() gets entered when the first available buffer has
been pre-associated as a bottom field, then the function is going to
process the buffers out of order. That first available buffer will be
put into the bottom field slot and the buffer after that will be put
into the top field slot. Problem is, since the top field is always
processed first by the driver, then that second buffer (the one after
the first available buffer) will be the first one to be finished.
Because of the strict fifo handling of all video buffers, then that
top field won't be seen by the app until after the bottom field is
also processed. Worse still, the app will get back the
chronologically later bottom field first, *before* the top field is
received. The buffer's timestamps will even be backwards.
While not fatal to most TV apps, this behavior can subtlely degrade
userspace deinterlacing (probably will cause jitter). That's probably
why it has gone unnoticed. But it will also cause serious problems if
the app in question discards all but the latest received buffer (a
latency minimizing tactic) - causing one field to only ever be
displayed since the other is now always late. Unfortunately once you
get into this state, you're stuck this way - because having consumed
two buffers, now the next time around the "first" available buffer
will again be a bottom field and the same thing happens.
How can we get into this state? In a perfect world, where there's
always a few free buffers queued to the driver, it should be
impossible. However if something disrupts streaming, e.g. if the
userspace app can't queue free buffers fast enough for a moment due
perhaps to a CPU scheduling glitch, then the driver can get
momentarily starved and some number of fields will be dropped. That's
OK. But if an odd number of fields get dropped, then that "first"
available buffer might be the bottom field and now we're stuck...
This patch fixes that problem by deliberately only setting up a single
field for one frame if we don't get a top field as the first available
buffer. By purposely skipping the other field, then we only handle a
single buffer thus bringing things back into proper sync (i.e. top
field first) for the next frame. To do this we just drop the few
lines in bttv_irq_next_video() that attempt to set up the second
buffer when that second buffer isn't for the bottom field.
This is definitely a problem in when in V4L2_FIELD_ALTERNATE mode. In
the other modes this change either has no effect or doesn't harm
things any further anyway.
Signed-off-by: Mike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The lack of #include <linux/vmalloc.h> caused a compile error on some
architectures.
Signed-off-by: HIRANO Takahito <hiranotaka@zng.info>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
change
Commit b4028437876866aba4747a655ede00f892089e14 has broken again re-use of
device objects across device_register() / device_unregister() cycles. Fix
soc-camera by nullifying the struct after device_unregister().
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
A missed conversion prevents correct pixel format negotiation with client
drivers.
Reported-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Fix a bug in cropping calculation, when the client is also scaling the image.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
When we call gspca_frame_add, it returns a pointer to the frame passed in,
unless we call it with LAST_PACKET, when it will return a pointer to a
new frame in which to store the frame data for the next frame.
The frame pointer was not updated in stv06xx and ov518.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
tda18271_rf_tracking_filters_init
While having tda18271 module set with debug=17 (cal & info prints) and
cal=0 (delay calibration process until first use) - I discovered that
during the calibration process, if the frequency test for 69750000
returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that
the tuner wouldn't be able to pickup any of the frequencies in the range
(all the other frequencies bands returned bcal=1). I spent some time
going over the code and the NXP's tda18271 spec (ver.4 of it i think) and
adding a lot of debug prints and walking/stepping through the calibration
process. I found that when the powerscan fails to find a frequency, the
rf calibration is not run and the default value is supposed to be used in
its place (pulled from the RF_CAL_map table) - but something was getting
goofed up there.
Now, my c coding skills are very rusty, but i think root of the problem is
a signedness issue with the math operation for calculating the rf_a1 and
rf_a2 values in tda18271_rf_tracking_filters_init func, which results in
values like 20648 for rf_a1 (when it should probably have a value like 0,
or so slightly negative that it should be zero - this bad value for rf_a1
would in turn makes the approx calc within
tda18271c2_rf_tracking_filters_correction go out of whack). The simplest
solution i found was to explicitly convert the signedness of the
denominator to avoid the implicit conversion. The values placed into the
u32 rf_freq array should never exceed about 900mhz, so i think the s32 max
value shouldn't be an issue in this case.
I've tested it out a little, and even when i get a bcal=0 with the
modified code, the default calibration value gets used, rf_a1 is zero, and
the tuner seems to lock on the stream and mythtv seems to play it fine.
Signed-off-by: Seth Barry <seth@cyberseth.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
