linux-stable.git/drivers/media/dvb/dvb-core, branch linux-3.3.y

media: dvb_frontend: fix a regression with DVB-S zig-zag

2012-05-21T17:46:18+00:00

commit 910a5f2e9642d5be373beae3d29e1c4a3bc7d83b upstream.

Changeset 5bfaadde broke zig-zag for DVB-S drivers that don't
implement get_tune_settings() callback.

Fix the code, in order to allow it to work as before, otherwise
some channels may not be tuned anymore.

Fix Fedora Bugzilla:
	https://bugzilla.redhat.com/show_bug.cgi?id=814404

Reported-by: Michael Heijenga 
Tested-by: Michael Heijenga 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: dvb_frontend: Fix a regression when switching back to DVB-S

2012-04-27T17:16:37+00:00

commit 3626479e482aa3247aac03724094ba6c13ea1e46 upstream.

There are some softwares (Kaffeine and likely xine) that uses a
DVBv5 call to switch to DVB-S2, but expects that a DVBv3 call to
switch back to DVB-S. Well, this is not right, as a DVBv3 call
doesn't know anything about delivery systems.

However, as, by accident, this used to work, we need to restore its
behavior, in order to avoid regressions with those softwares.

Reported on this Fedora 16 bugzilla:
	https://bugzilla.redhat.com/show_bug.cgi?id=812895

Reported-by: Dieter Roever 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: dvb-core: fix DVBFE_ALGO_HW retune bug

2012-04-13T16:13:57+00:00

commit 45145b67f5895ff92207cffd74e65460a87920b2 upstream.

Commit 7e07222 breaks DVBFE_ALGO_HW tuning after a retune is requested,
which causes bad tuning on my TBS 6920.

[    0.769091] pci 0000:06:00.0: [14f1:8852] type 0 class 0x000400
[   19.733530] CORE cx23885[0]: subsystem: 6920:8888, board: TurboSight TBS 6920 [card=14,autodetected]
[  762.824912] cx24116_load_firmware: FW version 1.23.86.1

7e0722215a510921cbb73ab4c37477d4dcb91bf8 [media] dvb-core: Don't pass DVBv3 parameters on tune() fops

Although re_tune is set to true when FESTATE_RETUNE occurs, it is never
set back to false which the old code used to do when !FESTATE_RETUNE.

This patch sets re_tune to false if !(state & FESTATE_RETUNE).

$ szap-s2 -a 2 "Channel 5"
reading channels from file '/home/simon/.szap/channels.conf'
zapping to 247 'Channel 5':
delivery DVB-S, modulation QPSK
sat 0, frequency 10964 MHz H, symbolrate 22000000, coderate 5/6, rolloff 0.35
vpid 0x092a, apid 0x092b, sid 0x092d
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eb33 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cf40 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr eccd | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal cec0 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

Signed-off-by: Simon Arlott 
Signed-off-by: Mauro Carvalho Chehab

media: dvb_frontend: regression fix: userspace ABI broken for xine

2012-04-13T16:13:57+00:00

commit 556a0442e08a8bc8541587a349cbf26ed14ec6de upstream.

The commit e399ce77e6e has broken the DVB ABI for xine:

The problem is that xine is expecting every event after a successful
FE_SET_FRONTEND ioctl to have a non-zero frequency parameter, regardless
of whether the tuning process has LOCKed yet. What used to happen is
that the events inherited the initial tuning parameters from the
FE_SET_FRONTEND call. However, the fepriv->parameters_out struct is now
not initialised until the status contains the FE_HAS_LOCK bit.

You might argue that this behaviour is intentional, except that if an
application other than xine uses the DVB adapter and manages to set the
parameters_out.frequency field to something other than zero, then xine
no longer has any problems until either the adapter is replugged or the
kernel modules reloaded. This can only mean that the
fepriv->parameters_out struct still contains the (stale) tuning
information from the previous application.

Signed-off-by: Chris Rankin 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2012-01-18T20:53:54+00:00

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (57 commits)
  [media] as3645a: Fix compilation by including slab.h
  [media] s5p-fimc: Remove linux/version.h include from fimc-mdevice.c
  [media] s5p-mfc: Remove linux/version.h include from s5p_mfc.c
  [media] ds3000: using logical && instead of bitwise &
  [media] v4l2-ctrls: make control names consistent
  [media] DVB: dib0700, add support for Nova-TD LEDs
  [media] DVB: dib0700, add corrected Nova-TD frontend_attach
  [media] DVB: dib0700, separate stk7070pd initialization
  [media] DVB: dib0700, move Nova-TD Stick to a separate set
  [media] : add MODULE_FIRMWARE to dib0700
  [media] DVB-CORE: remove superfluous DTV_CMDs
  [media] s5p-jpeg: adapt to recent videobuf2 changes
  [media] s5p-g2d: fixed a bug in controls setting function
  [media] s5p-mfc: Fix volatile controls setup
  [media] drivers/media/video/s5p-mfc/s5p_mfc.c: adjust double test
  [media] drivers/media/video/s5p-fimc/fimc-capture.c: adjust double test
  [media] s5p-fimc: Fix incorrect control ID assignment
  [media] dvb_frontend: Don't call get_frontend() if idle
  [media] DocBook/dvbproperty.xml: Remove DTV_MODULATION from ISDB-T
  [media] DocBook/dvbproperty.xml: Fix ISDB-T delivery system parameters
  ...

[media] DVB-CORE: remove superfluous DTV_CMDs

2012-01-18T00:58:40+00:00

This small patch removes superfluous DTV_CMDs from dvb_frontend.c which were added in the initially when ISBD-T support was added.
They were there unnoticed even though compilers should have warning about those duplicates. Finally they did and now we can remove them.

Thanks to Dan Carpenter  for pointing that out.

Signed-off-by: Patrick Boettcher 
Signed-off-by: Mauro Carvalho Chehab

[media] dvb_frontend: Don't call get_frontend() if idle

2012-01-17T18:20:37+00:00

If the frontend is in idle state, don't call get_frontend.

Calling get_frontend() when the device is not tuned may
result in wrong parameters to be returned to the
userspace.

I was tempted to not call get_frontend() at all, except
inside the dvb frontend thread, but this won't work for
all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
STD-B31) allow the broadcaster to dynamically change the
channel specs at runtime. That means that an ISDB-T optimized
application may want/need to monitor the TMCC tables, decoded
at the frontends via get_frontend call.

So, let's do the simpler change here.

Eventually, the logic could be changed to work only if
the device is tuned and has lock, but, even so, the
lock is also standard-dependent. For ISDB-T, the right
lock to wait is that the demod has TMCC lock. So, drivers
may need to implement some logic to detect if the get_frontend
info was retrieved or not.

Signed-off-by: Mauro Carvalho Chehab

Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2012-01-15T20:49:56+00:00

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (655 commits)
  [media] revert patch: HDIC HD29L2 DMB-TH USB2.0 reference design driver
  mb86a20s: Add a few more register settings at the init seq
  mb86a20s: Group registers into the same line
  [media] [PATCH] don't reset the delivery system on DTV_CLEAR
  [media] [BUG] it913x-fe fix typo error making SNR levels unstable
  [media] cx23885: Query the CX25840 during enum_input for status
  [media] cx25840: Add support for g_input_status
  [media] rc-videomate-m1f.c Rename to match remote controler name
  [media] drivers: media: au0828: Fix dependency for VIDEO_AU0828
  [media] convert drivers/media/* to use module_platform_driver()
  [media] drivers: video: cx231xx: Fix dependency for VIDEO_CX231XX_DVB
  [media] Exynos4 JPEG codec v4l2 driver
  [media] doc: v4l: selection: choose pixels as units for selection rectangles
  [media] v4l: s5p-tv: mixer: fix setup of VP scaling
  [media] v4l: s5p-tv: mixer: add support for selection API
  [media] v4l: emulate old crop API using extended crop/compose API
  [media] doc: v4l: add documentation for selection API
  [media] doc: v4l: add binary images for selection API
  [media] v4l: add support for selection api
  [media] hd29l2: fix review findings
  ...

[media] dvb-core: preserve the delivery system at cache clear

2012-01-15T13:12:22+00:00

The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.

So, the delivery system needs to be explicitly preserved there.

Signed-off-by: Mauro Carvalho Chehab

[media] dvb-core: fix a regression with MythTV

2012-01-15T13:12:21+00:00

As reported by Lawrence[1], MythTV 0.24.1 does the wrong thing
with a DVBv5 call: it fills the delivery system with
SYS_UNDEFINED, expecting that the DVB core would work with that.

This used to work by accident, as the DVB core were missing the
check for the supported delivery systems. Yet, fixing it
is easy, so let's add a logic to handle this case, to
provide backward compatibility.

[1] http://patchwork.linuxtv.org/patch/8314/

Signed-off-by: Mauro Carvalho Chehab