Format it as a table and links it with the legacy API xml.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Format it as a table and add more details, in special for
DTMB guard intervals.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Format it as a table and add more details. Also, remove the
duplicated occurrences.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

fe_bandwidth/fe_bandwidth_t is used only on DVBv3 API. So, move
it to the frontend legacy xml, and convert it into a table.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Format it as a table and add more details, in special, for
the DTMB modes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Format it as a table and provide more details.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Instead of using programlisting, use a table, as this provides
a better view of the structure.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Use the proper format for FE_DISEQC_SEND_BURST documentation
and  improve the documentation.

Keep the enum fe_sec_mini_cmd description together with
the ioctl, as both are used together.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Use the proper format for FE_SET_TONE documentation and
improve the documentation.

Keep the enum fe_sec_tone_mode description together with
the ioctl, as both are used together.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Use the proper format for FE_SET_VOLTAGE documentation and fix
the documentation. The description for the enum is not 100%,
and it is missing the voltage off value.

Also, it is better to keep the enum description together with
the ioctl, as both are used together.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Using typedefs is already bad enough, but doing it together
with enum declaration is even worse.

Also, it breaks the scripts at DocBook that would be generating
reference pointers for the enums.

Well, we can't get rid of typedef right now, but let's at least
declare it on a separate line, and let the scripts to generate
the cross-reference, as this is needed for the next DocBook
patches.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

In comments and in the documentation, the units of properties marked
with the FE_SCALE_DECIBEL scale are specified in terms of 1/1000 dB
or 0.0001 dB.  This is inconsistent, however, as 1/1000 is 0.001,
not 0.0001.

Note that the v4l-utils divide the value by 1000 for the signal
strength suggesting that the 1/1000 is correct.

Settle on millidecibels, ie. 1/1000dB or 0.001dB.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The DVBv3 statistics parameters are limited on several ways:
        - It doesn't provide any way to indicate the used measure,
	  so userspace need to guess how to calculate/use it;
        - Only a limited set of stats are supported;
        - Can't be called in a way to require them to be filled
          all at once (atomic reads from the hardware), with may
          cause troubles on interpreting them on userspace;
        - On some OFDM delivery systems, the carriers can be
          independently modulated, having different properties.
          Currently, there's no way to report per-layer stats.
To address the above issues, adding a new DVBv5-based stats API.
While here, correct inner code nomenclature on a few places.
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Unify multistream support at the DVBAPI: several delivery systems
allow it. Yet, each one had its own name. So, instead of adding
a third version of this field, remove the per-standard naming,
unifying it into a common name.

The legacy code number can still be used by old applications.

Version increased to 5.8.

[mchehab@redhat.com: joined the va1j5jf007s patch, in order to
 avoid compilation breakage]
Signed-off-by: NEvgeny Plehov <EvgenyPlehov@ukr.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

No functional changes. It just improves the description of the frontend
status, using Documentation/kernel-doc-nano-HOWTO.txt for the status
enumeration, and a table inside the DocBook.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

After thinking twice, I ended up adding own value for AUTO
interleaving instead of using NONE.

API minor number is not needed to increase as that patch should
be the same Kernel as interleaving parameter is initially added.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Cc: Andreas Oberritter <obi@linuxtv.org>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Mauro is proposing a new API to handle statistics. This functionality will
be returned after the statistics API is ready. Just remove them for now.
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add the following properties for controlling an ATSC-MH frontend:

DTV_ATSCMH_FIC_VER
DTV_ATSCMH_PARADE_ID
DTV_ATSCMH_NOG
DTV_ATSCMH_TNOG
DTV_ATSCMH_SGN
DTV_ATSCMH_PRC
DTV_ATSCMH_RS_FRAME_MODE
DTV_ATSCMH_RS_FRAME_ENSEMBLE
DTV_ATSCMH_RS_CODE_MODE_PRI
DTV_ATSCMH_RS_CODE_MODE_SEC
DTV_ATSCMH_SCCC_BLOCK_MODE
DTV_ATSCMH_SCCC_CODE_MODE_A
DTV_ATSCMH_SCCC_CODE_MODE_B
DTV_ATSCMH_SCCC_CODE_MODE_C
DTV_ATSCMH_SCCC_CODE_MODE_D
DTV_ATSCMH_FIC_ERR
DTV_ATSCMH_CRC_ERR
DTV_ATSCMH_RS_ERR
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Mark info.type as deprecated inside the header, recommending
the usage of DTV_ENUM_DELSYS DVBv5 command instead.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now that all frontends are implementing DVBv5, don't export the
DVBv3 specific stuff to the drivers. Only the core should be
aware of that, as it will keep providing DVBv3 backward compatibility.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using a roll-off factor, change DRX-K & friends to select
the bandwidth filter and the Nyquist half roll-off via delivery system.

This provides a cleaner support for Annex A/C switch.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Use a unique delivery system identifier for DVBC_ANNEX_C, just like any
other.

DVBC_ANNEX_A and DVBC_ANNEX_C have slightly different parameters
and are used in 2 geographically different locations.
Signed-off-by: NManu Abraham <abraham.manu@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

 Currently, for any multi-standard frontend it is assumed that it just
 has a single standard capability. This is fine in some cases, but
 makes things hard when there are incompatible standards in conjuction.
 Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
 the same for DSS. This is not specific to any driver as it is, but a
 generic issue. This was handled correctly in the multiproto tree,
 while such functionality is missing from the v5 API update.

 http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html

 Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
 issue in the v5 API, but that hack is incapable of addressing the
 issue, as it can be used to simply distinguish between DVB-S and
 DVB-S2 alone, or another X vs X2 modulation. If there are more systems,
 then you have a potential issue.

 An application needs to query the device capabilities before requesting
 any operation from the device.
Signed-off-by: NManu Abraham <abraham.manu@gmail.com>
Acked-by: NAndreas Oberritter <obi@linuxtv.org>
Acked-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DVB-C, as defined by ITU-T J.83 has 3 annexes. The differences between
Annex A and Annex C is that Annex C uses a subset of the modulation
types, and uses a different rolloff factor. A different rolloff means
that the bandwidth required is slicely different, and may affect the
saw filter configuration at the tuners. Also, some demods have different
configurations, depending on using Annex A or Annex C.

So, allow userspace to specify it, by changing the rolloff factor.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[steve@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined]
Signed-off-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NSteve Kerrison <steve@stevekerrison.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some (North American) providers use a non-standard mode called
"8psk turbo fec". Since there is no flag in the driver that
would allow an application to determine whether a particular
device can handle "turbo fec", the attached patch introduces
FE_CAN_TURBO_FEC.

Since there is no flag in the SI data that would indicate
that a transponder uses "turbo fec", VDR will assume that
all 8psk transponders on DVB-S use "turbo fec".
Tested-by: NDerek Kelly <user.vdr@gmail.com>
Signed-off-by: NKlaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Patch reverted per Andreas Oberritter <obi@linuxtv.org> request. It is basically
not ready yet for upstream merge.

This reverts commit 77b2ad374a82e3d740cb1780ff4caedc3e051b37.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The enum fe_caps provides flags that allow an application to detect
whether a device is capable of handling various modulation types etc.
A flag for detecting PSK_8, however, is missing.
This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements
it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones
with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.
Signed-off-by: NKlaus Schmidinger <Klaus.Schmidinger@tvdr.de>
Tested-by: NDerek Kelly <user.vdr@gmail.com>
Acked-by: NManu Abraham <manu@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In ISDB-S, time-devision duplex is used to multiplexing several waves
in the same frequency. Each wave is identified by its own transport
stream ID, or TS ID. We need to provide some way to specify this ID
from user applications to handle ISDB-S frontends.

This code has been tested with the Earthsoft PT1 driver.

[mchehab@infradead.org: Fix merge conflicts with isdbt and rename the new parameter to DTV_ISDBS_TS_ID]
Signed-off-by: NHIRANO Takahito <hiranotaka@zng.info>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch increments the DVB-API to version 5.1 in order to reflect the addition of ISDB-T and ISDB-Tsb on Linux' DVB-API.

Changes in detail:
- added a small document to describe how to use the API to tune to an ISDB-T or ISDB-Tsb channel
- added necessary fields to dtv_frontend_cache
- added a smarter clear-cache function which resets all fields of the dtv_frontend_cache
- added a TRANSMISSION_MODE_4K to fe_transmit_mode_t
Signed-off-by: NOlivier Grenie <olgrenie@dibcom.fr>
Signed-off-by: NPatrick Boettcher <pboettcher@dibcom.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

fix the following 'make headers_check' warnings:

  usr/include/linux/dvb/frontend.h:29: include of <linux/types.h> is preferred over <asm/types.h>
  usr/include/linux/dvb/frontend.h:76: found __[us]{8,16,32,64} type without #include <linux/types.h>
Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The attached patch adds a capability flag that allows an application
to determine whether a particular device can handle "second generation
modulation" transponders. This is necessary in order for applications
to be able to decide which device to use for a given channel in
a multi device environment, where DVB-S and DVB-S2 devices are mixed.

It is assumed that a device capable of handling "second generation
modulation" can implicitly handle "first generation modulation".
The flag is not named anything with DVBS2 in order to allow its
use with future DVBT2 devices as well (should they ever come).

Signed-off by: Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>
Acked-by: NSteven Toth <stoth@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NManu Abraham <manu@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NManu Abraham <manu@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Non-initialised cache values get a reasonble default.
Signed-off-by: NDarron Broad <darron@kewl.org>
Signed-off-by: NSteven Toth <stoth@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>