Skip to content

L
linux-davinci
Switch branch/tag
  1. 07 Nov, 2009 11 commits
    • Mike Isely's avatar
      V4L/DVB (13169): bttv: Fix potential out-of-order field processing · 66349b4e
      Mike Isely authored 
      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: default avatarMike Isely <isely@pobox.com>
CC: stable@kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      66349b4e
    • HIRANO Takahito's avatar
      V4L/DVB (13167): pt1: Fix a compile error on arm · e0a7e8a6
      HIRANO Takahito authored 
      The lack of #include <linux/vmalloc.h> caused a compile error on some
architectures.
Signed-off-by: default avatarHIRANO Takahito <hiranotaka@zng.info>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      e0a7e8a6
    • Guennadi Liakhovetski's avatar
      V4L/DVB (13132): fix use-after-free Oops, resulting from a driver-core API change · 76823b79
      Guennadi Liakhovetski authored 
      Commit b4028437 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: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      76823b79
    • Guennadi Liakhovetski's avatar
      V4L/DVB (13131): pxa_camera: fix camera pixel format configuration · 07bc46e6
      Guennadi Liakhovetski authored 
      A missed conversion prevents correct pixel format negotiation with client
drivers.
Reported-by: default avatarAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      07bc46e6
    • Guennadi Liakhovetski's avatar
      V4L/DVB (13129): sh_mobile_ceu_camera: fix cropping for scaling clients · 8cf1fec8
      Guennadi Liakhovetski authored 
      Fix a bug in cropping calculation, when the client is also scaling the image.
Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      8cf1fec8
    • Hans de Goede's avatar
      V4L/DVB (13122): gscpa - stv06xx + ov518: dont discard every other frame · 1381dfd5
      Hans de Goede authored 
      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: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarJean-Francois Moine <moinejf@free.fr>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      1381dfd5
    • Seth Barry's avatar
      V4L/DVB (13109): tda18271: fix signedness issue in tda18271_rf_tracking_filters_init · a57c1dcb
      Seth Barry authored 
      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: default avatarSeth Barry <seth@cyberseth.com>
Signed-off-by: default avatarMichael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      a57c1dcb
    • Michael Krufky's avatar
      V4L/DVB (13107): tda18271: fix overflow in FM radio frequency calculation · 4d831787
      Michael Krufky authored 
      Multiplication by 62500 causes an overflow in the 32 bit freq variable,
which is later divided by 1000 when using FM radio.

This patch prevents the overflow by scaling the frequency value correctly
upfront.  Thanks to Henk Vergonet for spotting the problem and providing
a preliminary patch, which this changeset was based upon.

Cc: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: default avatarMichael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      4d831787
    • Martin Samek's avatar
      V4L/DVB (13079): dib0700: fixed xc2028 firmware loading kernel oops · 7646b9de
      Martin Samek authored 
      Fixing kernel oops when driver attemps to load xc2028 firmware.

Note by djh: the patch contribute by Martin is a port of a fix I made during
the PCTV 340e development.  It's a temporary workaround that fixes a regression
(an OOPS condition) and the real fix should be in the code that manages the
i2c master on the dib7000p.  But this fix does address the immmediate
regression and should be merged upstream until we do a cleaner fix.
Signed-off-by: default avatarMartin Samek <martin@marsark.sytes.net>
Signed-off-by: default avatarDevin Heitmueller <dheitmueller@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      7646b9de
    • Patrick Boettcher's avatar
      V4L/DVB (13050): DIB0700: fix-up USB device ID for Terratec/Leadtek · 1e13c8f0
      Patrick Boettcher authored 
      git commit db48138f changed by accident the
assignment of certain USB IDs to their device-specific-handlers.

Thanks to Edward Sheldrake for finding this regression
Signed-off-by: default avatarPatrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      1e13c8f0
    • Michael Krufky's avatar
      V4L/DVB (13048): dib0070: fix build dependency when driver is disabled · 2b5d9946
      Michael Krufky authored 
      Fix build dependency on function, dib0070_ctrl_agc_filter

[mchehab@redhat.com: reverted the quick workaround 3f48258e]
Signed-off-by: default avatarMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: default avatarPatrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      2b5d9946
  3. 05 Nov, 2009 17 commits
  5. 04 Nov, 2009 12 commits