[PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Third iteration of the DD CineCTv6/FlexCT support patches with mostly
all things cleaned up that popped up so far. Obsoletes V1 and V2 series.

These patches enhance the functionality of dvb-frontends/stv0367 to work
with Digital Devices hardware driven by the ST STV0367 demodulator chip
and adds probe & attach bits to ddbridge to make use of them, effectively
enabling full support for CineCTv6 PCIe bridges and (older) DuoFlex CT
addon modules.

While the stv0367 code basically works with the DD hardware (e.g. setup
of demodulation works for both -C and -T delivery systems), some bits
(mostly initialisation) have to be done differently. Also, the static
if_khz configuration is not sufficient as the TDA18212 tuner works at
different IF speeds depending on the delivery system and carrier
bandwidth, so functionality is added to read that speed from the tuner.

The most important part is the addition of register default tabs for
the DD boards, the DD demod initialisation code and the automated
operation mode switch (OFDM vs. QAM) to be able to provide both systems
in one DVB frontend. Everything else is provided by the existing code
or the existing code is enhanced where it didn't suffice. So instead
of duplicating the driver, the existing one is reused. Patches are
laid out in a way to add each enhancement in small increments so they
should be fairly easy to review.

A note on the i2c_gatectrl flag: In the meantime (since v1) I got
clarification why this is needed (reception issues), so I'd prefer to
not diverge from that behaviour to not cause issues for anyone.

Checkpatch complains about some minor style issues, however the patches
were cleaned up beforehand and - where it still complains - match the
rest of the code style throughout the respective files.

In patches where code parts have been picked from other places, proper
credits to the original author is given and permissions where granted
beforehand.

Resulting STV0367/DD support was successfully tested with TVHeadend
and VDR setups by some users, with -C and -T combinations and two+four
port tuner setups (CTv6 with and without attached CT modules). I even
received some more very positive results on this since posting V1.

Apologizes if anything regarding the patch submission is/went wrong,
as this is my first time contribution to OSS via patch emails.

I'd appreciate any comments or even reviews on this to see if the way
the device support is done is acceptable at all, and how to proceed with
this. Having this as part of the 4.12 merge window would ofc be great.

Changes from v2 to v3:
 - refactored tda18212 ping in ddbridge which now even works, added
   i2c_read_regs for this (which is also required in another series)
   and wrapped i2c_read_reg to this
 - missing curly braces added as complained by the kbuild test bot
 - read_status() moved before get_frontend() for further signal stats
   readout (another series)
 - removed superfluous chip_id readout
 - added missing kfree(cab_state) to error cleanup in ddb_attach()
 - "invalid symbol rate" message changed from pr_err to printk to
   match the rest of the file

Changes from v1 to v2:
 - tda18212 modification/hack removed and implemented into ddbridge
   where it shouldn't harm but still is needed due to HW quirks
 - symbolrate_min/max added to dvb_frontend_ops
 - updated commit message body of the i2c_gatectrl flag patch (1/12) so
   it is more clear why this is needed and relevant, updated commit
   message body of 12/12 (ddbridge patch) aswell

Daniel Scheller (13):
  [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional
  [media] dvb-frontends/stv0367: print CPAMP status only if stv_debug is
    enabled
  [media] dvb-frontends/stv0367: refactor defaults table handling
  [media] dvb-frontends/stv0367: move out tables, support multiple tab
    variants
  [media] dvb-frontends/stv0367: make PLLSETUP a function, add 58MHz IC
    speed
  [media] dvb-frontends/stv0367: make full reinit on set_frontend()
    optional
  [media] dvb-frontends/stv0367: support reading if_khz from tuner
    config
  [media] dvb-frontends/stv0367: selectable QAM FEC Lock status register
  [media] dvb-frontends/stv0367: fix symbol rate conditions in
    cab_SetQamSize()
  [media] dvb-frontends/stv0367: add defaults for use w/DD-branded
    devices
  [media] dvb-frontends/stv0367: add Digital Devices compatibility
  [media] ddbridge: add i2c_read_regs()
  [media] ddbridge: support STV0367-based cards and modules

 drivers/media/dvb-frontends/stv0367.c      | 1168 ++++++++++---------------
 drivers/media/dvb-frontends/stv0367.h      |   13 +
 drivers/media/dvb-frontends/stv0367_defs.h | 1301 ++++++++++++++++++++++++++++
 drivers/media/dvb-frontends/stv0367_regs.h |    4 -
 drivers/media/pci/ddbridge/Kconfig         |    3 +
 drivers/media/pci/ddbridge/ddbridge-core.c |  168 +++-
 drivers/media/pci/ddbridge/ddbridge.h      |    1 +
 7 files changed, 1943 insertions(+), 715 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/stv0367_defs.h

-- 
2.10.2

[PATCH v3 01/13] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Some hardware and bridges (namely ddbridge) require that tuner access is
limited to one concurrent access and wrap i2c gate control with a
mutex_lock when attaching frontends. According to vendor information, this
is required as concurrent tuner reconfiguration can interfere each other
and at worst cause tuning fails or bad reception quality.

If the demod driver does gate_ctrl before setting up tuner parameters, and
the tuner does another I2C enable, it will deadlock forever when gate_ctrl
is wrapped into the mutex_lock. This adds a flag and a conditional before
triggering gate_ctrl in the demodulator driver.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index fd49c43..fc80934 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -89,6 +89,8 @@ struct stv0367_state {
 	struct stv0367cab_state *cab_state;
 	/* DVB-T */
 	struct stv0367ter_state *ter_state;
+	/* flags for operation control */
+	u8 use_i2c_gatectrl;
 };
 
 struct st_register {
@@ -1827,10 +1829,10 @@ static int stv0367ter_set_frontend(struct dvb_frontend *fe)
 	stv0367ter_init(fe);
 
 	if (fe->ops.tuner_ops.set_params) {
-		if (fe->ops.i2c_gate_ctrl)
+		if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
 			fe->ops.i2c_gate_ctrl(fe, 1);
 		fe->ops.tuner_ops.set_params(fe);
-		if (fe->ops.i2c_gate_ctrl)
+		if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
 			fe->ops.i2c_gate_ctrl(fe, 0);
 	}
 
@@ -2321,6 +2323,9 @@ struct dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
 	state->fe.demodulator_priv = state;
 	state->chip_id = stv0367_readreg(state, 0xf000);
 
+	/* demod operation options */
+	state->use_i2c_gatectrl = 1;
+
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
 	/* check if the demod is there */
@@ -3120,10 +3125,10 @@ static int stv0367cab_set_frontend(struct dvb_frontend *fe)
 
 	/* Tuner Frequency Setting */
 	if (fe->ops.tuner_ops.set_params) {
-		if (fe->ops.i2c_gate_ctrl)
+		if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
 			fe->ops.i2c_gate_ctrl(fe, 1);
 		fe->ops.tuner_ops.set_params(fe);
-		if (fe->ops.i2c_gate_ctrl)
+		if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
 			fe->ops.i2c_gate_ctrl(fe, 0);
 	}
 
@@ -3437,6 +3442,9 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 	state->fe.demodulator_priv = state;
 	state->chip_id = stv0367_readreg(state, 0xf000);
 
+	/* demod operation options */
+	state->use_i2c_gatectrl = 1;
+
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
 	/* check if the demod is there */
-- 
2.10.2

[PATCH v3 02/13] [media] dvb-frontends/stv0367: print CPAMP status only if stv_debug is enabled

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

The CPAMP log lines generated in stv0367_ter_check_cpamp() are printed
everytime tuning succeeds or fails, quite cluttering the normal kernel log.
Use dprintk() instead of printk(KERN_ERR...) so that if the information is
needed, it'll be printed when the stv_debug modparam is enabled.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index fc80934..0064d9d 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1262,9 +1262,9 @@ stv0367_ter_signal_type stv0367ter_check_cpamp(struct stv0367_state *state,
 	dprintk("******last CPAMPvalue= %d at wd=%d\n", CPAMPvalue, wd);
 	if (CPAMPvalue < CPAMPMin) {
 		CPAMPStatus = FE_TER_NOCPAMP;
-		printk(KERN_ERR "CPAMP failed\n");
+		dprintk("%s: CPAMP failed\n", __func__);
 	} else {
-		printk(KERN_ERR "CPAMP OK !\n");
+		dprintk("%s: CPAMP OK !\n", __func__);
 		CPAMPStatus = FE_TER_CPAMPOK;
 	}
 
-- 
2.10.2

[PATCH v3 03/13] [media] dvb-frontends/stv0367: refactor defaults table handling

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Change defaults table writing so tables can be of dynamic length without
having to keep track of their lengths by adding and evaluating an end
marker (reg 0x0000), also move table writing to a dedicated function to
remove code duplication. Additionally mark st_register tables const since
they're used read-only.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c      | 30 ++++++++++++++++++++----------
 drivers/media/dvb-frontends/stv0367_regs.h |  4 ----
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 0064d9d..5ed52ec 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -99,7 +99,7 @@ struct st_register {
 };
 
 /* values for STV4100 XTAL=30M int clk=53.125M*/
-static struct st_register def0367ter[STV0367TER_NBREGS] = {
+static const struct st_register def0367ter[] = {
 	{R367TER_ID,		0x60},
 	{R367TER_I2CRPT,	0xa0},
 	/* {R367TER_I2CRPT,	0x22},*/
@@ -546,6 +546,7 @@ static struct st_register def0367ter[STV0367TER_NBREGS] = {
 	{R367TER_DEBUG_LT7,	0x00},
 	{R367TER_DEBUG_LT8,	0x00},
 	{R367TER_DEBUG_LT9,	0x00},
+	{0x0000,		0x00},
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -573,7 +574,7 @@ static const s32 stv0367cab_RF_LookUp2[RF_LOOKUP_TABLE2_SIZE][RF_LOOKUP_TABLE2_S
 	}
 };
 
-static struct st_register def0367cab[STV0367CAB_NBREGS] = {
+static const struct st_register def0367cab[] = {
 	{R367CAB_ID,		0x60},
 	{R367CAB_I2CRPT,	0xa0},
 	/*{R367CAB_I2CRPT,	0x22},*/
@@ -762,6 +763,7 @@ static struct st_register def0367cab[STV0367CAB_NBREGS] = {
 	{R367CAB_T_O_ID_1,	0x00},
 	{R367CAB_T_O_ID_2,	0x00},
 	{R367CAB_T_O_ID_3,	0x00},
+	{0x0000,		0x00},
 };
 
 static
@@ -901,6 +903,20 @@ static u8 stv0367_getbits(u8 reg, u32 label)
 	return (reg & mask) >> pos;
 }
 #endif
+
+static void stv0367_write_table(struct stv0367_state *state,
+				const struct st_register *deftab)
+{
+	int i = 0;
+
+	while (1) {
+		if (!deftab[i].addr)
+			break;
+		stv0367_writereg(state, deftab[i].addr, deftab[i].value);
+		i++;
+	}
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
 	struct stv0367_state *state = fe->demodulator_priv;
@@ -1540,15 +1556,12 @@ static int stv0367ter_init(struct dvb_frontend *fe)
 {
 	struct stv0367_state *state = fe->demodulator_priv;
 	struct stv0367ter_state *ter_state = state->ter_state;
-	int i;
 
 	dprintk("%s:\n", __func__);
 
 	ter_state->pBER = 0;
 
-	for (i = 0; i < STV0367TER_NBREGS; i++)
-		stv0367_writereg(state, def0367ter[i].addr,
-					def0367ter[i].value);
+	stv0367_write_table(state, def0367ter);
 
 	switch (state->config->xtal) {
 		/*set internal freq to 53.125MHz */
@@ -2782,13 +2795,10 @@ static int stv0367cab_init(struct dvb_frontend *fe)
 {
 	struct stv0367_state *state = fe->demodulator_priv;
 	struct stv0367cab_state *cab_state = state->cab_state;
-	int i;
 
 	dprintk("%s:\n", __func__);
 
-	for (i = 0; i < STV0367CAB_NBREGS; i++)
-		stv0367_writereg(state, def0367cab[i].addr,
-						def0367cab[i].value);
+	stv0367_write_table(state, def0367cab);
 
 	switch (state->config->ts_mode) {
 	case STV0367_DVBCI_CLOCK:
diff --git a/drivers/media/dvb-frontends/stv0367_regs.h b/drivers/media/dvb-frontends/stv0367_regs.h
index 1d15862..cc66d93 100644
--- a/drivers/media/dvb-frontends/stv0367_regs.h
+++ b/drivers/media/dvb-frontends/stv0367_regs.h
@@ -2639,8 +2639,6 @@
 #define	R367TER_DEBUG_LT9	0xf405
 #define	F367TER_F_DEBUG_LT9	0xf40500ff
 
-#define STV0367TER_NBREGS	445
-
 /* ID */
 #define	R367CAB_ID	0xf000
 #define	F367CAB_IDENTIFICATIONREGISTER	0xf00000ff
@@ -3605,6 +3603,4 @@
 #define	R367CAB_T_O_ID_3	0xf4d3
 #define	F367CAB_TS_ID_I_H	0xf4d300ff
 
-#define STV0367CAB_NBREGS	187
-
 #endif
-- 
2.10.2

[PATCH v3 04/13] [media] dvb-frontends/stv0367: move out tables, support multiple tab variants

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Move the *ter and *cab st_register tables into a separate header file and
additionally organize them via a multidimensional array, allowing to add
more tables with differing init values, and also prepare for a base init
table which should contain general setup values. Also add a state var to
store the table triplet to be used.

Also fixes three minor style problems reported by checkpatch.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c      | 658 +--------------------------
 drivers/media/dvb-frontends/stv0367_defs.h | 693 +++++++++++++++++++++++++++++
 2 files changed, 701 insertions(+), 650 deletions(-)
 create mode 100644 drivers/media/dvb-frontends/stv0367_defs.h

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 5ed52ec..5b52673 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -26,6 +26,7 @@
 #include <linux/i2c.h>
 
 #include "stv0367.h"
+#include "stv0367_defs.h"
 #include "stv0367_regs.h"
 #include "stv0367_priv.h"
 
@@ -91,462 +92,7 @@ struct stv0367_state {
 	struct stv0367ter_state *ter_state;
 	/* flags for operation control */
 	u8 use_i2c_gatectrl;
-};
-
-struct st_register {
-	u16	addr;
-	u8	value;
-};
-
-/* values for STV4100 XTAL=30M int clk=53.125M*/
-static const struct st_register def0367ter[] = {
-	{R367TER_ID,		0x60},
-	{R367TER_I2CRPT,	0xa0},
-	/* {R367TER_I2CRPT,	0x22},*/
-	{R367TER_TOPCTRL,	0x00},/* for xc5000; was 0x02 */
-	{R367TER_IOCFG0,	0x40},
-	{R367TER_DAC0R,		0x00},
-	{R367TER_IOCFG1,	0x00},
-	{R367TER_DAC1R,		0x00},
-	{R367TER_IOCFG2,	0x62},
-	{R367TER_SDFR,		0x00},
-	{R367TER_STATUS,	0xf8},
-	{R367TER_AUX_CLK,	0x0a},
-	{R367TER_FREESYS1,	0x00},
-	{R367TER_FREESYS2,	0x00},
-	{R367TER_FREESYS3,	0x00},
-	{R367TER_GPIO_CFG,	0x55},
-	{R367TER_GPIO_CMD,	0x00},
-	{R367TER_AGC2MAX,	0xff},
-	{R367TER_AGC2MIN,	0x00},
-	{R367TER_AGC1MAX,	0xff},
-	{R367TER_AGC1MIN,	0x00},
-	{R367TER_AGCR,		0xbc},
-	{R367TER_AGC2TH,	0x00},
-	{R367TER_AGC12C,	0x00},
-	{R367TER_AGCCTRL1,	0x85},
-	{R367TER_AGCCTRL2,	0x1f},
-	{R367TER_AGC1VAL1,	0x00},
-	{R367TER_AGC1VAL2,	0x00},
-	{R367TER_AGC2VAL1,	0x6f},
-	{R367TER_AGC2VAL2,	0x05},
-	{R367TER_AGC2PGA,	0x00},
-	{R367TER_OVF_RATE1,	0x00},
-	{R367TER_OVF_RATE2,	0x00},
-	{R367TER_GAIN_SRC1,	0xaa},/* for xc5000; was 0x2b */
-	{R367TER_GAIN_SRC2,	0xd6},/* for xc5000; was 0x04 */
-	{R367TER_INC_DEROT1,	0x55},
-	{R367TER_INC_DEROT2,	0x55},
-	{R367TER_PPM_CPAMP_DIR,	0x2c},
-	{R367TER_PPM_CPAMP_INV,	0x00},
-	{R367TER_FREESTFE_1,	0x00},
-	{R367TER_FREESTFE_2,	0x1c},
-	{R367TER_DCOFFSET,	0x00},
-	{R367TER_EN_PROCESS,	0x05},
-	{R367TER_SDI_SMOOTHER,	0x80},
-	{R367TER_FE_LOOP_OPEN,	0x1c},
-	{R367TER_FREQOFF1,	0x00},
-	{R367TER_FREQOFF2,	0x00},
-	{R367TER_FREQOFF3,	0x00},
-	{R367TER_TIMOFF1,	0x00},
-	{R367TER_TIMOFF2,	0x00},
-	{R367TER_EPQ,		0x02},
-	{R367TER_EPQAUTO,	0x01},
-	{R367TER_SYR_UPDATE,	0xf5},
-	{R367TER_CHPFREE,	0x00},
-	{R367TER_PPM_STATE_MAC,	0x23},
-	{R367TER_INR_THRESHOLD,	0xff},
-	{R367TER_EPQ_TPS_ID_CELL, 0xf9},
-	{R367TER_EPQ_CFG,	0x00},
-	{R367TER_EPQ_STATUS,	0x01},
-	{R367TER_AUTORELOCK,	0x81},
-	{R367TER_BER_THR_VMSB,	0x00},
-	{R367TER_BER_THR_MSB,	0x00},
-	{R367TER_BER_THR_LSB,	0x00},
-	{R367TER_CCD,		0x83},
-	{R367TER_SPECTR_CFG,	0x00},
-	{R367TER_CHC_DUMMY,	0x18},
-	{R367TER_INC_CTL,	0x88},
-	{R367TER_INCTHRES_COR1,	0xb4},
-	{R367TER_INCTHRES_COR2,	0x96},
-	{R367TER_INCTHRES_DET1,	0x0e},
-	{R367TER_INCTHRES_DET2,	0x11},
-	{R367TER_IIR_CELLNB,	0x8d},
-	{R367TER_IIRCX_COEFF1_MSB, 0x00},
-	{R367TER_IIRCX_COEFF1_LSB, 0x00},
-	{R367TER_IIRCX_COEFF2_MSB, 0x09},
-	{R367TER_IIRCX_COEFF2_LSB, 0x18},
-	{R367TER_IIRCX_COEFF3_MSB, 0x14},
-	{R367TER_IIRCX_COEFF3_LSB, 0x9c},
-	{R367TER_IIRCX_COEFF4_MSB, 0x00},
-	{R367TER_IIRCX_COEFF4_LSB, 0x00},
-	{R367TER_IIRCX_COEFF5_MSB, 0x36},
-	{R367TER_IIRCX_COEFF5_LSB, 0x42},
-	{R367TER_FEPATH_CFG,	0x00},
-	{R367TER_PMC1_FUNC,	0x65},
-	{R367TER_PMC1_FOR,	0x00},
-	{R367TER_PMC2_FUNC,	0x00},
-	{R367TER_STATUS_ERR_DA,	0xe0},
-	{R367TER_DIG_AGC_R,	0xfe},
-	{R367TER_COMAGC_TARMSB,	0x0b},
-	{R367TER_COM_AGC_TAR_ENMODE, 0x41},
-	{R367TER_COM_AGC_CFG,	0x3e},
-	{R367TER_COM_AGC_GAIN1, 0x39},
-	{R367TER_AUT_AGC_TARGETMSB, 0x0b},
-	{R367TER_LOCK_DET_MSB,	0x01},
-	{R367TER_AGCTAR_LOCK_LSBS, 0x40},
-	{R367TER_AUT_GAIN_EN,	0xf4},
-	{R367TER_AUT_CFG,	0xf0},
-	{R367TER_LOCKN,		0x23},
-	{R367TER_INT_X_3,	0x00},
-	{R367TER_INT_X_2,	0x03},
-	{R367TER_INT_X_1,	0x8d},
-	{R367TER_INT_X_0,	0xa0},
-	{R367TER_MIN_ERRX_MSB,	0x00},
-	{R367TER_COR_CTL,	0x23},
-	{R367TER_COR_STAT,	0xf6},
-	{R367TER_COR_INTEN,	0x00},
-	{R367TER_COR_INTSTAT,	0x3f},
-	{R367TER_COR_MODEGUARD,	0x03},
-	{R367TER_AGC_CTL,	0x08},
-	{R367TER_AGC_MANUAL1,	0x00},
-	{R367TER_AGC_MANUAL2,	0x00},
-	{R367TER_AGC_TARG,	0x16},
-	{R367TER_AGC_GAIN1,	0x53},
-	{R367TER_AGC_GAIN2,	0x1d},
-	{R367TER_RESERVED_1,	0x00},
-	{R367TER_RESERVED_2,	0x00},
-	{R367TER_RESERVED_3,	0x00},
-	{R367TER_CAS_CTL,	0x44},
-	{R367TER_CAS_FREQ,	0xb3},
-	{R367TER_CAS_DAGCGAIN,	0x12},
-	{R367TER_SYR_CTL,	0x04},
-	{R367TER_SYR_STAT,	0x10},
-	{R367TER_SYR_NCO1,	0x00},
-	{R367TER_SYR_NCO2,	0x00},
-	{R367TER_SYR_OFFSET1,	0x00},
-	{R367TER_SYR_OFFSET2,	0x00},
-	{R367TER_FFT_CTL,	0x00},
-	{R367TER_SCR_CTL,	0x70},
-	{R367TER_PPM_CTL1,	0xf8},
-	{R367TER_TRL_CTL,	0x14},/* for xc5000; was 0xac */
-	{R367TER_TRL_NOMRATE1,	0xae},/* for xc5000; was 0x1e */
-	{R367TER_TRL_NOMRATE2,	0x56},/* for xc5000; was 0x58 */
-	{R367TER_TRL_TIME1,	0x1d},
-	{R367TER_TRL_TIME2,	0xfc},
-	{R367TER_CRL_CTL,	0x24},
-	{R367TER_CRL_FREQ1,	0xad},
-	{R367TER_CRL_FREQ2,	0x9d},
-	{R367TER_CRL_FREQ3,	0xff},
-	{R367TER_CHC_CTL,	0x01},
-	{R367TER_CHC_SNR,	0xf0},
-	{R367TER_BDI_CTL,	0x00},
-	{R367TER_DMP_CTL,	0x00},
-	{R367TER_TPS_RCVD1,	0x30},
-	{R367TER_TPS_RCVD2,	0x02},
-	{R367TER_TPS_RCVD3,	0x01},
-	{R367TER_TPS_RCVD4,	0x00},
-	{R367TER_TPS_ID_CELL1,	0x00},
-	{R367TER_TPS_ID_CELL2,	0x00},
-	{R367TER_TPS_RCVD5_SET1, 0x02},
-	{R367TER_TPS_SET2,	0x02},
-	{R367TER_TPS_SET3,	0x01},
-	{R367TER_TPS_CTL,	0x00},
-	{R367TER_CTL_FFTOSNUM,	0x34},
-	{R367TER_TESTSELECT,	0x09},
-	{R367TER_MSC_REV,	0x0a},
-	{R367TER_PIR_CTL,	0x00},
-	{R367TER_SNR_CARRIER1,	0xa1},
-	{R367TER_SNR_CARRIER2,	0x9a},
-	{R367TER_PPM_CPAMP,	0x2c},
-	{R367TER_TSM_AP0,	0x00},
-	{R367TER_TSM_AP1,	0x00},
-	{R367TER_TSM_AP2 ,	0x00},
-	{R367TER_TSM_AP3,	0x00},
-	{R367TER_TSM_AP4,	0x00},
-	{R367TER_TSM_AP5,	0x00},
-	{R367TER_TSM_AP6,	0x00},
-	{R367TER_TSM_AP7,	0x00},
-	{R367TER_TSTRES,	0x00},
-	{R367TER_ANACTRL,	0x0D},/* PLL stoped, restart at init!!! */
-	{R367TER_TSTBUS,	0x00},
-	{R367TER_TSTRATE,	0x00},
-	{R367TER_CONSTMODE,	0x01},
-	{R367TER_CONSTCARR1,	0x00},
-	{R367TER_CONSTCARR2,	0x00},
-	{R367TER_ICONSTEL,	0x0a},
-	{R367TER_QCONSTEL,	0x15},
-	{R367TER_TSTBISTRES0,	0x00},
-	{R367TER_TSTBISTRES1,	0x00},
-	{R367TER_TSTBISTRES2,	0x28},
-	{R367TER_TSTBISTRES3,	0x00},
-	{R367TER_RF_AGC1,	0xff},
-	{R367TER_RF_AGC2,	0x83},
-	{R367TER_ANADIGCTRL,	0x19},
-	{R367TER_PLLMDIV,	0x01},/* for xc5000; was 0x0c */
-	{R367TER_PLLNDIV,	0x06},/* for xc5000; was 0x55 */
-	{R367TER_PLLSETUP,	0x18},
-	{R367TER_DUAL_AD12,	0x0C},/* for xc5000 AGC voltage 1.6V */
-	{R367TER_TSTBIST,	0x00},
-	{R367TER_PAD_COMP_CTRL,	0x00},
-	{R367TER_PAD_COMP_WR,	0x00},
-	{R367TER_PAD_COMP_RD,	0xe0},
-	{R367TER_SYR_TARGET_FFTADJT_MSB, 0x00},
-	{R367TER_SYR_TARGET_FFTADJT_LSB, 0x00},
-	{R367TER_SYR_TARGET_CHCADJT_MSB, 0x00},
-	{R367TER_SYR_TARGET_CHCADJT_LSB, 0x00},
-	{R367TER_SYR_FLAG,	0x00},
-	{R367TER_CRL_TARGET1,	0x00},
-	{R367TER_CRL_TARGET2,	0x00},
-	{R367TER_CRL_TARGET3,	0x00},
-	{R367TER_CRL_TARGET4,	0x00},
-	{R367TER_CRL_FLAG,	0x00},
-	{R367TER_TRL_TARGET1,	0x00},
-	{R367TER_TRL_TARGET2,	0x00},
-	{R367TER_TRL_CHC,	0x00},
-	{R367TER_CHC_SNR_TARG,	0x00},
-	{R367TER_TOP_TRACK,	0x00},
-	{R367TER_TRACKER_FREE1,	0x00},
-	{R367TER_ERROR_CRL1,	0x00},
-	{R367TER_ERROR_CRL2,	0x00},
-	{R367TER_ERROR_CRL3,	0x00},
-	{R367TER_ERROR_CRL4,	0x00},
-	{R367TER_DEC_NCO1,	0x2c},
-	{R367TER_DEC_NCO2,	0x0f},
-	{R367TER_DEC_NCO3,	0x20},
-	{R367TER_SNR,		0xf1},
-	{R367TER_SYR_FFTADJ1,	0x00},
-	{R367TER_SYR_FFTADJ2,	0x00},
-	{R367TER_SYR_CHCADJ1,	0x00},
-	{R367TER_SYR_CHCADJ2,	0x00},
-	{R367TER_SYR_OFF,	0x00},
-	{R367TER_PPM_OFFSET1,	0x00},
-	{R367TER_PPM_OFFSET2,	0x03},
-	{R367TER_TRACKER_FREE2,	0x00},
-	{R367TER_DEBG_LT10,	0x00},
-	{R367TER_DEBG_LT11,	0x00},
-	{R367TER_DEBG_LT12,	0x00},
-	{R367TER_DEBG_LT13,	0x00},
-	{R367TER_DEBG_LT14,	0x00},
-	{R367TER_DEBG_LT15,	0x00},
-	{R367TER_DEBG_LT16,	0x00},
-	{R367TER_DEBG_LT17,	0x00},
-	{R367TER_DEBG_LT18,	0x00},
-	{R367TER_DEBG_LT19,	0x00},
-	{R367TER_DEBG_LT1A,	0x00},
-	{R367TER_DEBG_LT1B,	0x00},
-	{R367TER_DEBG_LT1C,	0x00},
-	{R367TER_DEBG_LT1D,	0x00},
-	{R367TER_DEBG_LT1E,	0x00},
-	{R367TER_DEBG_LT1F,	0x00},
-	{R367TER_RCCFGH,	0x00},
-	{R367TER_RCCFGM,	0x00},
-	{R367TER_RCCFGL,	0x00},
-	{R367TER_RCINSDELH,	0x00},
-	{R367TER_RCINSDELM,	0x00},
-	{R367TER_RCINSDELL,	0x00},
-	{R367TER_RCSTATUS,	0x00},
-	{R367TER_RCSPEED,	0x6f},
-	{R367TER_RCDEBUGM,	0xe7},
-	{R367TER_RCDEBUGL,	0x9b},
-	{R367TER_RCOBSCFG,	0x00},
-	{R367TER_RCOBSM,	0x00},
-	{R367TER_RCOBSL,	0x00},
-	{R367TER_RCFECSPY,	0x00},
-	{R367TER_RCFSPYCFG,	0x00},
-	{R367TER_RCFSPYDATA,	0x00},
-	{R367TER_RCFSPYOUT,	0x00},
-	{R367TER_RCFSTATUS,	0x00},
-	{R367TER_RCFGOODPACK,	0x00},
-	{R367TER_RCFPACKCNT,	0x00},
-	{R367TER_RCFSPYMISC,	0x00},
-	{R367TER_RCFBERCPT4,	0x00},
-	{R367TER_RCFBERCPT3,	0x00},
-	{R367TER_RCFBERCPT2,	0x00},
-	{R367TER_RCFBERCPT1,	0x00},
-	{R367TER_RCFBERCPT0,	0x00},
-	{R367TER_RCFBERERR2,	0x00},
-	{R367TER_RCFBERERR1,	0x00},
-	{R367TER_RCFBERERR0,	0x00},
-	{R367TER_RCFSTATESM,	0x00},
-	{R367TER_RCFSTATESL,	0x00},
-	{R367TER_RCFSPYBER,	0x00},
-	{R367TER_RCFSPYDISTM,	0x00},
-	{R367TER_RCFSPYDISTL,	0x00},
-	{R367TER_RCFSPYOBS7,	0x00},
-	{R367TER_RCFSPYOBS6,	0x00},
-	{R367TER_RCFSPYOBS5,	0x00},
-	{R367TER_RCFSPYOBS4,	0x00},
-	{R367TER_RCFSPYOBS3,	0x00},
-	{R367TER_RCFSPYOBS2,	0x00},
-	{R367TER_RCFSPYOBS1,	0x00},
-	{R367TER_RCFSPYOBS0,	0x00},
-	{R367TER_TSGENERAL,	0x00},
-	{R367TER_RC1SPEED,	0x6f},
-	{R367TER_TSGSTATUS,	0x18},
-	{R367TER_FECM,		0x01},
-	{R367TER_VTH12,		0xff},
-	{R367TER_VTH23,		0xa1},
-	{R367TER_VTH34,		0x64},
-	{R367TER_VTH56,		0x40},
-	{R367TER_VTH67,		0x00},
-	{R367TER_VTH78,		0x2c},
-	{R367TER_VITCURPUN,	0x12},
-	{R367TER_VERROR,	0x01},
-	{R367TER_PRVIT,		0x3f},
-	{R367TER_VAVSRVIT,	0x00},
-	{R367TER_VSTATUSVIT,	0xbd},
-	{R367TER_VTHINUSE,	0xa1},
-	{R367TER_KDIV12,	0x20},
-	{R367TER_KDIV23,	0x40},
-	{R367TER_KDIV34,	0x20},
-	{R367TER_KDIV56,	0x30},
-	{R367TER_KDIV67,	0x00},
-	{R367TER_KDIV78,	0x30},
-	{R367TER_SIGPOWER,	0x54},
-	{R367TER_DEMAPVIT,	0x40},
-	{R367TER_VITSCALE,	0x00},
-	{R367TER_FFEC1PRG,	0x00},
-	{R367TER_FVITCURPUN,	0x12},
-	{R367TER_FVERROR,	0x01},
-	{R367TER_FVSTATUSVIT,	0xbd},
-	{R367TER_DEBUG_LT1,	0x00},
-	{R367TER_DEBUG_LT2,	0x00},
-	{R367TER_DEBUG_LT3,	0x00},
-	{R367TER_TSTSFMET,	0x00},
-	{R367TER_SELOUT,	0x00},
-	{R367TER_TSYNC,		0x00},
-	{R367TER_TSTERR,	0x00},
-	{R367TER_TSFSYNC,	0x00},
-	{R367TER_TSTSFERR,	0x00},
-	{R367TER_TSTTSSF1,	0x01},
-	{R367TER_TSTTSSF2,	0x1f},
-	{R367TER_TSTTSSF3,	0x00},
-	{R367TER_TSTTS1,	0x00},
-	{R367TER_TSTTS2,	0x1f},
-	{R367TER_TSTTS3,	0x01},
-	{R367TER_TSTTS4,	0x00},
-	{R367TER_TSTTSRC,	0x00},
-	{R367TER_TSTTSRS,	0x00},
-	{R367TER_TSSTATEM,	0xb0},
-	{R367TER_TSSTATEL,	0x40},
-	{R367TER_TSCFGH,	0xC0},
-	{R367TER_TSCFGM,	0xc0},/* for xc5000; was 0x00 */
-	{R367TER_TSCFGL,	0x20},
-	{R367TER_TSSYNC,	0x00},
-	{R367TER_TSINSDELH,	0x00},
-	{R367TER_TSINSDELM,	0x00},
-	{R367TER_TSINSDELL,	0x00},
-	{R367TER_TSDIVN,	0x03},
-	{R367TER_TSDIVPM,	0x00},
-	{R367TER_TSDIVPL,	0x00},
-	{R367TER_TSDIVQM,	0x00},
-	{R367TER_TSDIVQL,	0x00},
-	{R367TER_TSDILSTKM,	0x00},
-	{R367TER_TSDILSTKL,	0x00},
-	{R367TER_TSSPEED,	0x40},/* for xc5000; was 0x6f */
-	{R367TER_TSSTATUS,	0x81},
-	{R367TER_TSSTATUS2,	0x6a},
-	{R367TER_TSBITRATEM,	0x0f},
-	{R367TER_TSBITRATEL,	0xc6},
-	{R367TER_TSPACKLENM,	0x00},
-	{R367TER_TSPACKLENL,	0xfc},
-	{R367TER_TSBLOCLENM,	0x0a},
-	{R367TER_TSBLOCLENL,	0x80},
-	{R367TER_TSDLYH,	0x90},
-	{R367TER_TSDLYM,	0x68},
-	{R367TER_TSDLYL,	0x01},
-	{R367TER_TSNPDAV,	0x00},
-	{R367TER_TSBUFSTATH,	0x00},
-	{R367TER_TSBUFSTATM,	0x00},
-	{R367TER_TSBUFSTATL,	0x00},
-	{R367TER_TSDEBUGM,	0xcf},
-	{R367TER_TSDEBUGL,	0x1e},
-	{R367TER_TSDLYSETH,	0x00},
-	{R367TER_TSDLYSETM,	0x68},
-	{R367TER_TSDLYSETL,	0x00},
-	{R367TER_TSOBSCFG,	0x00},
-	{R367TER_TSOBSM,	0x47},
-	{R367TER_TSOBSL,	0x1f},
-	{R367TER_ERRCTRL1,	0x95},
-	{R367TER_ERRCNT1H,	0x80},
-	{R367TER_ERRCNT1M,	0x00},
-	{R367TER_ERRCNT1L,	0x00},
-	{R367TER_ERRCTRL2,	0x95},
-	{R367TER_ERRCNT2H,	0x00},
-	{R367TER_ERRCNT2M,	0x00},
-	{R367TER_ERRCNT2L,	0x00},
-	{R367TER_FECSPY,	0x88},
-	{R367TER_FSPYCFG,	0x2c},
-	{R367TER_FSPYDATA,	0x3a},
-	{R367TER_FSPYOUT,	0x06},
-	{R367TER_FSTATUS,	0x61},
-	{R367TER_FGOODPACK,	0xff},
-	{R367TER_FPACKCNT,	0xff},
-	{R367TER_FSPYMISC,	0x66},
-	{R367TER_FBERCPT4,	0x00},
-	{R367TER_FBERCPT3,	0x00},
-	{R367TER_FBERCPT2,	0x36},
-	{R367TER_FBERCPT1,	0x36},
-	{R367TER_FBERCPT0,	0x14},
-	{R367TER_FBERERR2,	0x00},
-	{R367TER_FBERERR1,	0x03},
-	{R367TER_FBERERR0,	0x28},
-	{R367TER_FSTATESM,	0x00},
-	{R367TER_FSTATESL,	0x02},
-	{R367TER_FSPYBER,	0x00},
-	{R367TER_FSPYDISTM,	0x01},
-	{R367TER_FSPYDISTL,	0x9f},
-	{R367TER_FSPYOBS7,	0xc9},
-	{R367TER_FSPYOBS6,	0x99},
-	{R367TER_FSPYOBS5,	0x08},
-	{R367TER_FSPYOBS4,	0xec},
-	{R367TER_FSPYOBS3,	0x01},
-	{R367TER_FSPYOBS2,	0x0f},
-	{R367TER_FSPYOBS1,	0xf5},
-	{R367TER_FSPYOBS0,	0x08},
-	{R367TER_SFDEMAP,	0x40},
-	{R367TER_SFERROR,	0x00},
-	{R367TER_SFAVSR,	0x30},
-	{R367TER_SFECSTATUS,	0xcc},
-	{R367TER_SFKDIV12,	0x20},
-	{R367TER_SFKDIV23,	0x40},
-	{R367TER_SFKDIV34,	0x20},
-	{R367TER_SFKDIV56,	0x20},
-	{R367TER_SFKDIV67,	0x00},
-	{R367TER_SFKDIV78,	0x20},
-	{R367TER_SFDILSTKM,	0x00},
-	{R367TER_SFDILSTKL,	0x00},
-	{R367TER_SFSTATUS,	0xb5},
-	{R367TER_SFDLYH,	0x90},
-	{R367TER_SFDLYM,	0x60},
-	{R367TER_SFDLYL,	0x01},
-	{R367TER_SFDLYSETH,	0xc0},
-	{R367TER_SFDLYSETM,	0x60},
-	{R367TER_SFDLYSETL,	0x00},
-	{R367TER_SFOBSCFG,	0x00},
-	{R367TER_SFOBSM,	0x47},
-	{R367TER_SFOBSL,	0x05},
-	{R367TER_SFECINFO,	0x40},
-	{R367TER_SFERRCTRL,	0x74},
-	{R367TER_SFERRCNTH,	0x80},
-	{R367TER_SFERRCNTM ,	0x00},
-	{R367TER_SFERRCNTL,	0x00},
-	{R367TER_SYMBRATEM,	0x2f},
-	{R367TER_SYMBRATEL,	0x50},
-	{R367TER_SYMBSTATUS,	0x7f},
-	{R367TER_SYMBCFG,	0x00},
-	{R367TER_SYMBFIFOM,	0xf4},
-	{R367TER_SYMBFIFOL,	0x0d},
-	{R367TER_SYMBOFFSM,	0xf0},
-	{R367TER_SYMBOFFSL,	0x2d},
-	{R367TER_DEBUG_LT4,	0x00},
-	{R367TER_DEBUG_LT5,	0x00},
-	{R367TER_DEBUG_LT6,	0x00},
-	{R367TER_DEBUG_LT7,	0x00},
-	{R367TER_DEBUG_LT8,	0x00},
-	{R367TER_DEBUG_LT9,	0x00},
-	{0x0000,		0x00},
+	u8 deftabs;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -574,198 +120,6 @@ static const s32 stv0367cab_RF_LookUp2[RF_LOOKUP_TABLE2_SIZE][RF_LOOKUP_TABLE2_S
 	}
 };
 
-static const struct st_register def0367cab[] = {
-	{R367CAB_ID,		0x60},
-	{R367CAB_I2CRPT,	0xa0},
-	/*{R367CAB_I2CRPT,	0x22},*/
-	{R367CAB_TOPCTRL,	0x10},
-	{R367CAB_IOCFG0,	0x80},
-	{R367CAB_DAC0R,		0x00},
-	{R367CAB_IOCFG1,	0x00},
-	{R367CAB_DAC1R,		0x00},
-	{R367CAB_IOCFG2,	0x00},
-	{R367CAB_SDFR,		0x00},
-	{R367CAB_AUX_CLK,	0x00},
-	{R367CAB_FREESYS1,	0x00},
-	{R367CAB_FREESYS2,	0x00},
-	{R367CAB_FREESYS3,	0x00},
-	{R367CAB_GPIO_CFG,	0x55},
-	{R367CAB_GPIO_CMD,	0x01},
-	{R367CAB_TSTRES,	0x00},
-	{R367CAB_ANACTRL,	0x0d},/* was 0x00 need to check - I.M.L.*/
-	{R367CAB_TSTBUS,	0x00},
-	{R367CAB_RF_AGC1,	0xea},
-	{R367CAB_RF_AGC2,	0x82},
-	{R367CAB_ANADIGCTRL,	0x0b},
-	{R367CAB_PLLMDIV,	0x01},
-	{R367CAB_PLLNDIV,	0x08},
-	{R367CAB_PLLSETUP,	0x18},
-	{R367CAB_DUAL_AD12,	0x0C}, /* for xc5000 AGC voltage 1.6V */
-	{R367CAB_TSTBIST,	0x00},
-	{R367CAB_CTRL_1,	0x00},
-	{R367CAB_CTRL_2,	0x03},
-	{R367CAB_IT_STATUS1,	0x2b},
-	{R367CAB_IT_STATUS2,	0x08},
-	{R367CAB_IT_EN1,	0x00},
-	{R367CAB_IT_EN2,	0x00},
-	{R367CAB_CTRL_STATUS,	0x04},
-	{R367CAB_TEST_CTL,	0x00},
-	{R367CAB_AGC_CTL,	0x73},
-	{R367CAB_AGC_IF_CFG,	0x50},
-	{R367CAB_AGC_RF_CFG,	0x00},
-	{R367CAB_AGC_PWM_CFG,	0x03},
-	{R367CAB_AGC_PWR_REF_L,	0x5a},
-	{R367CAB_AGC_PWR_REF_H,	0x00},
-	{R367CAB_AGC_RF_TH_L,	0xff},
-	{R367CAB_AGC_RF_TH_H,	0x07},
-	{R367CAB_AGC_IF_LTH_L,	0x00},
-	{R367CAB_AGC_IF_LTH_H,	0x08},
-	{R367CAB_AGC_IF_HTH_L,	0xff},
-	{R367CAB_AGC_IF_HTH_H,	0x07},
-	{R367CAB_AGC_PWR_RD_L,	0xa0},
-	{R367CAB_AGC_PWR_RD_M,	0xe9},
-	{R367CAB_AGC_PWR_RD_H,	0x03},
-	{R367CAB_AGC_PWM_IFCMD_L,	0xe4},
-	{R367CAB_AGC_PWM_IFCMD_H,	0x00},
-	{R367CAB_AGC_PWM_RFCMD_L,	0xff},
-	{R367CAB_AGC_PWM_RFCMD_H,	0x07},
-	{R367CAB_IQDEM_CFG,	0x01},
-	{R367CAB_MIX_NCO_LL,	0x22},
-	{R367CAB_MIX_NCO_HL,	0x96},
-	{R367CAB_MIX_NCO_HH,	0x55},
-	{R367CAB_SRC_NCO_LL,	0xff},
-	{R367CAB_SRC_NCO_LH,	0x0c},
-	{R367CAB_SRC_NCO_HL,	0xf5},
-	{R367CAB_SRC_NCO_HH,	0x20},
-	{R367CAB_IQDEM_GAIN_SRC_L,	0x06},
-	{R367CAB_IQDEM_GAIN_SRC_H,	0x01},
-	{R367CAB_IQDEM_DCRM_CFG_LL,	0xfe},
-	{R367CAB_IQDEM_DCRM_CFG_LH,	0xff},
-	{R367CAB_IQDEM_DCRM_CFG_HL,	0x0f},
-	{R367CAB_IQDEM_DCRM_CFG_HH,	0x00},
-	{R367CAB_IQDEM_ADJ_COEFF0,	0x34},
-	{R367CAB_IQDEM_ADJ_COEFF1,	0xae},
-	{R367CAB_IQDEM_ADJ_COEFF2,	0x46},
-	{R367CAB_IQDEM_ADJ_COEFF3,	0x77},
-	{R367CAB_IQDEM_ADJ_COEFF4,	0x96},
-	{R367CAB_IQDEM_ADJ_COEFF5,	0x69},
-	{R367CAB_IQDEM_ADJ_COEFF6,	0xc7},
-	{R367CAB_IQDEM_ADJ_COEFF7,	0x01},
-	{R367CAB_IQDEM_ADJ_EN,	0x04},
-	{R367CAB_IQDEM_ADJ_AGC_REF,	0x94},
-	{R367CAB_ALLPASSFILT1,	0xc9},
-	{R367CAB_ALLPASSFILT2,	0x2d},
-	{R367CAB_ALLPASSFILT3,	0xa3},
-	{R367CAB_ALLPASSFILT4,	0xfb},
-	{R367CAB_ALLPASSFILT5,	0xf6},
-	{R367CAB_ALLPASSFILT6,	0x45},
-	{R367CAB_ALLPASSFILT7,	0x6f},
-	{R367CAB_ALLPASSFILT8,	0x7e},
-	{R367CAB_ALLPASSFILT9,	0x05},
-	{R367CAB_ALLPASSFILT10,	0x0a},
-	{R367CAB_ALLPASSFILT11,	0x51},
-	{R367CAB_TRL_AGC_CFG,	0x20},
-	{R367CAB_TRL_LPF_CFG,	0x28},
-	{R367CAB_TRL_LPF_ACQ_GAIN,	0x44},
-	{R367CAB_TRL_LPF_TRK_GAIN,	0x22},
-	{R367CAB_TRL_LPF_OUT_GAIN,	0x03},
-	{R367CAB_TRL_LOCKDET_LTH,	0x04},
-	{R367CAB_TRL_LOCKDET_HTH,	0x11},
-	{R367CAB_TRL_LOCKDET_TRGVAL,	0x20},
-	{R367CAB_IQ_QAM,	0x01},
-	{R367CAB_FSM_STATE,	0xa0},
-	{R367CAB_FSM_CTL,	0x08},
-	{R367CAB_FSM_STS,	0x0c},
-	{R367CAB_FSM_SNR0_HTH,	0x00},
-	{R367CAB_FSM_SNR1_HTH,	0x00},
-	{R367CAB_FSM_SNR2_HTH,	0x23},/* 0x00 */
-	{R367CAB_FSM_SNR0_LTH,	0x00},
-	{R367CAB_FSM_SNR1_LTH,	0x00},
-	{R367CAB_FSM_EQA1_HTH,	0x00},
-	{R367CAB_FSM_TEMPO,	0x32},
-	{R367CAB_FSM_CONFIG,	0x03},
-	{R367CAB_EQU_I_TESTTAP_L,	0x11},
-	{R367CAB_EQU_I_TESTTAP_M,	0x00},
-	{R367CAB_EQU_I_TESTTAP_H,	0x00},
-	{R367CAB_EQU_TESTAP_CFG,	0x00},
-	{R367CAB_EQU_Q_TESTTAP_L,	0xff},
-	{R367CAB_EQU_Q_TESTTAP_M,	0x00},
-	{R367CAB_EQU_Q_TESTTAP_H,	0x00},
-	{R367CAB_EQU_TAP_CTRL,	0x00},
-	{R367CAB_EQU_CTR_CRL_CONTROL_L,	0x11},
-	{R367CAB_EQU_CTR_CRL_CONTROL_H,	0x05},
-	{R367CAB_EQU_CTR_HIPOW_L,	0x00},
-	{R367CAB_EQU_CTR_HIPOW_H,	0x00},
-	{R367CAB_EQU_I_EQU_LO,	0xef},
-	{R367CAB_EQU_I_EQU_HI,	0x00},
-	{R367CAB_EQU_Q_EQU_LO,	0xee},
-	{R367CAB_EQU_Q_EQU_HI,	0x00},
-	{R367CAB_EQU_MAPPER,	0xc5},
-	{R367CAB_EQU_SWEEP_RATE,	0x80},
-	{R367CAB_EQU_SNR_LO,	0x64},
-	{R367CAB_EQU_SNR_HI,	0x03},
-	{R367CAB_EQU_GAMMA_LO,	0x00},
-	{R367CAB_EQU_GAMMA_HI,	0x00},
-	{R367CAB_EQU_ERR_GAIN,	0x36},
-	{R367CAB_EQU_RADIUS,	0xaa},
-	{R367CAB_EQU_FFE_MAINTAP,	0x00},
-	{R367CAB_EQU_FFE_LEAKAGE,	0x63},
-	{R367CAB_EQU_FFE_MAINTAP_POS,	0xdf},
-	{R367CAB_EQU_GAIN_WIDE,	0x88},
-	{R367CAB_EQU_GAIN_NARROW,	0x41},
-	{R367CAB_EQU_CTR_LPF_GAIN,	0xd1},
-	{R367CAB_EQU_CRL_LPF_GAIN,	0xa7},
-	{R367CAB_EQU_GLOBAL_GAIN,	0x06},
-	{R367CAB_EQU_CRL_LD_SEN,	0x85},
-	{R367CAB_EQU_CRL_LD_VAL,	0xe2},
-	{R367CAB_EQU_CRL_TFR,	0x20},
-	{R367CAB_EQU_CRL_BISTH_LO,	0x00},
-	{R367CAB_EQU_CRL_BISTH_HI,	0x00},
-	{R367CAB_EQU_SWEEP_RANGE_LO,	0x00},
-	{R367CAB_EQU_SWEEP_RANGE_HI,	0x00},
-	{R367CAB_EQU_CRL_LIMITER,	0x40},
-	{R367CAB_EQU_MODULUS_MAP,	0x90},
-	{R367CAB_EQU_PNT_GAIN,	0xa7},
-	{R367CAB_FEC_AC_CTR_0,	0x16},
-	{R367CAB_FEC_AC_CTR_1,	0x0b},
-	{R367CAB_FEC_AC_CTR_2,	0x88},
-	{R367CAB_FEC_AC_CTR_3,	0x02},
-	{R367CAB_FEC_STATUS,	0x12},
-	{R367CAB_RS_COUNTER_0,	0x7d},
-	{R367CAB_RS_COUNTER_1,	0xd0},
-	{R367CAB_RS_COUNTER_2,	0x19},
-	{R367CAB_RS_COUNTER_3,	0x0b},
-	{R367CAB_RS_COUNTER_4,	0xa3},
-	{R367CAB_RS_COUNTER_5,	0x00},
-	{R367CAB_BERT_0,	0x01},
-	{R367CAB_BERT_1,	0x25},
-	{R367CAB_BERT_2,	0x41},
-	{R367CAB_BERT_3,	0x39},
-	{R367CAB_OUTFORMAT_0,	0xc2},
-	{R367CAB_OUTFORMAT_1,	0x22},
-	{R367CAB_SMOOTHER_2,	0x28},
-	{R367CAB_TSMF_CTRL_0,	0x01},
-	{R367CAB_TSMF_CTRL_1,	0xc6},
-	{R367CAB_TSMF_CTRL_3,	0x43},
-	{R367CAB_TS_ON_ID_0,	0x00},
-	{R367CAB_TS_ON_ID_1,	0x00},
-	{R367CAB_TS_ON_ID_2,	0x00},
-	{R367CAB_TS_ON_ID_3,	0x00},
-	{R367CAB_RE_STATUS_0,	0x00},
-	{R367CAB_RE_STATUS_1,	0x00},
-	{R367CAB_RE_STATUS_2,	0x00},
-	{R367CAB_RE_STATUS_3,	0x00},
-	{R367CAB_TS_STATUS_0,	0x00},
-	{R367CAB_TS_STATUS_1,	0x00},
-	{R367CAB_TS_STATUS_2,	0xa0},
-	{R367CAB_TS_STATUS_3,	0x00},
-	{R367CAB_T_O_ID_0,	0x00},
-	{R367CAB_T_O_ID_1,	0x00},
-	{R367CAB_T_O_ID_2,	0x00},
-	{R367CAB_T_O_ID_3,	0x00},
-	{0x0000,		0x00},
-};
-
 static
 int stv0367_writeregs(struct stv0367_state *state, u16 reg, u8 *data, int len)
 {
@@ -1561,7 +915,8 @@ static int stv0367ter_init(struct dvb_frontend *fe)
 
 	ter_state->pBER = 0;
 
-	stv0367_write_table(state, def0367ter);
+	stv0367_write_table(state,
+		stv0367_deftabs[state->deftabs][STV0367_TAB_TER]);
 
 	switch (state->config->xtal) {
 		/*set internal freq to 53.125MHz */
@@ -2338,6 +1693,7 @@ struct dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
 
 	/* demod operation options */
 	state->use_i2c_gatectrl = 1;
+	state->deftabs = STV0367_DEFTAB_GENERIC;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
@@ -2798,7 +2154,8 @@ static int stv0367cab_init(struct dvb_frontend *fe)
 
 	dprintk("%s:\n", __func__);
 
-	stv0367_write_table(state, def0367cab);
+	stv0367_write_table(state,
+		stv0367_deftabs[state->deftabs][STV0367_TAB_CAB]);
 
 	switch (state->config->ts_mode) {
 	case STV0367_DVBCI_CLOCK:
@@ -3454,6 +2811,7 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 
 	/* demod operation options */
 	state->use_i2c_gatectrl = 1;
+	state->deftabs = STV0367_DEFTAB_GENERIC;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
diff --git a/drivers/media/dvb-frontends/stv0367_defs.h b/drivers/media/dvb-frontends/stv0367_defs.h
new file mode 100644
index 0000000..53faad6
--- /dev/null
+++ b/drivers/media/dvb-frontends/stv0367_defs.h
@@ -0,0 +1,693 @@
+/*
+ * stv0367_defs.h
+ *
+ * Driver for ST STV0367 DVB-T & DVB-C demodulator IC.
+ *
+ * Copyright (C) ST Microelectronics.
+ * Copyright (C) 2010,2011 NetUP Inc.
+ * Copyright (C) 2010,2011 Igor M. Liplianin <liplianin@netup.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *
+ * GNU General Public License for more details.
+ */
+
+#ifndef STV0367_DEFS_H
+#define STV0367_DEFS_H
+
+#include "stv0367_regs.h"
+
+#define STV0367_DEFTAB_GENERIC	0
+#define STV0367_DEFTAB_MAX	1
+
+#define STV0367_TAB_TER		0
+#define STV0367_TAB_CAB		1
+#define STV0367_TAB_BASE	2
+#define STV0367_TAB_MAX		3
+
+struct st_register {
+	u16	addr;
+	u8	value;
+};
+
+/* values for STV4100 XTAL=30M int clk=53.125M*/
+static const struct st_register def0367ter[] = {
+	{R367TER_ID,		0x60},
+	{R367TER_I2CRPT,	0xa0},
+	/* {R367TER_I2CRPT,	0x22},*/
+	{R367TER_TOPCTRL,	0x00},/* for xc5000; was 0x02 */
+	{R367TER_IOCFG0,	0x40},
+	{R367TER_DAC0R,		0x00},
+	{R367TER_IOCFG1,	0x00},
+	{R367TER_DAC1R,		0x00},
+	{R367TER_IOCFG2,	0x62},
+	{R367TER_SDFR,		0x00},
+	{R367TER_STATUS,	0xf8},
+	{R367TER_AUX_CLK,	0x0a},
+	{R367TER_FREESYS1,	0x00},
+	{R367TER_FREESYS2,	0x00},
+	{R367TER_FREESYS3,	0x00},
+	{R367TER_GPIO_CFG,	0x55},
+	{R367TER_GPIO_CMD,	0x00},
+	{R367TER_AGC2MAX,	0xff},
+	{R367TER_AGC2MIN,	0x00},
+	{R367TER_AGC1MAX,	0xff},
+	{R367TER_AGC1MIN,	0x00},
+	{R367TER_AGCR,		0xbc},
+	{R367TER_AGC2TH,	0x00},
+	{R367TER_AGC12C,	0x00},
+	{R367TER_AGCCTRL1,	0x85},
+	{R367TER_AGCCTRL2,	0x1f},
+	{R367TER_AGC1VAL1,	0x00},
+	{R367TER_AGC1VAL2,	0x00},
+	{R367TER_AGC2VAL1,	0x6f},
+	{R367TER_AGC2VAL2,	0x05},
+	{R367TER_AGC2PGA,	0x00},
+	{R367TER_OVF_RATE1,	0x00},
+	{R367TER_OVF_RATE2,	0x00},
+	{R367TER_GAIN_SRC1,	0xaa},/* for xc5000; was 0x2b */
+	{R367TER_GAIN_SRC2,	0xd6},/* for xc5000; was 0x04 */
+	{R367TER_INC_DEROT1,	0x55},
+	{R367TER_INC_DEROT2,	0x55},
+	{R367TER_PPM_CPAMP_DIR,	0x2c},
+	{R367TER_PPM_CPAMP_INV,	0x00},
+	{R367TER_FREESTFE_1,	0x00},
+	{R367TER_FREESTFE_2,	0x1c},
+	{R367TER_DCOFFSET,	0x00},
+	{R367TER_EN_PROCESS,	0x05},
+	{R367TER_SDI_SMOOTHER,	0x80},
+	{R367TER_FE_LOOP_OPEN,	0x1c},
+	{R367TER_FREQOFF1,	0x00},
+	{R367TER_FREQOFF2,	0x00},
+	{R367TER_FREQOFF3,	0x00},
+	{R367TER_TIMOFF1,	0x00},
+	{R367TER_TIMOFF2,	0x00},
+	{R367TER_EPQ,		0x02},
+	{R367TER_EPQAUTO,	0x01},
+	{R367TER_SYR_UPDATE,	0xf5},
+	{R367TER_CHPFREE,	0x00},
+	{R367TER_PPM_STATE_MAC,	0x23},
+	{R367TER_INR_THRESHOLD,	0xff},
+	{R367TER_EPQ_TPS_ID_CELL, 0xf9},
+	{R367TER_EPQ_CFG,	0x00},
+	{R367TER_EPQ_STATUS,	0x01},
+	{R367TER_AUTORELOCK,	0x81},
+	{R367TER_BER_THR_VMSB,	0x00},
+	{R367TER_BER_THR_MSB,	0x00},
+	{R367TER_BER_THR_LSB,	0x00},
+	{R367TER_CCD,		0x83},
+	{R367TER_SPECTR_CFG,	0x00},
+	{R367TER_CHC_DUMMY,	0x18},
+	{R367TER_INC_CTL,	0x88},
+	{R367TER_INCTHRES_COR1,	0xb4},
+	{R367TER_INCTHRES_COR2,	0x96},
+	{R367TER_INCTHRES_DET1,	0x0e},
+	{R367TER_INCTHRES_DET2,	0x11},
+	{R367TER_IIR_CELLNB,	0x8d},
+	{R367TER_IIRCX_COEFF1_MSB, 0x00},
+	{R367TER_IIRCX_COEFF1_LSB, 0x00},
+	{R367TER_IIRCX_COEFF2_MSB, 0x09},
+	{R367TER_IIRCX_COEFF2_LSB, 0x18},
+	{R367TER_IIRCX_COEFF3_MSB, 0x14},
+	{R367TER_IIRCX_COEFF3_LSB, 0x9c},
+	{R367TER_IIRCX_COEFF4_MSB, 0x00},
+	{R367TER_IIRCX_COEFF4_LSB, 0x00},
+	{R367TER_IIRCX_COEFF5_MSB, 0x36},
+	{R367TER_IIRCX_COEFF5_LSB, 0x42},
+	{R367TER_FEPATH_CFG,	0x00},
+	{R367TER_PMC1_FUNC,	0x65},
+	{R367TER_PMC1_FOR,	0x00},
+	{R367TER_PMC2_FUNC,	0x00},
+	{R367TER_STATUS_ERR_DA,	0xe0},
+	{R367TER_DIG_AGC_R,	0xfe},
+	{R367TER_COMAGC_TARMSB,	0x0b},
+	{R367TER_COM_AGC_TAR_ENMODE, 0x41},
+	{R367TER_COM_AGC_CFG,	0x3e},
+	{R367TER_COM_AGC_GAIN1, 0x39},
+	{R367TER_AUT_AGC_TARGETMSB, 0x0b},
+	{R367TER_LOCK_DET_MSB,	0x01},
+	{R367TER_AGCTAR_LOCK_LSBS, 0x40},
+	{R367TER_AUT_GAIN_EN,	0xf4},
+	{R367TER_AUT_CFG,	0xf0},
+	{R367TER_LOCKN,		0x23},
+	{R367TER_INT_X_3,	0x00},
+	{R367TER_INT_X_2,	0x03},
+	{R367TER_INT_X_1,	0x8d},
+	{R367TER_INT_X_0,	0xa0},
+	{R367TER_MIN_ERRX_MSB,	0x00},
+	{R367TER_COR_CTL,	0x23},
+	{R367TER_COR_STAT,	0xf6},
+	{R367TER_COR_INTEN,	0x00},
+	{R367TER_COR_INTSTAT,	0x3f},
+	{R367TER_COR_MODEGUARD,	0x03},
+	{R367TER_AGC_CTL,	0x08},
+	{R367TER_AGC_MANUAL1,	0x00},
+	{R367TER_AGC_MANUAL2,	0x00},
+	{R367TER_AGC_TARG,	0x16},
+	{R367TER_AGC_GAIN1,	0x53},
+	{R367TER_AGC_GAIN2,	0x1d},
+	{R367TER_RESERVED_1,	0x00},
+	{R367TER_RESERVED_2,	0x00},
+	{R367TER_RESERVED_3,	0x00},
+	{R367TER_CAS_CTL,	0x44},
+	{R367TER_CAS_FREQ,	0xb3},
+	{R367TER_CAS_DAGCGAIN,	0x12},
+	{R367TER_SYR_CTL,	0x04},
+	{R367TER_SYR_STAT,	0x10},
+	{R367TER_SYR_NCO1,	0x00},
+	{R367TER_SYR_NCO2,	0x00},
+	{R367TER_SYR_OFFSET1,	0x00},
+	{R367TER_SYR_OFFSET2,	0x00},
+	{R367TER_FFT_CTL,	0x00},
+	{R367TER_SCR_CTL,	0x70},
+	{R367TER_PPM_CTL1,	0xf8},
+	{R367TER_TRL_CTL,	0x14},/* for xc5000; was 0xac */
+	{R367TER_TRL_NOMRATE1,	0xae},/* for xc5000; was 0x1e */
+	{R367TER_TRL_NOMRATE2,	0x56},/* for xc5000; was 0x58 */
+	{R367TER_TRL_TIME1,	0x1d},
+	{R367TER_TRL_TIME2,	0xfc},
+	{R367TER_CRL_CTL,	0x24},
+	{R367TER_CRL_FREQ1,	0xad},
+	{R367TER_CRL_FREQ2,	0x9d},
+	{R367TER_CRL_FREQ3,	0xff},
+	{R367TER_CHC_CTL,	0x01},
+	{R367TER_CHC_SNR,	0xf0},
+	{R367TER_BDI_CTL,	0x00},
+	{R367TER_DMP_CTL,	0x00},
+	{R367TER_TPS_RCVD1,	0x30},
+	{R367TER_TPS_RCVD2,	0x02},
+	{R367TER_TPS_RCVD3,	0x01},
+	{R367TER_TPS_RCVD4,	0x00},
+	{R367TER_TPS_ID_CELL1,	0x00},
+	{R367TER_TPS_ID_CELL2,	0x00},
+	{R367TER_TPS_RCVD5_SET1, 0x02},
+	{R367TER_TPS_SET2,	0x02},
+	{R367TER_TPS_SET3,	0x01},
+	{R367TER_TPS_CTL,	0x00},
+	{R367TER_CTL_FFTOSNUM,	0x34},
+	{R367TER_TESTSELECT,	0x09},
+	{R367TER_MSC_REV,	0x0a},
+	{R367TER_PIR_CTL,	0x00},
+	{R367TER_SNR_CARRIER1,	0xa1},
+	{R367TER_SNR_CARRIER2,	0x9a},
+	{R367TER_PPM_CPAMP,	0x2c},
+	{R367TER_TSM_AP0,	0x00},
+	{R367TER_TSM_AP1,	0x00},
+	{R367TER_TSM_AP2,	0x00},
+	{R367TER_TSM_AP3,	0x00},
+	{R367TER_TSM_AP4,	0x00},
+	{R367TER_TSM_AP5,	0x00},
+	{R367TER_TSM_AP6,	0x00},
+	{R367TER_TSM_AP7,	0x00},
+	{R367TER_TSTRES,	0x00},
+	{R367TER_ANACTRL,	0x0D},/* PLL stopped, restart at init!!! */
+	{R367TER_TSTBUS,	0x00},
+	{R367TER_TSTRATE,	0x00},
+	{R367TER_CONSTMODE,	0x01},
+	{R367TER_CONSTCARR1,	0x00},
+	{R367TER_CONSTCARR2,	0x00},
+	{R367TER_ICONSTEL,	0x0a},
+	{R367TER_QCONSTEL,	0x15},
+	{R367TER_TSTBISTRES0,	0x00},
+	{R367TER_TSTBISTRES1,	0x00},
+	{R367TER_TSTBISTRES2,	0x28},
+	{R367TER_TSTBISTRES3,	0x00},
+	{R367TER_RF_AGC1,	0xff},
+	{R367TER_RF_AGC2,	0x83},
+	{R367TER_ANADIGCTRL,	0x19},
+	{R367TER_PLLMDIV,	0x01},/* for xc5000; was 0x0c */
+	{R367TER_PLLNDIV,	0x06},/* for xc5000; was 0x55 */
+	{R367TER_PLLSETUP,	0x18},
+	{R367TER_DUAL_AD12,	0x0C},/* for xc5000 AGC voltage 1.6V */
+	{R367TER_TSTBIST,	0x00},
+	{R367TER_PAD_COMP_CTRL,	0x00},
+	{R367TER_PAD_COMP_WR,	0x00},
+	{R367TER_PAD_COMP_RD,	0xe0},
+	{R367TER_SYR_TARGET_FFTADJT_MSB, 0x00},
+	{R367TER_SYR_TARGET_FFTADJT_LSB, 0x00},
+	{R367TER_SYR_TARGET_CHCADJT_MSB, 0x00},
+	{R367TER_SYR_TARGET_CHCADJT_LSB, 0x00},
+	{R367TER_SYR_FLAG,	0x00},
+	{R367TER_CRL_TARGET1,	0x00},
+	{R367TER_CRL_TARGET2,	0x00},
+	{R367TER_CRL_TARGET3,	0x00},
+	{R367TER_CRL_TARGET4,	0x00},
+	{R367TER_CRL_FLAG,	0x00},
+	{R367TER_TRL_TARGET1,	0x00},
+	{R367TER_TRL_TARGET2,	0x00},
+	{R367TER_TRL_CHC,	0x00},
+	{R367TER_CHC_SNR_TARG,	0x00},
+	{R367TER_TOP_TRACK,	0x00},
+	{R367TER_TRACKER_FREE1,	0x00},
+	{R367TER_ERROR_CRL1,	0x00},
+	{R367TER_ERROR_CRL2,	0x00},
+	{R367TER_ERROR_CRL3,	0x00},
+	{R367TER_ERROR_CRL4,	0x00},
+	{R367TER_DEC_NCO1,	0x2c},
+	{R367TER_DEC_NCO2,	0x0f},
+	{R367TER_DEC_NCO3,	0x20},
+	{R367TER_SNR,		0xf1},
+	{R367TER_SYR_FFTADJ1,	0x00},
+	{R367TER_SYR_FFTADJ2,	0x00},
+	{R367TER_SYR_CHCADJ1,	0x00},
+	{R367TER_SYR_CHCADJ2,	0x00},
+	{R367TER_SYR_OFF,	0x00},
+	{R367TER_PPM_OFFSET1,	0x00},
+	{R367TER_PPM_OFFSET2,	0x03},
+	{R367TER_TRACKER_FREE2,	0x00},
+	{R367TER_DEBG_LT10,	0x00},
+	{R367TER_DEBG_LT11,	0x00},
+	{R367TER_DEBG_LT12,	0x00},
+	{R367TER_DEBG_LT13,	0x00},
+	{R367TER_DEBG_LT14,	0x00},
+	{R367TER_DEBG_LT15,	0x00},
+	{R367TER_DEBG_LT16,	0x00},
+	{R367TER_DEBG_LT17,	0x00},
+	{R367TER_DEBG_LT18,	0x00},
+	{R367TER_DEBG_LT19,	0x00},
+	{R367TER_DEBG_LT1A,	0x00},
+	{R367TER_DEBG_LT1B,	0x00},
+	{R367TER_DEBG_LT1C,	0x00},
+	{R367TER_DEBG_LT1D,	0x00},
+	{R367TER_DEBG_LT1E,	0x00},
+	{R367TER_DEBG_LT1F,	0x00},
+	{R367TER_RCCFGH,	0x00},
+	{R367TER_RCCFGM,	0x00},
+	{R367TER_RCCFGL,	0x00},
+	{R367TER_RCINSDELH,	0x00},
+	{R367TER_RCINSDELM,	0x00},
+	{R367TER_RCINSDELL,	0x00},
+	{R367TER_RCSTATUS,	0x00},
+	{R367TER_RCSPEED,	0x6f},
+	{R367TER_RCDEBUGM,	0xe7},
+	{R367TER_RCDEBUGL,	0x9b},
+	{R367TER_RCOBSCFG,	0x00},
+	{R367TER_RCOBSM,	0x00},
+	{R367TER_RCOBSL,	0x00},
+	{R367TER_RCFECSPY,	0x00},
+	{R367TER_RCFSPYCFG,	0x00},
+	{R367TER_RCFSPYDATA,	0x00},
+	{R367TER_RCFSPYOUT,	0x00},
+	{R367TER_RCFSTATUS,	0x00},
+	{R367TER_RCFGOODPACK,	0x00},
+	{R367TER_RCFPACKCNT,	0x00},
+	{R367TER_RCFSPYMISC,	0x00},
+	{R367TER_RCFBERCPT4,	0x00},
+	{R367TER_RCFBERCPT3,	0x00},
+	{R367TER_RCFBERCPT2,	0x00},
+	{R367TER_RCFBERCPT1,	0x00},
+	{R367TER_RCFBERCPT0,	0x00},
+	{R367TER_RCFBERERR2,	0x00},
+	{R367TER_RCFBERERR1,	0x00},
+	{R367TER_RCFBERERR0,	0x00},
+	{R367TER_RCFSTATESM,	0x00},
+	{R367TER_RCFSTATESL,	0x00},
+	{R367TER_RCFSPYBER,	0x00},
+	{R367TER_RCFSPYDISTM,	0x00},
+	{R367TER_RCFSPYDISTL,	0x00},
+	{R367TER_RCFSPYOBS7,	0x00},
+	{R367TER_RCFSPYOBS6,	0x00},
+	{R367TER_RCFSPYOBS5,	0x00},
+	{R367TER_RCFSPYOBS4,	0x00},
+	{R367TER_RCFSPYOBS3,	0x00},
+	{R367TER_RCFSPYOBS2,	0x00},
+	{R367TER_RCFSPYOBS1,	0x00},
+	{R367TER_RCFSPYOBS0,	0x00},
+	{R367TER_TSGENERAL,	0x00},
+	{R367TER_RC1SPEED,	0x6f},
+	{R367TER_TSGSTATUS,	0x18},
+	{R367TER_FECM,		0x01},
+	{R367TER_VTH12,		0xff},
+	{R367TER_VTH23,		0xa1},
+	{R367TER_VTH34,		0x64},
+	{R367TER_VTH56,		0x40},
+	{R367TER_VTH67,		0x00},
+	{R367TER_VTH78,		0x2c},
+	{R367TER_VITCURPUN,	0x12},
+	{R367TER_VERROR,	0x01},
+	{R367TER_PRVIT,		0x3f},
+	{R367TER_VAVSRVIT,	0x00},
+	{R367TER_VSTATUSVIT,	0xbd},
+	{R367TER_VTHINUSE,	0xa1},
+	{R367TER_KDIV12,	0x20},
+	{R367TER_KDIV23,	0x40},
+	{R367TER_KDIV34,	0x20},
+	{R367TER_KDIV56,	0x30},
+	{R367TER_KDIV67,	0x00},
+	{R367TER_KDIV78,	0x30},
+	{R367TER_SIGPOWER,	0x54},
+	{R367TER_DEMAPVIT,	0x40},
+	{R367TER_VITSCALE,	0x00},
+	{R367TER_FFEC1PRG,	0x00},
+	{R367TER_FVITCURPUN,	0x12},
+	{R367TER_FVERROR,	0x01},
+	{R367TER_FVSTATUSVIT,	0xbd},
+	{R367TER_DEBUG_LT1,	0x00},
+	{R367TER_DEBUG_LT2,	0x00},
+	{R367TER_DEBUG_LT3,	0x00},
+	{R367TER_TSTSFMET,	0x00},
+	{R367TER_SELOUT,	0x00},
+	{R367TER_TSYNC,		0x00},
+	{R367TER_TSTERR,	0x00},
+	{R367TER_TSFSYNC,	0x00},
+	{R367TER_TSTSFERR,	0x00},
+	{R367TER_TSTTSSF1,	0x01},
+	{R367TER_TSTTSSF2,	0x1f},
+	{R367TER_TSTTSSF3,	0x00},
+	{R367TER_TSTTS1,	0x00},
+	{R367TER_TSTTS2,	0x1f},
+	{R367TER_TSTTS3,	0x01},
+	{R367TER_TSTTS4,	0x00},
+	{R367TER_TSTTSRC,	0x00},
+	{R367TER_TSTTSRS,	0x00},
+	{R367TER_TSSTATEM,	0xb0},
+	{R367TER_TSSTATEL,	0x40},
+	{R367TER_TSCFGH,	0xC0},
+	{R367TER_TSCFGM,	0xc0},/* for xc5000; was 0x00 */
+	{R367TER_TSCFGL,	0x20},
+	{R367TER_TSSYNC,	0x00},
+	{R367TER_TSINSDELH,	0x00},
+	{R367TER_TSINSDELM,	0x00},
+	{R367TER_TSINSDELL,	0x00},
+	{R367TER_TSDIVN,	0x03},
+	{R367TER_TSDIVPM,	0x00},
+	{R367TER_TSDIVPL,	0x00},
+	{R367TER_TSDIVQM,	0x00},
+	{R367TER_TSDIVQL,	0x00},
+	{R367TER_TSDILSTKM,	0x00},
+	{R367TER_TSDILSTKL,	0x00},
+	{R367TER_TSSPEED,	0x40},/* for xc5000; was 0x6f */
+	{R367TER_TSSTATUS,	0x81},
+	{R367TER_TSSTATUS2,	0x6a},
+	{R367TER_TSBITRATEM,	0x0f},
+	{R367TER_TSBITRATEL,	0xc6},
+	{R367TER_TSPACKLENM,	0x00},
+	{R367TER_TSPACKLENL,	0xfc},
+	{R367TER_TSBLOCLENM,	0x0a},
+	{R367TER_TSBLOCLENL,	0x80},
+	{R367TER_TSDLYH,	0x90},
+	{R367TER_TSDLYM,	0x68},
+	{R367TER_TSDLYL,	0x01},
+	{R367TER_TSNPDAV,	0x00},
+	{R367TER_TSBUFSTATH,	0x00},
+	{R367TER_TSBUFSTATM,	0x00},
+	{R367TER_TSBUFSTATL,	0x00},
+	{R367TER_TSDEBUGM,	0xcf},
+	{R367TER_TSDEBUGL,	0x1e},
+	{R367TER_TSDLYSETH,	0x00},
+	{R367TER_TSDLYSETM,	0x68},
+	{R367TER_TSDLYSETL,	0x00},
+	{R367TER_TSOBSCFG,	0x00},
+	{R367TER_TSOBSM,	0x47},
+	{R367TER_TSOBSL,	0x1f},
+	{R367TER_ERRCTRL1,	0x95},
+	{R367TER_ERRCNT1H,	0x80},
+	{R367TER_ERRCNT1M,	0x00},
+	{R367TER_ERRCNT1L,	0x00},
+	{R367TER_ERRCTRL2,	0x95},
+	{R367TER_ERRCNT2H,	0x00},
+	{R367TER_ERRCNT2M,	0x00},
+	{R367TER_ERRCNT2L,	0x00},
+	{R367TER_FECSPY,	0x88},
+	{R367TER_FSPYCFG,	0x2c},
+	{R367TER_FSPYDATA,	0x3a},
+	{R367TER_FSPYOUT,	0x06},
+	{R367TER_FSTATUS,	0x61},
+	{R367TER_FGOODPACK,	0xff},
+	{R367TER_FPACKCNT,	0xff},
+	{R367TER_FSPYMISC,	0x66},
+	{R367TER_FBERCPT4,	0x00},
+	{R367TER_FBERCPT3,	0x00},
+	{R367TER_FBERCPT2,	0x36},
+	{R367TER_FBERCPT1,	0x36},
+	{R367TER_FBERCPT0,	0x14},
+	{R367TER_FBERERR2,	0x00},
+	{R367TER_FBERERR1,	0x03},
+	{R367TER_FBERERR0,	0x28},
+	{R367TER_FSTATESM,	0x00},
+	{R367TER_FSTATESL,	0x02},
+	{R367TER_FSPYBER,	0x00},
+	{R367TER_FSPYDISTM,	0x01},
+	{R367TER_FSPYDISTL,	0x9f},
+	{R367TER_FSPYOBS7,	0xc9},
+	{R367TER_FSPYOBS6,	0x99},
+	{R367TER_FSPYOBS5,	0x08},
+	{R367TER_FSPYOBS4,	0xec},
+	{R367TER_FSPYOBS3,	0x01},
+	{R367TER_FSPYOBS2,	0x0f},
+	{R367TER_FSPYOBS1,	0xf5},
+	{R367TER_FSPYOBS0,	0x08},
+	{R367TER_SFDEMAP,	0x40},
+	{R367TER_SFERROR,	0x00},
+	{R367TER_SFAVSR,	0x30},
+	{R367TER_SFECSTATUS,	0xcc},
+	{R367TER_SFKDIV12,	0x20},
+	{R367TER_SFKDIV23,	0x40},
+	{R367TER_SFKDIV34,	0x20},
+	{R367TER_SFKDIV56,	0x20},
+	{R367TER_SFKDIV67,	0x00},
+	{R367TER_SFKDIV78,	0x20},
+	{R367TER_SFDILSTKM,	0x00},
+	{R367TER_SFDILSTKL,	0x00},
+	{R367TER_SFSTATUS,	0xb5},
+	{R367TER_SFDLYH,	0x90},
+	{R367TER_SFDLYM,	0x60},
+	{R367TER_SFDLYL,	0x01},
+	{R367TER_SFDLYSETH,	0xc0},
+	{R367TER_SFDLYSETM,	0x60},
+	{R367TER_SFDLYSETL,	0x00},
+	{R367TER_SFOBSCFG,	0x00},
+	{R367TER_SFOBSM,	0x47},
+	{R367TER_SFOBSL,	0x05},
+	{R367TER_SFECINFO,	0x40},
+	{R367TER_SFERRCTRL,	0x74},
+	{R367TER_SFERRCNTH,	0x80},
+	{R367TER_SFERRCNTM,	0x00},
+	{R367TER_SFERRCNTL,	0x00},
+	{R367TER_SYMBRATEM,	0x2f},
+	{R367TER_SYMBRATEL,	0x50},
+	{R367TER_SYMBSTATUS,	0x7f},
+	{R367TER_SYMBCFG,	0x00},
+	{R367TER_SYMBFIFOM,	0xf4},
+	{R367TER_SYMBFIFOL,	0x0d},
+	{R367TER_SYMBOFFSM,	0xf0},
+	{R367TER_SYMBOFFSL,	0x2d},
+	{R367TER_DEBUG_LT4,	0x00},
+	{R367TER_DEBUG_LT5,	0x00},
+	{R367TER_DEBUG_LT6,	0x00},
+	{R367TER_DEBUG_LT7,	0x00},
+	{R367TER_DEBUG_LT8,	0x00},
+	{R367TER_DEBUG_LT9,	0x00},
+	{0x0000,		0x00},
+};
+
+static const struct st_register def0367cab[] = {
+	{R367CAB_ID,		0x60},
+	{R367CAB_I2CRPT,	0xa0},
+	/*{R367CAB_I2CRPT,	0x22},*/
+	{R367CAB_TOPCTRL,	0x10},
+	{R367CAB_IOCFG0,	0x80},
+	{R367CAB_DAC0R,		0x00},
+	{R367CAB_IOCFG1,	0x00},
+	{R367CAB_DAC1R,		0x00},
+	{R367CAB_IOCFG2,	0x00},
+	{R367CAB_SDFR,		0x00},
+	{R367CAB_AUX_CLK,	0x00},
+	{R367CAB_FREESYS1,	0x00},
+	{R367CAB_FREESYS2,	0x00},
+	{R367CAB_FREESYS3,	0x00},
+	{R367CAB_GPIO_CFG,	0x55},
+	{R367CAB_GPIO_CMD,	0x01},
+	{R367CAB_TSTRES,	0x00},
+	{R367CAB_ANACTRL,	0x0d},/* was 0x00 need to check - I.M.L.*/
+	{R367CAB_TSTBUS,	0x00},
+	{R367CAB_RF_AGC1,	0xea},
+	{R367CAB_RF_AGC2,	0x82},
+	{R367CAB_ANADIGCTRL,	0x0b},
+	{R367CAB_PLLMDIV,	0x01},
+	{R367CAB_PLLNDIV,	0x08},
+	{R367CAB_PLLSETUP,	0x18},
+	{R367CAB_DUAL_AD12,	0x0C}, /* for xc5000 AGC voltage 1.6V */
+	{R367CAB_TSTBIST,	0x00},
+	{R367CAB_CTRL_1,	0x00},
+	{R367CAB_CTRL_2,	0x03},
+	{R367CAB_IT_STATUS1,	0x2b},
+	{R367CAB_IT_STATUS2,	0x08},
+	{R367CAB_IT_EN1,	0x00},
+	{R367CAB_IT_EN2,	0x00},
+	{R367CAB_CTRL_STATUS,	0x04},
+	{R367CAB_TEST_CTL,	0x00},
+	{R367CAB_AGC_CTL,	0x73},
+	{R367CAB_AGC_IF_CFG,	0x50},
+	{R367CAB_AGC_RF_CFG,	0x00},
+	{R367CAB_AGC_PWM_CFG,	0x03},
+	{R367CAB_AGC_PWR_REF_L,	0x5a},
+	{R367CAB_AGC_PWR_REF_H,	0x00},
+	{R367CAB_AGC_RF_TH_L,	0xff},
+	{R367CAB_AGC_RF_TH_H,	0x07},
+	{R367CAB_AGC_IF_LTH_L,	0x00},
+	{R367CAB_AGC_IF_LTH_H,	0x08},
+	{R367CAB_AGC_IF_HTH_L,	0xff},
+	{R367CAB_AGC_IF_HTH_H,	0x07},
+	{R367CAB_AGC_PWR_RD_L,	0xa0},
+	{R367CAB_AGC_PWR_RD_M,	0xe9},
+	{R367CAB_AGC_PWR_RD_H,	0x03},
+	{R367CAB_AGC_PWM_IFCMD_L,	0xe4},
+	{R367CAB_AGC_PWM_IFCMD_H,	0x00},
+	{R367CAB_AGC_PWM_RFCMD_L,	0xff},
+	{R367CAB_AGC_PWM_RFCMD_H,	0x07},
+	{R367CAB_IQDEM_CFG,	0x01},
+	{R367CAB_MIX_NCO_LL,	0x22},
+	{R367CAB_MIX_NCO_HL,	0x96},
+	{R367CAB_MIX_NCO_HH,	0x55},
+	{R367CAB_SRC_NCO_LL,	0xff},
+	{R367CAB_SRC_NCO_LH,	0x0c},
+	{R367CAB_SRC_NCO_HL,	0xf5},
+	{R367CAB_SRC_NCO_HH,	0x20},
+	{R367CAB_IQDEM_GAIN_SRC_L,	0x06},
+	{R367CAB_IQDEM_GAIN_SRC_H,	0x01},
+	{R367CAB_IQDEM_DCRM_CFG_LL,	0xfe},
+	{R367CAB_IQDEM_DCRM_CFG_LH,	0xff},
+	{R367CAB_IQDEM_DCRM_CFG_HL,	0x0f},
+	{R367CAB_IQDEM_DCRM_CFG_HH,	0x00},
+	{R367CAB_IQDEM_ADJ_COEFF0,	0x34},
+	{R367CAB_IQDEM_ADJ_COEFF1,	0xae},
+	{R367CAB_IQDEM_ADJ_COEFF2,	0x46},
+	{R367CAB_IQDEM_ADJ_COEFF3,	0x77},
+	{R367CAB_IQDEM_ADJ_COEFF4,	0x96},
+	{R367CAB_IQDEM_ADJ_COEFF5,	0x69},
+	{R367CAB_IQDEM_ADJ_COEFF6,	0xc7},
+	{R367CAB_IQDEM_ADJ_COEFF7,	0x01},
+	{R367CAB_IQDEM_ADJ_EN,	0x04},
+	{R367CAB_IQDEM_ADJ_AGC_REF,	0x94},
+	{R367CAB_ALLPASSFILT1,	0xc9},
+	{R367CAB_ALLPASSFILT2,	0x2d},
+	{R367CAB_ALLPASSFILT3,	0xa3},
+	{R367CAB_ALLPASSFILT4,	0xfb},
+	{R367CAB_ALLPASSFILT5,	0xf6},
+	{R367CAB_ALLPASSFILT6,	0x45},
+	{R367CAB_ALLPASSFILT7,	0x6f},
+	{R367CAB_ALLPASSFILT8,	0x7e},
+	{R367CAB_ALLPASSFILT9,	0x05},
+	{R367CAB_ALLPASSFILT10,	0x0a},
+	{R367CAB_ALLPASSFILT11,	0x51},
+	{R367CAB_TRL_AGC_CFG,	0x20},
+	{R367CAB_TRL_LPF_CFG,	0x28},
+	{R367CAB_TRL_LPF_ACQ_GAIN,	0x44},
+	{R367CAB_TRL_LPF_TRK_GAIN,	0x22},
+	{R367CAB_TRL_LPF_OUT_GAIN,	0x03},
+	{R367CAB_TRL_LOCKDET_LTH,	0x04},
+	{R367CAB_TRL_LOCKDET_HTH,	0x11},
+	{R367CAB_TRL_LOCKDET_TRGVAL,	0x20},
+	{R367CAB_IQ_QAM,	0x01},
+	{R367CAB_FSM_STATE,	0xa0},
+	{R367CAB_FSM_CTL,	0x08},
+	{R367CAB_FSM_STS,	0x0c},
+	{R367CAB_FSM_SNR0_HTH,	0x00},
+	{R367CAB_FSM_SNR1_HTH,	0x00},
+	{R367CAB_FSM_SNR2_HTH,	0x23},/* 0x00 */
+	{R367CAB_FSM_SNR0_LTH,	0x00},
+	{R367CAB_FSM_SNR1_LTH,	0x00},
+	{R367CAB_FSM_EQA1_HTH,	0x00},
+	{R367CAB_FSM_TEMPO,	0x32},
+	{R367CAB_FSM_CONFIG,	0x03},
+	{R367CAB_EQU_I_TESTTAP_L,	0x11},
+	{R367CAB_EQU_I_TESTTAP_M,	0x00},
+	{R367CAB_EQU_I_TESTTAP_H,	0x00},
+	{R367CAB_EQU_TESTAP_CFG,	0x00},
+	{R367CAB_EQU_Q_TESTTAP_L,	0xff},
+	{R367CAB_EQU_Q_TESTTAP_M,	0x00},
+	{R367CAB_EQU_Q_TESTTAP_H,	0x00},
+	{R367CAB_EQU_TAP_CTRL,	0x00},
+	{R367CAB_EQU_CTR_CRL_CONTROL_L,	0x11},
+	{R367CAB_EQU_CTR_CRL_CONTROL_H,	0x05},
+	{R367CAB_EQU_CTR_HIPOW_L,	0x00},
+	{R367CAB_EQU_CTR_HIPOW_H,	0x00},
+	{R367CAB_EQU_I_EQU_LO,	0xef},
+	{R367CAB_EQU_I_EQU_HI,	0x00},
+	{R367CAB_EQU_Q_EQU_LO,	0xee},
+	{R367CAB_EQU_Q_EQU_HI,	0x00},
+	{R367CAB_EQU_MAPPER,	0xc5},
+	{R367CAB_EQU_SWEEP_RATE,	0x80},
+	{R367CAB_EQU_SNR_LO,	0x64},
+	{R367CAB_EQU_SNR_HI,	0x03},
+	{R367CAB_EQU_GAMMA_LO,	0x00},
+	{R367CAB_EQU_GAMMA_HI,	0x00},
+	{R367CAB_EQU_ERR_GAIN,	0x36},
+	{R367CAB_EQU_RADIUS,	0xaa},
+	{R367CAB_EQU_FFE_MAINTAP,	0x00},
+	{R367CAB_EQU_FFE_LEAKAGE,	0x63},
+	{R367CAB_EQU_FFE_MAINTAP_POS,	0xdf},
+	{R367CAB_EQU_GAIN_WIDE,	0x88},
+	{R367CAB_EQU_GAIN_NARROW,	0x41},
+	{R367CAB_EQU_CTR_LPF_GAIN,	0xd1},
+	{R367CAB_EQU_CRL_LPF_GAIN,	0xa7},
+	{R367CAB_EQU_GLOBAL_GAIN,	0x06},
+	{R367CAB_EQU_CRL_LD_SEN,	0x85},
+	{R367CAB_EQU_CRL_LD_VAL,	0xe2},
+	{R367CAB_EQU_CRL_TFR,	0x20},
+	{R367CAB_EQU_CRL_BISTH_LO,	0x00},
+	{R367CAB_EQU_CRL_BISTH_HI,	0x00},
+	{R367CAB_EQU_SWEEP_RANGE_LO,	0x00},
+	{R367CAB_EQU_SWEEP_RANGE_HI,	0x00},
+	{R367CAB_EQU_CRL_LIMITER,	0x40},
+	{R367CAB_EQU_MODULUS_MAP,	0x90},
+	{R367CAB_EQU_PNT_GAIN,	0xa7},
+	{R367CAB_FEC_AC_CTR_0,	0x16},
+	{R367CAB_FEC_AC_CTR_1,	0x0b},
+	{R367CAB_FEC_AC_CTR_2,	0x88},
+	{R367CAB_FEC_AC_CTR_3,	0x02},
+	{R367CAB_FEC_STATUS,	0x12},
+	{R367CAB_RS_COUNTER_0,	0x7d},
+	{R367CAB_RS_COUNTER_1,	0xd0},
+	{R367CAB_RS_COUNTER_2,	0x19},
+	{R367CAB_RS_COUNTER_3,	0x0b},
+	{R367CAB_RS_COUNTER_4,	0xa3},
+	{R367CAB_RS_COUNTER_5,	0x00},
+	{R367CAB_BERT_0,	0x01},
+	{R367CAB_BERT_1,	0x25},
+	{R367CAB_BERT_2,	0x41},
+	{R367CAB_BERT_3,	0x39},
+	{R367CAB_OUTFORMAT_0,	0xc2},
+	{R367CAB_OUTFORMAT_1,	0x22},
+	{R367CAB_SMOOTHER_2,	0x28},
+	{R367CAB_TSMF_CTRL_0,	0x01},
+	{R367CAB_TSMF_CTRL_1,	0xc6},
+	{R367CAB_TSMF_CTRL_3,	0x43},
+	{R367CAB_TS_ON_ID_0,	0x00},
+	{R367CAB_TS_ON_ID_1,	0x00},
+	{R367CAB_TS_ON_ID_2,	0x00},
+	{R367CAB_TS_ON_ID_3,	0x00},
+	{R367CAB_RE_STATUS_0,	0x00},
+	{R367CAB_RE_STATUS_1,	0x00},
+	{R367CAB_RE_STATUS_2,	0x00},
+	{R367CAB_RE_STATUS_3,	0x00},
+	{R367CAB_TS_STATUS_0,	0x00},
+	{R367CAB_TS_STATUS_1,	0x00},
+	{R367CAB_TS_STATUS_2,	0xa0},
+	{R367CAB_TS_STATUS_3,	0x00},
+	{R367CAB_T_O_ID_0,	0x00},
+	{R367CAB_T_O_ID_1,	0x00},
+	{R367CAB_T_O_ID_2,	0x00},
+	{R367CAB_T_O_ID_3,	0x00},
+	{0x0000,		0x00},
+};
+
+/*
+ * Tables combined
+ */
+
+static const struct
+st_register *stv0367_deftabs[STV0367_DEFTAB_MAX][STV0367_TAB_MAX] = {
+	/* generic default/init tabs */
+	{ def0367ter, def0367cab, NULL },
+};
+
+#endif
-- 
2.10.2

[PATCH v3 05/13] [media] dvb-frontends/stv0367: make PLLSETUP a function, add 58MHz IC speed

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

This moves the PLL SETUP code from stv0367ter_init() into a dedicated
function, and also make it possible to configure 58Mhz IC speed at
27MHz Xtal (used on STV0367-based DDB cards/modules in QAM mode).

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 73 +++++++++++++++++++++++------------
 drivers/media/dvb-frontends/stv0367.h |  3 ++
 2 files changed, 51 insertions(+), 25 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 5b52673..da10d9a 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -271,6 +271,53 @@ static void stv0367_write_table(struct stv0367_state *state,
 	}
 }
 
+static void stv0367_pll_setup(struct stv0367_state *state,
+				u32 icspeed, u32 xtal)
+{
+	/* note on regs: R367TER_* and R367CAB_* defines each point to
+	 * 0xf0d8, so just use R367TER_ for both cases
+	 */
+
+	switch (icspeed) {
+	case STV0367_ICSPEED_58000:
+		switch (xtal) {
+		default:
+		case 27000000:
+			dprintk("STV0367 SetCLKgen for 58MHz IC and 27Mhz crystal\n");
+			/* PLLMDIV: 27, PLLNDIV: 232 */
+			stv0367_writereg(state, R367TER_PLLMDIV, 0x1b);
+			stv0367_writereg(state, R367TER_PLLNDIV, 0xe8);
+			break;
+		}
+		break;
+	default:
+	case STV0367_ICSPEED_53125:
+		switch (xtal) {
+			/* set internal freq to 53.125MHz */
+		case 16000000:
+			stv0367_writereg(state, R367TER_PLLMDIV, 0x2);
+			stv0367_writereg(state, R367TER_PLLNDIV, 0x1b);
+			break;
+		case 25000000:
+			stv0367_writereg(state, R367TER_PLLMDIV, 0xa);
+			stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
+			break;
+		default:
+		case 27000000:
+			dprintk("FE_STV0367TER_SetCLKgen for 27Mhz\n");
+			stv0367_writereg(state, R367TER_PLLMDIV, 0x1);
+			stv0367_writereg(state, R367TER_PLLNDIV, 0x8);
+			break;
+		case 30000000:
+			stv0367_writereg(state, R367TER_PLLMDIV, 0xc);
+			stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
+			break;
+		}
+	}
+
+	stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
 	struct stv0367_state *state = fe->demodulator_priv;
@@ -918,31 +965,7 @@ static int stv0367ter_init(struct dvb_frontend *fe)
 	stv0367_write_table(state,
 		stv0367_deftabs[state->deftabs][STV0367_TAB_TER]);
 
-	switch (state->config->xtal) {
-		/*set internal freq to 53.125MHz */
-	case 16000000:
-		stv0367_writereg(state, R367TER_PLLMDIV, 0x2);
-		stv0367_writereg(state, R367TER_PLLNDIV, 0x1b);
-		stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-		break;
-	case 25000000:
-		stv0367_writereg(state, R367TER_PLLMDIV, 0xa);
-		stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
-		stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-		break;
-	default:
-	case 27000000:
-		dprintk("FE_STV0367TER_SetCLKgen for 27Mhz\n");
-		stv0367_writereg(state, R367TER_PLLMDIV, 0x1);
-		stv0367_writereg(state, R367TER_PLLNDIV, 0x8);
-		stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-		break;
-	case 30000000:
-		stv0367_writereg(state, R367TER_PLLMDIV, 0xc);
-		stv0367_writereg(state, R367TER_PLLNDIV, 0x55);
-		stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
-		break;
-	}
+	stv0367_pll_setup(state, STV0367_ICSPEED_53125, state->config->xtal);
 
 	stv0367_writereg(state, R367TER_I2CRPT, 0xa0);
 	stv0367_writereg(state, R367TER_ANACTRL, 0x00);
diff --git a/drivers/media/dvb-frontends/stv0367.h b/drivers/media/dvb-frontends/stv0367.h
index 26c38a0..aaa0236 100644
--- a/drivers/media/dvb-frontends/stv0367.h
+++ b/drivers/media/dvb-frontends/stv0367.h
@@ -25,6 +25,9 @@
 #include <linux/dvb/frontend.h>
 #include "dvb_frontend.h"
 
+#define STV0367_ICSPEED_53125	53125000
+#define STV0367_ICSPEED_58000	58000000
+
 struct stv0367_config {
 	u8 demod_address;
 	u32 xtal;
-- 
2.10.2

[PATCH v3 06/13] [media] dvb-frontends/stv0367: make full reinit on set_frontend() optional

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Every time dvb_frontend_ops.set_frontend() is called, an almost full reinit
of the demodulator will be performed. While this might cause a slight delay
when switching channels due to all involved tables being rewritten, it can
even be dangerous in certain causes in that the demod may lock up and
requires to be powercycled (this can happen on Digital Devices hardware).
So this adds a flag if it should be done, and to not change behaviour with
existing card support, it'll be enabled in all cases.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index da10d9a..9370afa 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -93,6 +93,7 @@ struct stv0367_state {
 	/* flags for operation control */
 	u8 use_i2c_gatectrl;
 	u8 deftabs;
+	u8 reinit_on_setfrontend;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -1217,7 +1218,8 @@ static int stv0367ter_set_frontend(struct dvb_frontend *fe)
 	s8 num_trials, index;
 	u8 SenseTrials[] = { INVERSION_ON, INVERSION_OFF };
 
-	stv0367ter_init(fe);
+	if (state->reinit_on_setfrontend)
+		stv0367ter_init(fe);
 
 	if (fe->ops.tuner_ops.set_params) {
 		if (state->use_i2c_gatectrl && fe->ops.i2c_gate_ctrl)
@@ -1717,6 +1719,7 @@ struct dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
 	/* demod operation options */
 	state->use_i2c_gatectrl = 1;
 	state->deftabs = STV0367_DEFTAB_GENERIC;
+	state->reinit_on_setfrontend = 1;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
@@ -2511,7 +2514,8 @@ static int stv0367cab_set_frontend(struct dvb_frontend *fe)
 		break;
 	}
 
-	stv0367cab_init(fe);
+	if (state->reinit_on_setfrontend)
+		stv0367cab_init(fe);
 
 	/* Tuner Frequency Setting */
 	if (fe->ops.tuner_ops.set_params) {
@@ -2835,6 +2839,7 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 	/* demod operation options */
 	state->use_i2c_gatectrl = 1;
 	state->deftabs = STV0367_DEFTAB_GENERIC;
+	state->reinit_on_setfrontend = 1;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
-- 
2.10.2

[PATCH v3 07/13] [media] dvb-frontends/stv0367: support reading if_khz from tuner config

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Currently, if_khz is set and provided using the configuration var in
struct stv0367_config. However, in some constellations, the value might be
different for differing channel bandwidths or even -T and -C operation.
When e.g. used in conjunction with TDA18212 tuners, the tuner frontend
might be aware of the different freqs. This factors if_khz retrieval in a
function, which checks a new flag if an automatic retrieval attempt should
be made, and if the tuner provides it, use it whenever needed.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 45 +++++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 9370afa..74fee3f 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -94,6 +94,7 @@ struct stv0367_state {
 	u8 use_i2c_gatectrl;
 	u8 deftabs;
 	u8 reinit_on_setfrontend;
+	u8 auto_if_khz;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -319,6 +320,17 @@ static void stv0367_pll_setup(struct stv0367_state *state,
 	stv0367_writereg(state, R367TER_PLLSETUP, 0x18);
 }
 
+static int stv0367_get_if_khz(struct stv0367_state *state, u32 *ifkhz)
+{
+	if (state->auto_if_khz && state->fe.ops.tuner_ops.get_if_frequency) {
+		state->fe.ops.tuner_ops.get_if_frequency(&state->fe, ifkhz);
+		*ifkhz = *ifkhz / 1000; /* hz -> khz */
+	} else
+		*ifkhz = state->config->if_khz;
+
+	return 0;
+}
+
 static int stv0367ter_gate_ctrl(struct dvb_frontend *fe, int enable)
 {
 	struct stv0367_state *state = fe->demodulator_priv;
@@ -992,10 +1004,12 @@ static int stv0367ter_algo(struct dvb_frontend *fe)
 	u8 /*constell,*/ counter;
 	s8 step;
 	s32 timing_offset = 0;
-	u32 trl_nomrate = 0, InternalFreq = 0, temp = 0;
+	u32 trl_nomrate = 0, InternalFreq = 0, temp = 0, ifkhz = 0;
 
 	dprintk("%s:\n", __func__);
 
+	stv0367_get_if_khz(state, &ifkhz);
+
 	ter_state->frequency = p->frequency;
 	ter_state->force = FE_TER_FORCENONE
 			+ stv0367_readbits(state, F367TER_FORCE) * 2;
@@ -1098,8 +1112,7 @@ static int stv0367ter_algo(struct dvb_frontend *fe)
 			stv0367_readbits(state, F367TER_GAIN_SRC_LO);
 
 	temp = (int)
-		((InternalFreq - state->config->if_khz) * (1 << 16)
-							/ (InternalFreq));
+		((InternalFreq - ifkhz) * (1 << 16) / (InternalFreq));
 
 	dprintk("DEROT temp=0x%x\n", temp);
 	stv0367_writebits(state, F367TER_INC_DEROT_HI, temp / 256);
@@ -1720,6 +1733,7 @@ struct dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
 	state->use_i2c_gatectrl = 1;
 	state->deftabs = STV0367_DEFTAB_GENERIC;
 	state->reinit_on_setfrontend = 1;
+	state->auto_if_khz = 0;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
@@ -2229,7 +2243,7 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct stv0367_state *state,
 {
 	struct stv0367cab_state *cab_state = state->cab_state;
 	enum stv0367_cab_signal_type signalType = FE_CAB_NOAGC;
-	u32	QAMFEC_Lock, QAM_Lock, u32_tmp,
+	u32	QAMFEC_Lock, QAM_Lock, u32_tmp, ifkhz,
 		LockTime, TRLTimeOut, AGCTimeOut, CRLSymbols,
 		CRLTimeOut, EQLTimeOut, DemodTimeOut, FECTimeOut;
 	u8	TrackAGCAccum;
@@ -2237,6 +2251,8 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct stv0367_state *state,
 
 	dprintk("%s:\n", __func__);
 
+	stv0367_get_if_khz(state, &ifkhz);
+
 	/* Timeouts calculation */
 	/* A max lock time of 25 ms is allowed for delayed AGC */
 	AGCTimeOut = 25;
@@ -2315,7 +2331,7 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct stv0367_state *state,
 	/* The sweep function is never used, Sweep rate must be set to 0 */
 	/* Set the derotator frequency in Hz */
 	stv0367cab_set_derot_freq(state, cab_state->adc_clk,
-		(1000 * (s32)state->config->if_khz + cab_state->derot_offset));
+		(1000 * (s32)ifkhz + cab_state->derot_offset));
 	/* Disable the Allpass Filter when the symbol rate is out of range */
 	if ((p->symbol_rate > 10800000) | (p->symbol_rate < 1800000)) {
 		stv0367_writebits(state, F367CAB_ADJ_EN, 0);
@@ -2405,17 +2421,17 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct stv0367_state *state,
 							F367CAB_QUAD_INV);
 #if 0
 /* not clear for me */
-		if (state->config->if_khz != 0) {
-			if (state->config->if_khz > cab_state->adc_clk / 1000) {
+		if (ifkhz != 0) {
+			if (ifkhz > cab_state->adc_clk / 1000) {
 				cab_state->freq_khz =
 					FE_Cab_TunerGetFrequency(pIntParams->hTuner)
 				- stv0367cab_get_derot_freq(state, cab_state->adc_clk)
-				- cab_state->adc_clk / 1000 + state->config->if_khz;
+				- cab_state->adc_clk / 1000 + ifkhz;
 			} else {
 				cab_state->freq_khz =
 						FE_Cab_TunerGetFrequency(pIntParams->hTuner)
 						- stv0367cab_get_derot_freq(state, cab_state->adc_clk)
-										+ state->config->if_khz;
+						+ ifkhz;
 			}
 		} else {
 			cab_state->freq_khz =
@@ -2546,11 +2562,13 @@ static int stv0367cab_get_frontend(struct dvb_frontend *fe,
 {
 	struct stv0367_state *state = fe->demodulator_priv;
 	struct stv0367cab_state *cab_state = state->cab_state;
+	u32 ifkhz = 0;
 
 	enum stv0367cab_mod QAMSize;
 
 	dprintk("%s:\n", __func__);
 
+	stv0367_get_if_khz(state, &ifkhz);
 	p->symbol_rate = stv0367cab_GetSymbolRate(state, cab_state->mclk);
 
 	QAMSize = stv0367_readbits(state, F367CAB_QAM_MODE);
@@ -2578,19 +2596,19 @@ static int stv0367cab_get_frontend(struct dvb_frontend *fe,
 
 	dprintk("%s: tuner frequency = %d\n", __func__, p->frequency);
 
-	if (state->config->if_khz == 0) {
+	if (ifkhz == 0) {
 		p->frequency +=
 			(stv0367cab_get_derot_freq(state, cab_state->adc_clk) -
 			cab_state->adc_clk / 4000);
 		return 0;
 	}
 
-	if (state->config->if_khz > cab_state->adc_clk / 1000)
-		p->frequency += (state->config->if_khz
+	if (ifkhz > cab_state->adc_clk / 1000)
+		p->frequency += (ifkhz
 			- stv0367cab_get_derot_freq(state, cab_state->adc_clk)
 			- cab_state->adc_clk / 1000);
 	else
-		p->frequency += (state->config->if_khz
+		p->frequency += (ifkhz
 			- stv0367cab_get_derot_freq(state, cab_state->adc_clk));
 
 	return 0;
@@ -2840,6 +2858,7 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 	state->use_i2c_gatectrl = 1;
 	state->deftabs = STV0367_DEFTAB_GENERIC;
 	state->reinit_on_setfrontend = 1;
+	state->auto_if_khz = 0;
 
 	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
 
-- 
2.10.2

[PATCH v3 08/13] [media] dvb-frontends/stv0367: selectable QAM FEC Lock status register

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

In some configurations (due to different PIN config, wiring or so), the
QAM FECLock might be signalled using a different register than
F367CAB_QAMFEC_LOCK (e.g. F367CAB_DESCR_SYNCSTATE on Digital Devices hw),
so make that register selectable.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index 74fee3f..fb41c7b 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -57,6 +57,7 @@ struct stv0367cab_state {
 	u32 freq_khz;			/* found frequency (in kHz)	*/
 	u32 symbol_rate;		/* found symbol rate (in Bds)	*/
 	enum fe_spectral_inversion spect_inv; /* Spectrum Inversion	*/
+	u32 qamfec_status_reg;          /* status reg to poll for FEC Lock */
 };
 
 struct stv0367ter_state {
@@ -2145,7 +2146,8 @@ static int stv0367cab_read_status(struct dvb_frontend *fe,
 
 	*status = 0;
 
-	if (stv0367_readbits(state, F367CAB_QAMFEC_LOCK)) {
+	if (stv0367_readbits(state, (state->cab_state->qamfec_status_reg ?
+		state->cab_state->qamfec_status_reg : F367CAB_QAMFEC_LOCK))) {
 		*status |= FE_HAS_LOCK;
 		dprintk("%s: stv0367 has locked\n", __func__);
 	}
@@ -2410,7 +2412,9 @@ enum stv0367_cab_signal_type stv0367cab_algo(struct stv0367_state *state,
 			usleep_range(5000, 7000);
 			LockTime += 5;
 			QAMFEC_Lock = stv0367_readbits(state,
-							F367CAB_QAMFEC_LOCK);
+				(state->cab_state->qamfec_status_reg ?
+				state->cab_state->qamfec_status_reg :
+				F367CAB_QAMFEC_LOCK));
 		} while (!QAMFEC_Lock && (LockTime < FECTimeOut));
 	} else
 		QAMFEC_Lock = 0;
@@ -2849,6 +2853,7 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 	state->i2c = i2c;
 	state->config = config;
 	cab_state->search_range = 280000;
+	cab_state->qamfec_status_reg = F367CAB_QAMFEC_LOCK;
 	state->cab_state = cab_state;
 	state->fe.ops = stv0367cab_ops;
 	state->fe.demodulator_priv = state;
-- 
2.10.2

[PATCH v3 09/13] [media] dvb-frontends/stv0367: fix symbol rate conditions in cab_SetQamSize()

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

The values used for comparing symbol rates and the resulting conditional
reg writes seem wrong (rates multiplied by ten), so fix those values.
While this doesn't seem to influence operation, it should be fixed anyway.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index fb41c7b..ffc046a 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1838,11 +1838,11 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct stv0367_state *state,
 	case FE_CAB_MOD_QAM64:
 		stv0367_writereg(state, R367CAB_IQDEM_ADJ_AGC_REF, 0x82);
 		stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x5a);
-		if (SymbolRate > 45000000) {
+		if (SymbolRate > 4500000) {
 			stv0367_writereg(state, R367CAB_FSM_STATE, 0xb0);
 			stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
 			stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa5);
-		} else if (SymbolRate > 25000000) {
+		} else if (SymbolRate > 2500000) {
 			stv0367_writereg(state, R367CAB_FSM_STATE, 0xa0);
 			stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
 			stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa6);
@@ -1860,9 +1860,9 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct stv0367_state *state,
 		stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x76);
 		stv0367_writereg(state, R367CAB_FSM_STATE, 0x90);
 		stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xb1);
-		if (SymbolRate > 45000000)
+		if (SymbolRate > 4500000)
 			stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa7);
-		else if (SymbolRate > 25000000)
+		else if (SymbolRate > 2500000)
 			stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0xa6);
 		else
 			stv0367_writereg(state, R367CAB_EQU_CRL_LPF_GAIN, 0x97);
@@ -1875,9 +1875,9 @@ static enum stv0367cab_mod stv0367cab_SetQamSize(struct stv0367_state *state,
 		stv0367_writereg(state, R367CAB_IQDEM_ADJ_AGC_REF, 0x94);
 		stv0367_writereg(state, R367CAB_AGC_PWR_REF_L, 0x5a);
 		stv0367_writereg(state, R367CAB_FSM_STATE, 0xa0);
-		if (SymbolRate > 45000000)
+		if (SymbolRate > 4500000)
 			stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
-		else if (SymbolRate > 25000000)
+		else if (SymbolRate > 2500000)
 			stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xc1);
 		else
 			stv0367_writereg(state, R367CAB_EQU_CTR_LPF_GAIN, 0xd1);
-- 
2.10.2

[PATCH v3 10/13] [media] dvb-frontends/stv0367: add defaults for use w/DD-branded devices

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Digital Devices uses defaults tables in their stv0367dd demod driver
variant which differ in a few registers, at least enough that no stable
operation can be provided with the tables already present in the driver
(init succeeds and DVB reception works but at least when the driver is
reloaded using rmmod/modprobe, the demod goes into a crashed state in a
way it doesn't react on any I2C command anymore, while even more
side-effects may occur), so there's a good reason to better have another
set of defaults.

Defaults originating from the stv0367dd driver. Permission to reuse them
was formally granted by Ralph Metzler <rjkm@metzlerbros.de>.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367_defs.h | 610 ++++++++++++++++++++++++++++-
 1 file changed, 609 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/stv0367_defs.h b/drivers/media/dvb-frontends/stv0367_defs.h
index 53faad6..277d297 100644
--- a/drivers/media/dvb-frontends/stv0367_defs.h
+++ b/drivers/media/dvb-frontends/stv0367_defs.h
@@ -25,7 +25,8 @@
 #include "stv0367_regs.h"
 
 #define STV0367_DEFTAB_GENERIC	0
-#define STV0367_DEFTAB_MAX	1
+#define STV0367_DEFTAB_DDB	1
+#define STV0367_DEFTAB_MAX	2
 
 #define STV0367_TAB_TER		0
 #define STV0367_TAB_CAB		1
@@ -680,6 +681,611 @@ static const struct st_register def0367cab[] = {
 	{0x0000,		0x00},
 };
 
+/**************
+ *
+ * Defaults / Tables for Digital Devices C/T Cine/Flex devices
+ *
+ **************/
+
+static const struct st_register def0367dd_ofdm[] = {
+	{R367TER_AGC2MAX,                0xff},
+	{R367TER_AGC2MIN,                0x00},
+	{R367TER_AGC1MAX,                0xff},
+	{R367TER_AGC1MIN,                0x00},
+	{R367TER_AGCR,                   0xbc},
+	{R367TER_AGC2TH,                 0x00},
+	{R367TER_AGCCTRL1,               0x85},
+	{R367TER_AGCCTRL2,               0x1f},
+	{R367TER_AGC1VAL1,               0x00},
+	{R367TER_AGC1VAL2,               0x00},
+	{R367TER_AGC2VAL1,               0x6f},
+	{R367TER_AGC2VAL2,               0x05},
+	{R367TER_AGC2PGA,                0x00},
+	{R367TER_OVF_RATE1,              0x00},
+	{R367TER_OVF_RATE2,              0x00},
+	{R367TER_GAIN_SRC1,              0x2b},
+	{R367TER_GAIN_SRC2,              0x04},
+	{R367TER_INC_DEROT1,             0x55},
+	{R367TER_INC_DEROT2,             0x55},
+	{R367TER_PPM_CPAMP_DIR,          0x2c},
+	{R367TER_PPM_CPAMP_INV,          0x00},
+	{R367TER_FREESTFE_1,             0x00},
+	{R367TER_FREESTFE_2,             0x1c},
+	{R367TER_DCOFFSET,               0x00},
+	{R367TER_EN_PROCESS,             0x05},
+	{R367TER_SDI_SMOOTHER,           0x80},
+	{R367TER_FE_LOOP_OPEN,           0x1c},
+	{R367TER_FREQOFF1,               0x00},
+	{R367TER_FREQOFF2,               0x00},
+	{R367TER_FREQOFF3,               0x00},
+	{R367TER_TIMOFF1,                0x00},
+	{R367TER_TIMOFF2,                0x00},
+	{R367TER_EPQ,                    0x02},
+	{R367TER_EPQAUTO,                0x01},
+	{R367TER_SYR_UPDATE,             0xf5},
+	{R367TER_CHPFREE,                0x00},
+	{R367TER_PPM_STATE_MAC,          0x23},
+	{R367TER_INR_THRESHOLD,          0xff},
+	{R367TER_EPQ_TPS_ID_CELL,        0xf9},
+	{R367TER_EPQ_CFG,                0x00},
+	{R367TER_EPQ_STATUS,             0x01},
+	{R367TER_AUTORELOCK,             0x81},
+	{R367TER_BER_THR_VMSB,           0x00},
+	{R367TER_BER_THR_MSB,            0x00},
+	{R367TER_BER_THR_LSB,            0x00},
+	{R367TER_CCD,                    0x83},
+	{R367TER_SPECTR_CFG,             0x00},
+	{R367TER_CHC_DUMMY,              0x18},
+	{R367TER_INC_CTL,                0x88},
+	{R367TER_INCTHRES_COR1,          0xb4},
+	{R367TER_INCTHRES_COR2,          0x96},
+	{R367TER_INCTHRES_DET1,          0x0e},
+	{R367TER_INCTHRES_DET2,          0x11},
+	{R367TER_IIR_CELLNB,             0x8d},
+	{R367TER_IIRCX_COEFF1_MSB,       0x00},
+	{R367TER_IIRCX_COEFF1_LSB,       0x00},
+	{R367TER_IIRCX_COEFF2_MSB,       0x09},
+	{R367TER_IIRCX_COEFF2_LSB,       0x18},
+	{R367TER_IIRCX_COEFF3_MSB,       0x14},
+	{R367TER_IIRCX_COEFF3_LSB,       0x9c},
+	{R367TER_IIRCX_COEFF4_MSB,       0x00},
+	{R367TER_IIRCX_COEFF4_LSB,       0x00},
+	{R367TER_IIRCX_COEFF5_MSB,       0x36},
+	{R367TER_IIRCX_COEFF5_LSB,       0x42},
+	{R367TER_FEPATH_CFG,             0x00},
+	{R367TER_PMC1_FUNC,              0x65},
+	{R367TER_PMC1_FOR,               0x00},
+	{R367TER_PMC2_FUNC,              0x00},
+	{R367TER_STATUS_ERR_DA,          0xe0},
+	{R367TER_DIG_AGC_R,              0xfe},
+	{R367TER_COMAGC_TARMSB,          0x0b},
+	{R367TER_COM_AGC_TAR_ENMODE,     0x41},
+	{R367TER_COM_AGC_CFG,            0x3e},
+	{R367TER_COM_AGC_GAIN1,          0x39},
+	{R367TER_AUT_AGC_TARGETMSB,      0x0b},
+	{R367TER_LOCK_DET_MSB,           0x01},
+	{R367TER_AGCTAR_LOCK_LSBS,       0x40},
+	{R367TER_AUT_GAIN_EN,            0xf4},
+	{R367TER_AUT_CFG,                0xf0},
+	{R367TER_LOCKN,                  0x23},
+	{R367TER_INT_X_3,                0x00},
+	{R367TER_INT_X_2,                0x03},
+	{R367TER_INT_X_1,                0x8d},
+	{R367TER_INT_X_0,                0xa0},
+	{R367TER_MIN_ERRX_MSB,           0x00},
+	{R367TER_COR_CTL,                0x00},
+	{R367TER_COR_STAT,               0xf6},
+	{R367TER_COR_INTEN,              0x00},
+	{R367TER_COR_INTSTAT,            0x3f},
+	{R367TER_COR_MODEGUARD,          0x03},
+	{R367TER_AGC_CTL,                0x08},
+	{R367TER_AGC_MANUAL1,            0x00},
+	{R367TER_AGC_MANUAL2,            0x00},
+	{R367TER_AGC_TARG,               0x16},
+	{R367TER_AGC_GAIN1,              0x53},
+	{R367TER_AGC_GAIN2,              0x1d},
+	{R367TER_RESERVED_1,             0x00},
+	{R367TER_RESERVED_2,             0x00},
+	{R367TER_RESERVED_3,             0x00},
+	{R367TER_CAS_CTL,                0x44},
+	{R367TER_CAS_FREQ,               0xb3},
+	{R367TER_CAS_DAGCGAIN,           0x12},
+	{R367TER_SYR_CTL,                0x04},
+	{R367TER_SYR_STAT,               0x10},
+	{R367TER_SYR_NCO1,               0x00},
+	{R367TER_SYR_NCO2,               0x00},
+	{R367TER_SYR_OFFSET1,            0x00},
+	{R367TER_SYR_OFFSET2,            0x00},
+	{R367TER_FFT_CTL,                0x00},
+	{R367TER_SCR_CTL,                0x70},
+	{R367TER_PPM_CTL1,               0xf8},
+	{R367TER_TRL_CTL,                0xac},
+	{R367TER_TRL_NOMRATE1,           0x1e},
+	{R367TER_TRL_NOMRATE2,           0x58},
+	{R367TER_TRL_TIME1,              0x1d},
+	{R367TER_TRL_TIME2,              0xfc},
+	{R367TER_CRL_CTL,                0x24},
+	{R367TER_CRL_FREQ1,              0xad},
+	{R367TER_CRL_FREQ2,              0x9d},
+	{R367TER_CRL_FREQ3,              0xff},
+	{R367TER_CHC_CTL,                0x01},
+	{R367TER_CHC_SNR,                0xf0},
+	{R367TER_BDI_CTL,                0x00},
+	{R367TER_DMP_CTL,                0x00},
+	{R367TER_TPS_RCVD1,              0x30},
+	{R367TER_TPS_RCVD2,              0x02},
+	{R367TER_TPS_RCVD3,              0x01},
+	{R367TER_TPS_RCVD4,              0x00},
+	{R367TER_TPS_ID_CELL1,           0x00},
+	{R367TER_TPS_ID_CELL2,           0x00},
+	{R367TER_TPS_RCVD5_SET1,         0x02},
+	{R367TER_TPS_SET2,               0x02},
+	{R367TER_TPS_SET3,               0x01},
+	{R367TER_TPS_CTL,                0x00},
+	{R367TER_CTL_FFTOSNUM,           0x34},
+	{R367TER_TESTSELECT,             0x09},
+	{R367TER_MSC_REV,                0x0a},
+	{R367TER_PIR_CTL,                0x00},
+	{R367TER_SNR_CARRIER1,           0xa1},
+	{R367TER_SNR_CARRIER2,           0x9a},
+	{R367TER_PPM_CPAMP,              0x2c},
+	{R367TER_TSM_AP0,                0x00},
+	{R367TER_TSM_AP1,                0x00},
+	{R367TER_TSM_AP2,                0x00},
+	{R367TER_TSM_AP3,                0x00},
+	{R367TER_TSM_AP4,                0x00},
+	{R367TER_TSM_AP5,                0x00},
+	{R367TER_TSM_AP6,                0x00},
+	{R367TER_TSM_AP7,                0x00},
+	{R367TER_CONSTMODE,              0x01},
+	{R367TER_CONSTCARR1,             0x00},
+	{R367TER_CONSTCARR2,             0x00},
+	{R367TER_ICONSTEL,               0x0a},
+	{R367TER_QCONSTEL,               0x15},
+	{R367TER_TSTBISTRES0,            0x00},
+	{R367TER_TSTBISTRES1,            0x00},
+	{R367TER_TSTBISTRES2,            0x28},
+	{R367TER_TSTBISTRES3,            0x00},
+	{R367TER_SYR_TARGET_FFTADJT_MSB, 0x00},
+	{R367TER_SYR_TARGET_FFTADJT_LSB, 0x00},
+	{R367TER_SYR_TARGET_CHCADJT_MSB, 0x00},
+	{R367TER_SYR_TARGET_CHCADJT_LSB, 0x00},
+	{R367TER_SYR_FLAG,               0x00},
+	{R367TER_CRL_TARGET1,            0x00},
+	{R367TER_CRL_TARGET2,            0x00},
+	{R367TER_CRL_TARGET3,            0x00},
+	{R367TER_CRL_TARGET4,            0x00},
+	{R367TER_CRL_FLAG,               0x00},
+	{R367TER_TRL_TARGET1,            0x00},
+	{R367TER_TRL_TARGET2,            0x00},
+	{R367TER_TRL_CHC,                0x00},
+	{R367TER_CHC_SNR_TARG,           0x00},
+	{R367TER_TOP_TRACK,              0x00},
+	{R367TER_TRACKER_FREE1,          0x00},
+	{R367TER_ERROR_CRL1,             0x00},
+	{R367TER_ERROR_CRL2,             0x00},
+	{R367TER_ERROR_CRL3,             0x00},
+	{R367TER_ERROR_CRL4,             0x00},
+	{R367TER_DEC_NCO1,               0x2c},
+	{R367TER_DEC_NCO2,               0x0f},
+	{R367TER_DEC_NCO3,               0x20},
+	{R367TER_SNR,                    0xf1},
+	{R367TER_SYR_FFTADJ1,            0x00},
+	{R367TER_SYR_FFTADJ2,            0x00},
+	{R367TER_SYR_CHCADJ1,            0x00},
+	{R367TER_SYR_CHCADJ2,            0x00},
+	{R367TER_SYR_OFF,                0x00},
+	{R367TER_PPM_OFFSET1,            0x00},
+	{R367TER_PPM_OFFSET2,            0x03},
+	{R367TER_TRACKER_FREE2,          0x00},
+	{R367TER_DEBG_LT10,              0x00},
+	{R367TER_DEBG_LT11,              0x00},
+	{R367TER_DEBG_LT12,              0x00},
+	{R367TER_DEBG_LT13,              0x00},
+	{R367TER_DEBG_LT14,              0x00},
+	{R367TER_DEBG_LT15,              0x00},
+	{R367TER_DEBG_LT16,              0x00},
+	{R367TER_DEBG_LT17,              0x00},
+	{R367TER_DEBG_LT18,              0x00},
+	{R367TER_DEBG_LT19,              0x00},
+	{R367TER_DEBG_LT1A,              0x00},
+	{R367TER_DEBG_LT1B,              0x00},
+	{R367TER_DEBG_LT1C,              0x00},
+	{R367TER_DEBG_LT1D,              0x00},
+	{R367TER_DEBG_LT1E,              0x00},
+	{R367TER_DEBG_LT1F,              0x00},
+	{R367TER_RCCFGH,                 0x00},
+	{R367TER_RCCFGM,                 0x00},
+	{R367TER_RCCFGL,                 0x00},
+	{R367TER_RCINSDELH,              0x00},
+	{R367TER_RCINSDELM,              0x00},
+	{R367TER_RCINSDELL,              0x00},
+	{R367TER_RCSTATUS,               0x00},
+	{R367TER_RCSPEED,                0x6f},
+	{R367TER_RCDEBUGM,               0xe7},
+	{R367TER_RCDEBUGL,               0x9b},
+	{R367TER_RCOBSCFG,               0x00},
+	{R367TER_RCOBSM,                 0x00},
+	{R367TER_RCOBSL,                 0x00},
+	{R367TER_RCFECSPY,               0x00},
+	{R367TER_RCFSPYCFG,              0x00},
+	{R367TER_RCFSPYDATA,             0x00},
+	{R367TER_RCFSPYOUT,              0x00},
+	{R367TER_RCFSTATUS,              0x00},
+	{R367TER_RCFGOODPACK,            0x00},
+	{R367TER_RCFPACKCNT,             0x00},
+	{R367TER_RCFSPYMISC,             0x00},
+	{R367TER_RCFBERCPT4,             0x00},
+	{R367TER_RCFBERCPT3,             0x00},
+	{R367TER_RCFBERCPT2,             0x00},
+	{R367TER_RCFBERCPT1,             0x00},
+	{R367TER_RCFBERCPT0,             0x00},
+	{R367TER_RCFBERERR2,             0x00},
+	{R367TER_RCFBERERR1,             0x00},
+	{R367TER_RCFBERERR0,             0x00},
+	{R367TER_RCFSTATESM,             0x00},
+	{R367TER_RCFSTATESL,             0x00},
+	{R367TER_RCFSPYBER,              0x00},
+	{R367TER_RCFSPYDISTM,            0x00},
+	{R367TER_RCFSPYDISTL,            0x00},
+	{R367TER_RCFSPYOBS7,             0x00},
+	{R367TER_RCFSPYOBS6,             0x00},
+	{R367TER_RCFSPYOBS5,             0x00},
+	{R367TER_RCFSPYOBS4,             0x00},
+	{R367TER_RCFSPYOBS3,             0x00},
+	{R367TER_RCFSPYOBS2,             0x00},
+	{R367TER_RCFSPYOBS1,             0x00},
+	{R367TER_RCFSPYOBS0,             0x00},
+	{R367TER_FECM,                   0x01},
+	{R367TER_VTH12,                  0xff},
+	{R367TER_VTH23,                  0xa1},
+	{R367TER_VTH34,                  0x64},
+	{R367TER_VTH56,                  0x40},
+	{R367TER_VTH67,                  0x00},
+	{R367TER_VTH78,                  0x2c},
+	{R367TER_VITCURPUN,              0x12},
+	{R367TER_VERROR,                 0x01},
+	{R367TER_PRVIT,                  0x3f},
+	{R367TER_VAVSRVIT,               0x00},
+	{R367TER_VSTATUSVIT,             0xbd},
+	{R367TER_VTHINUSE,               0xa1},
+	{R367TER_KDIV12,                 0x20},
+	{R367TER_KDIV23,                 0x40},
+	{R367TER_KDIV34,                 0x20},
+	{R367TER_KDIV56,                 0x30},
+	{R367TER_KDIV67,                 0x00},
+	{R367TER_KDIV78,                 0x30},
+	{R367TER_SIGPOWER,               0x54},
+	{R367TER_DEMAPVIT,               0x40},
+	{R367TER_VITSCALE,               0x00},
+	{R367TER_FFEC1PRG,               0x00},
+	{R367TER_FVITCURPUN,             0x12},
+	{R367TER_FVERROR,                0x01},
+	{R367TER_FVSTATUSVIT,            0xbd},
+	{R367TER_DEBUG_LT1,              0x00},
+	{R367TER_DEBUG_LT2,              0x00},
+	{R367TER_DEBUG_LT3,              0x00},
+	{R367TER_TSTSFMET,               0x00},
+	{R367TER_SELOUT,                 0x00},
+	{R367TER_TSYNC,                  0x00},
+	{R367TER_TSTERR,                 0x00},
+	{R367TER_TSFSYNC,                0x00},
+	{R367TER_TSTSFERR,               0x00},
+	{R367TER_TSTTSSF1,               0x01},
+	{R367TER_TSTTSSF2,               0x1f},
+	{R367TER_TSTTSSF3,               0x00},
+	{R367TER_TSTTS1,                 0x00},
+	{R367TER_TSTTS2,                 0x1f},
+	{R367TER_TSTTS3,                 0x01},
+	{R367TER_TSTTS4,                 0x00},
+	{R367TER_TSTTSRC,                0x00},
+	{R367TER_TSTTSRS,                0x00},
+	{R367TER_TSSTATEM,               0xb0},
+	{R367TER_TSSTATEL,               0x40},
+	{R367TER_TSCFGH,                 0x80},
+	{R367TER_TSCFGM,                 0x00},
+	{R367TER_TSCFGL,                 0x20},
+	{R367TER_TSSYNC,                 0x00},
+	{R367TER_TSINSDELH,              0x00},
+	{R367TER_TSINSDELM,              0x00},
+	{R367TER_TSINSDELL,              0x00},
+	{R367TER_TSDIVN,                 0x03},
+	{R367TER_TSDIVPM,                0x00},
+	{R367TER_TSDIVPL,                0x00},
+	{R367TER_TSDIVQM,                0x00},
+	{R367TER_TSDIVQL,                0x00},
+	{R367TER_TSDILSTKM,              0x00},
+	{R367TER_TSDILSTKL,              0x00},
+	{R367TER_TSSPEED,                0x6f},
+	{R367TER_TSSTATUS,               0x81},
+	{R367TER_TSSTATUS2,              0x6a},
+	{R367TER_TSBITRATEM,             0x0f},
+	{R367TER_TSBITRATEL,             0xc6},
+	{R367TER_TSPACKLENM,             0x00},
+	{R367TER_TSPACKLENL,             0xfc},
+	{R367TER_TSBLOCLENM,             0x0a},
+	{R367TER_TSBLOCLENL,             0x80},
+	{R367TER_TSDLYH,                 0x90},
+	{R367TER_TSDLYM,                 0x68},
+	{R367TER_TSDLYL,                 0x01},
+	{R367TER_TSNPDAV,                0x00},
+	{R367TER_TSBUFSTATH,             0x00},
+	{R367TER_TSBUFSTATM,             0x00},
+	{R367TER_TSBUFSTATL,             0x00},
+	{R367TER_TSDEBUGM,               0xcf},
+	{R367TER_TSDEBUGL,               0x1e},
+	{R367TER_TSDLYSETH,              0x00},
+	{R367TER_TSDLYSETM,              0x68},
+	{R367TER_TSDLYSETL,              0x00},
+	{R367TER_TSOBSCFG,               0x00},
+	{R367TER_TSOBSM,                 0x47},
+	{R367TER_TSOBSL,                 0x1f},
+	{R367TER_ERRCTRL1,               0x95},
+	{R367TER_ERRCNT1H,               0x80},
+	{R367TER_ERRCNT1M,               0x00},
+	{R367TER_ERRCNT1L,               0x00},
+	{R367TER_ERRCTRL2,               0x95},
+	{R367TER_ERRCNT2H,               0x00},
+	{R367TER_ERRCNT2M,               0x00},
+	{R367TER_ERRCNT2L,               0x00},
+	{R367TER_FECSPY,                 0x88},
+	{R367TER_FSPYCFG,                0x2c},
+	{R367TER_FSPYDATA,               0x3a},
+	{R367TER_FSPYOUT,                0x06},
+	{R367TER_FSTATUS,                0x61},
+	{R367TER_FGOODPACK,              0xff},
+	{R367TER_FPACKCNT,               0xff},
+	{R367TER_FSPYMISC,               0x66},
+	{R367TER_FBERCPT4,               0x00},
+	{R367TER_FBERCPT3,               0x00},
+	{R367TER_FBERCPT2,               0x36},
+	{R367TER_FBERCPT1,               0x36},
+	{R367TER_FBERCPT0,               0x14},
+	{R367TER_FBERERR2,               0x00},
+	{R367TER_FBERERR1,               0x03},
+	{R367TER_FBERERR0,               0x28},
+	{R367TER_FSTATESM,               0x00},
+	{R367TER_FSTATESL,               0x02},
+	{R367TER_FSPYBER,                0x00},
+	{R367TER_FSPYDISTM,              0x01},
+	{R367TER_FSPYDISTL,              0x9f},
+	{R367TER_FSPYOBS7,               0xc9},
+	{R367TER_FSPYOBS6,               0x99},
+	{R367TER_FSPYOBS5,               0x08},
+	{R367TER_FSPYOBS4,               0xec},
+	{R367TER_FSPYOBS3,               0x01},
+	{R367TER_FSPYOBS2,               0x0f},
+	{R367TER_FSPYOBS1,               0xf5},
+	{R367TER_FSPYOBS0,               0x08},
+	{R367TER_SFDEMAP,                0x40},
+	{R367TER_SFERROR,                0x00},
+	{R367TER_SFAVSR,                 0x30},
+	{R367TER_SFECSTATUS,             0xcc},
+	{R367TER_SFKDIV12,               0x20},
+	{R367TER_SFKDIV23,               0x40},
+	{R367TER_SFKDIV34,               0x20},
+	{R367TER_SFKDIV56,               0x20},
+	{R367TER_SFKDIV67,               0x00},
+	{R367TER_SFKDIV78,               0x20},
+	{R367TER_SFDILSTKM,              0x00},
+	{R367TER_SFDILSTKL,              0x00},
+	{R367TER_SFSTATUS,               0xb5},
+	{R367TER_SFDLYH,                 0x90},
+	{R367TER_SFDLYM,                 0x60},
+	{R367TER_SFDLYL,                 0x01},
+	{R367TER_SFDLYSETH,              0xc0},
+	{R367TER_SFDLYSETM,              0x60},
+	{R367TER_SFDLYSETL,              0x00},
+	{R367TER_SFOBSCFG,               0x00},
+	{R367TER_SFOBSM,                 0x47},
+	{R367TER_SFOBSL,                 0x05},
+	{R367TER_SFECINFO,               0x40},
+	{R367TER_SFERRCTRL,              0x74},
+	{R367TER_SFERRCNTH,              0x80},
+	{R367TER_SFERRCNTM,              0x00},
+	{R367TER_SFERRCNTL,              0x00},
+	{R367TER_SYMBRATEM,              0x2f},
+	{R367TER_SYMBRATEL,              0x50},
+	{R367TER_SYMBSTATUS,             0x7f},
+	{R367TER_SYMBCFG,                0x00},
+	{R367TER_SYMBFIFOM,              0xf4},
+	{R367TER_SYMBFIFOL,              0x0d},
+	{R367TER_SYMBOFFSM,              0xf0},
+	{R367TER_SYMBOFFSL,              0x2d},
+	{0x0000, 0x00} /* EOT */
+};
+
+static const struct st_register def0367dd_qam[] = {
+	{R367CAB_CTRL_1,                  0x06}, /* Orginal 0x04 */
+	{R367CAB_CTRL_2,                  0x03},
+	{R367CAB_IT_STATUS1,              0x2b},
+	{R367CAB_IT_STATUS2,              0x08},
+	{R367CAB_IT_EN1,                  0x00},
+	{R367CAB_IT_EN2,                  0x00},
+	{R367CAB_CTRL_STATUS,             0x04},
+	{R367CAB_TEST_CTL,                0x00},
+	{R367CAB_AGC_CTL,                 0x73},
+	{R367CAB_AGC_IF_CFG,              0x50},
+	{R367CAB_AGC_RF_CFG,              0x02}, /* RF Freeze */
+	{R367CAB_AGC_PWM_CFG,             0x03},
+	{R367CAB_AGC_PWR_REF_L,           0x5a},
+	{R367CAB_AGC_PWR_REF_H,           0x00},
+	{R367CAB_AGC_RF_TH_L,             0xff},
+	{R367CAB_AGC_RF_TH_H,             0x07},
+	{R367CAB_AGC_IF_LTH_L,            0x00},
+	{R367CAB_AGC_IF_LTH_H,            0x08},
+	{R367CAB_AGC_IF_HTH_L,            0xff},
+	{R367CAB_AGC_IF_HTH_H,            0x07},
+	{R367CAB_AGC_PWR_RD_L,            0xa0},
+	{R367CAB_AGC_PWR_RD_M,            0xe9},
+	{R367CAB_AGC_PWR_RD_H,            0x03},
+	{R367CAB_AGC_PWM_IFCMD_L,         0xe4},
+	{R367CAB_AGC_PWM_IFCMD_H,         0x00},
+	{R367CAB_AGC_PWM_RFCMD_L,         0xff},
+	{R367CAB_AGC_PWM_RFCMD_H,         0x07},
+	{R367CAB_IQDEM_CFG,               0x01},
+	{R367CAB_MIX_NCO_LL,              0x22},
+	{R367CAB_MIX_NCO_HL,              0x96},
+	{R367CAB_MIX_NCO_HH,              0x55},
+	{R367CAB_SRC_NCO_LL,              0xff},
+	{R367CAB_SRC_NCO_LH,              0x0c},
+	{R367CAB_SRC_NCO_HL,              0xf5},
+	{R367CAB_SRC_NCO_HH,              0x20},
+	{R367CAB_IQDEM_GAIN_SRC_L,        0x06},
+	{R367CAB_IQDEM_GAIN_SRC_H,        0x01},
+	{R367CAB_IQDEM_DCRM_CFG_LL,       0xfe},
+	{R367CAB_IQDEM_DCRM_CFG_LH,       0xff},
+	{R367CAB_IQDEM_DCRM_CFG_HL,       0x0f},
+	{R367CAB_IQDEM_DCRM_CFG_HH,       0x00},
+	{R367CAB_IQDEM_ADJ_COEFF0,        0x34},
+	{R367CAB_IQDEM_ADJ_COEFF1,        0xae},
+	{R367CAB_IQDEM_ADJ_COEFF2,        0x46},
+	{R367CAB_IQDEM_ADJ_COEFF3,        0x77},
+	{R367CAB_IQDEM_ADJ_COEFF4,        0x96},
+	{R367CAB_IQDEM_ADJ_COEFF5,        0x69},
+	{R367CAB_IQDEM_ADJ_COEFF6,        0xc7},
+	{R367CAB_IQDEM_ADJ_COEFF7,        0x01},
+	{R367CAB_IQDEM_ADJ_EN,            0x04},
+	{R367CAB_IQDEM_ADJ_AGC_REF,       0x94},
+	{R367CAB_ALLPASSFILT1,            0xc9},
+	{R367CAB_ALLPASSFILT2,            0x2d},
+	{R367CAB_ALLPASSFILT3,            0xa3},
+	{R367CAB_ALLPASSFILT4,            0xfb},
+	{R367CAB_ALLPASSFILT5,            0xf6},
+	{R367CAB_ALLPASSFILT6,            0x45},
+	{R367CAB_ALLPASSFILT7,            0x6f},
+	{R367CAB_ALLPASSFILT8,            0x7e},
+	{R367CAB_ALLPASSFILT9,            0x05},
+	{R367CAB_ALLPASSFILT10,           0x0a},
+	{R367CAB_ALLPASSFILT11,           0x51},
+	{R367CAB_TRL_AGC_CFG,             0x20},
+	{R367CAB_TRL_LPF_CFG,             0x28},
+	{R367CAB_TRL_LPF_ACQ_GAIN,        0x44},
+	{R367CAB_TRL_LPF_TRK_GAIN,        0x22},
+	{R367CAB_TRL_LPF_OUT_GAIN,        0x03},
+	{R367CAB_TRL_LOCKDET_LTH,         0x04},
+	{R367CAB_TRL_LOCKDET_HTH,         0x11},
+	{R367CAB_TRL_LOCKDET_TRGVAL,      0x20},
+	{R367CAB_IQ_QAM,                  0x01},
+	{R367CAB_FSM_STATE,               0xa0},
+	{R367CAB_FSM_CTL,                 0x08},
+	{R367CAB_FSM_STS,                 0x0c},
+	{R367CAB_FSM_SNR0_HTH,            0x00},
+	{R367CAB_FSM_SNR1_HTH,            0x00},
+	{R367CAB_FSM_SNR2_HTH,            0x00},
+	{R367CAB_FSM_SNR0_LTH,            0x00},
+	{R367CAB_FSM_SNR1_LTH,            0x00},
+	{R367CAB_FSM_EQA1_HTH,            0x00},
+	{R367CAB_FSM_TEMPO,               0x32},
+	{R367CAB_FSM_CONFIG,              0x03},
+	{R367CAB_EQU_I_TESTTAP_L,         0x11},
+	{R367CAB_EQU_I_TESTTAP_M,         0x00},
+	{R367CAB_EQU_I_TESTTAP_H,         0x00},
+	{R367CAB_EQU_TESTAP_CFG,          0x00},
+	{R367CAB_EQU_Q_TESTTAP_L,         0xff},
+	{R367CAB_EQU_Q_TESTTAP_M,         0x00},
+	{R367CAB_EQU_Q_TESTTAP_H,         0x00},
+	{R367CAB_EQU_TAP_CTRL,            0x00},
+	{R367CAB_EQU_CTR_CRL_CONTROL_L,   0x11},
+	{R367CAB_EQU_CTR_CRL_CONTROL_H,   0x05},
+	{R367CAB_EQU_CTR_HIPOW_L,         0x00},
+	{R367CAB_EQU_CTR_HIPOW_H,         0x00},
+	{R367CAB_EQU_I_EQU_LO,            0xef},
+	{R367CAB_EQU_I_EQU_HI,            0x00},
+	{R367CAB_EQU_Q_EQU_LO,            0xee},
+	{R367CAB_EQU_Q_EQU_HI,            0x00},
+	{R367CAB_EQU_MAPPER,              0xc5},
+	{R367CAB_EQU_SWEEP_RATE,          0x80},
+	{R367CAB_EQU_SNR_LO,              0x64},
+	{R367CAB_EQU_SNR_HI,              0x03},
+	{R367CAB_EQU_GAMMA_LO,            0x00},
+	{R367CAB_EQU_GAMMA_HI,            0x00},
+	{R367CAB_EQU_ERR_GAIN,            0x36},
+	{R367CAB_EQU_RADIUS,              0xaa},
+	{R367CAB_EQU_FFE_MAINTAP,         0x00},
+	{R367CAB_EQU_FFE_LEAKAGE,         0x63},
+	{R367CAB_EQU_FFE_MAINTAP_POS,     0xdf},
+	{R367CAB_EQU_GAIN_WIDE,           0x88},
+	{R367CAB_EQU_GAIN_NARROW,         0x41},
+	{R367CAB_EQU_CTR_LPF_GAIN,        0xd1},
+	{R367CAB_EQU_CRL_LPF_GAIN,        0xa7},
+	{R367CAB_EQU_GLOBAL_GAIN,         0x06},
+	{R367CAB_EQU_CRL_LD_SEN,          0x85},
+	{R367CAB_EQU_CRL_LD_VAL,          0xe2},
+	{R367CAB_EQU_CRL_TFR,             0x20},
+	{R367CAB_EQU_CRL_BISTH_LO,        0x00},
+	{R367CAB_EQU_CRL_BISTH_HI,        0x00},
+	{R367CAB_EQU_SWEEP_RANGE_LO,      0x00},
+	{R367CAB_EQU_SWEEP_RANGE_HI,      0x00},
+	{R367CAB_EQU_CRL_LIMITER,         0x40},
+	{R367CAB_EQU_MODULUS_MAP,         0x90},
+	{R367CAB_EQU_PNT_GAIN,            0xa7},
+	{R367CAB_FEC_AC_CTR_0,            0x16},
+	{R367CAB_FEC_AC_CTR_1,            0x0b},
+	{R367CAB_FEC_AC_CTR_2,            0x88},
+	{R367CAB_FEC_AC_CTR_3,            0x02},
+	{R367CAB_FEC_STATUS,              0x12},
+	{R367CAB_RS_COUNTER_0,            0x7d},
+	{R367CAB_RS_COUNTER_1,            0xd0},
+	{R367CAB_RS_COUNTER_2,            0x19},
+	{R367CAB_RS_COUNTER_3,            0x0b},
+	{R367CAB_RS_COUNTER_4,            0xa3},
+	{R367CAB_RS_COUNTER_5,            0x00},
+	{R367CAB_BERT_0,                  0x01},
+	{R367CAB_BERT_1,                  0x25},
+	{R367CAB_BERT_2,                  0x41},
+	{R367CAB_BERT_3,                  0x39},
+	{R367CAB_OUTFORMAT_0,             0xc2},
+	{R367CAB_OUTFORMAT_1,             0x22},
+	{R367CAB_SMOOTHER_2,              0x28},
+	{R367CAB_TSMF_CTRL_0,             0x01},
+	{R367CAB_TSMF_CTRL_1,             0xc6},
+	{R367CAB_TSMF_CTRL_3,             0x43},
+	{R367CAB_TS_ON_ID_0,              0x00},
+	{R367CAB_TS_ON_ID_1,              0x00},
+	{R367CAB_TS_ON_ID_2,              0x00},
+	{R367CAB_TS_ON_ID_3,              0x00},
+	{R367CAB_RE_STATUS_0,             0x00},
+	{R367CAB_RE_STATUS_1,             0x00},
+	{R367CAB_RE_STATUS_2,             0x00},
+	{R367CAB_RE_STATUS_3,             0x00},
+	{R367CAB_TS_STATUS_0,             0x00},
+	{R367CAB_TS_STATUS_1,             0x00},
+	{R367CAB_TS_STATUS_2,             0xa0},
+	{R367CAB_TS_STATUS_3,             0x00},
+	{R367CAB_T_O_ID_0,                0x00},
+	{R367CAB_T_O_ID_1,                0x00},
+	{R367CAB_T_O_ID_2,                0x00},
+	{R367CAB_T_O_ID_3,                0x00},
+	{0x0000, 0x00} /* EOT */
+};
+
+static const struct st_register def0367dd_base[] = {
+	{R367TER_IOCFG0,     0x80},
+	{R367TER_DAC0R,      0x00},
+	{R367TER_IOCFG1,     0x00},
+	{R367TER_DAC1R,      0x00},
+	{R367TER_IOCFG2,     0x00},
+	{R367TER_SDFR,       0x00},
+	{R367TER_AUX_CLK,    0x00},
+	{R367TER_FREESYS1,   0x00},
+	{R367TER_FREESYS2,   0x00},
+	{R367TER_FREESYS3,   0x00},
+	{R367TER_GPIO_CFG,   0x55},
+	{R367TER_GPIO_CMD,   0x01},
+	{R367TER_TSTRES,     0x00},
+	{R367TER_ANACTRL,    0x00},
+	{R367TER_TSTBUS,     0x00},
+	{R367TER_RF_AGC2,    0x20},
+	{R367TER_ANADIGCTRL, 0x0b},
+	{R367TER_PLLMDIV,    0x01},
+	{R367TER_PLLNDIV,    0x08},
+	{R367TER_PLLSETUP,   0x18},
+	{R367TER_DUAL_AD12,  0x04},
+	{R367TER_TSTBIST,    0x00},
+	{0x0000, 0x00} /* EOT */
+};
+
 /*
  * Tables combined
  */
@@ -688,6 +1294,8 @@ static const struct
 st_register *stv0367_deftabs[STV0367_DEFTAB_MAX][STV0367_TAB_MAX] = {
 	/* generic default/init tabs */
 	{ def0367ter, def0367cab, NULL },
+	/* default tabs for digital devices cards/flex modules */
+	{ def0367dd_ofdm, def0367dd_qam, def0367dd_base },
 };
 
 #endif
-- 
2.10.2

[PATCH v3 11/13] [media] dvb-frontends/stv0367: add Digital Devices compatibility

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

This - in conjunction with the previous changes - makes it possible to use
the STV0367 DVB-C/T demodulator driver with Digital Devices hardware having
this demodulator soldered on them (namely CineCTv6 bridges and some earlier
DuoFlex CT addon modules).

The changes do the following:

- add a third *_attach function which will make use of a third frontend_ops
  struct which announces both -C and -T support (the same as with DD's own
  driver stv0367dd). This is necessary to support both delivery systems
  on one FE without having to do large conversions to VB2 or the need to
  select either -C or -T mode via modparams and the like. Additionally,
  the frontend_ops point to new "glue" functions which will then call into
  the existing functionality depending on the active delivery system/demod
  state (all used functionality works almost OOTB).
- Demod initialisation has been ported from stv0367dd. DD's driver always
  does a full init of both OFDM and QAM cores, with some additional things.
  The active delivery system is remembered and upon switch, the Demod will
  be reconfigured to work in OFDM or QAM mode (that's what the ddb_setup_XX
  functions are used for). Note that in QAM mode, the DD demods work with
  an IC speed of 58Mhz. It's not very good to perform full reinits upon
  Demod mode changes since in very rare occasions this can lead to the I2C
  interface or the whole Demod to crash, requiring a powercycle, thus the
  flag to perform full reinit is set to disabled.
- A little enum is added for named identifiers of the current Demod state.

Initialisation code/register writes originate from stv0367dd. Permission
to reuse was formally granted by Ralph Metzler <rjkm@metzlerbros.de>.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/dvb-frontends/stv0367.c | 324 ++++++++++++++++++++++++++++++++++
 drivers/media/dvb-frontends/stv0367.h |  10 ++
 2 files changed, 334 insertions(+)

diff --git a/drivers/media/dvb-frontends/stv0367.c b/drivers/media/dvb-frontends/stv0367.c
index ffc046a..e726c2e 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -46,6 +46,8 @@ module_param_named(i2c_debug, i2cdebug, int, 0644);
 	} while (0)
 	/* DVB-C */
 
+enum active_demod_state { demod_none, demod_ter, demod_cab };
+
 struct stv0367cab_state {
 	enum stv0367_cab_signal_type	state;
 	u32	mclk;
@@ -96,6 +98,7 @@ struct stv0367_state {
 	u8 deftabs;
 	u8 reinit_on_setfrontend;
 	u8 auto_if_khz;
+	enum active_demod_state activedemod;
 };
 
 #define RF_LOOKUP_TABLE_SIZE  31
@@ -2880,6 +2883,327 @@ struct dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 }
 EXPORT_SYMBOL(stv0367cab_attach);
 
+/*
+ * Functions for operation on Digital Devices hardware
+ */
+
+static void stv0367ddb_setup_ter(struct stv0367_state *state)
+{
+	stv0367_writereg(state, R367TER_DEBUG_LT4, 0x00);
+	stv0367_writereg(state, R367TER_DEBUG_LT5, 0x00);
+	stv0367_writereg(state, R367TER_DEBUG_LT6, 0x00); /* R367CAB_CTRL_1 */
+	stv0367_writereg(state, R367TER_DEBUG_LT7, 0x00); /* R367CAB_CTRL_2 */
+	stv0367_writereg(state, R367TER_DEBUG_LT8, 0x00);
+	stv0367_writereg(state, R367TER_DEBUG_LT9, 0x00);
+
+	/* Tuner Setup */
+	/* Buffer Q disabled, I Enabled, unsigned ADC */
+	stv0367_writereg(state, R367TER_ANADIGCTRL, 0x89);
+	stv0367_writereg(state, R367TER_DUAL_AD12, 0x04); /* ADCQ disabled */
+
+	/* Clock setup */
+	/* PLL bypassed and disabled */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x0D);
+	stv0367_writereg(state, R367TER_TOPCTRL, 0x00); /* Set OFDM */
+
+	/* IC runs at 54 MHz with a 27 MHz crystal */
+	stv0367_pll_setup(state, STV0367_ICSPEED_53125, state->config->xtal);
+
+	msleep(50);
+	/* PLL enabled and used */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x00);
+
+	state->activedemod = demod_ter;
+}
+
+static void stv0367ddb_setup_cab(struct stv0367_state *state)
+{
+	stv0367_writereg(state, R367TER_DEBUG_LT4, 0x00);
+	stv0367_writereg(state, R367TER_DEBUG_LT5, 0x01);
+	stv0367_writereg(state, R367TER_DEBUG_LT6, 0x06); /* R367CAB_CTRL_1 */
+	stv0367_writereg(state, R367TER_DEBUG_LT7, 0x03); /* R367CAB_CTRL_2 */
+	stv0367_writereg(state, R367TER_DEBUG_LT8, 0x00);
+	stv0367_writereg(state, R367TER_DEBUG_LT9, 0x00);
+
+	/* Tuner Setup */
+	/* Buffer Q disabled, I Enabled, signed ADC */
+	stv0367_writereg(state, R367TER_ANADIGCTRL, 0x8B);
+	/* ADCQ disabled */
+	stv0367_writereg(state, R367TER_DUAL_AD12, 0x04);
+
+	/* Clock setup */
+	/* PLL bypassed and disabled */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x0D);
+	/* Set QAM */
+	stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
+
+	/* IC runs at 58 MHz with a 27 MHz crystal */
+	stv0367_pll_setup(state, STV0367_ICSPEED_58000, state->config->xtal);
+
+	msleep(50);
+	/* PLL enabled and used */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x00);
+
+	state->cab_state->mclk = stv0367cab_get_mclk(&state->fe,
+		state->config->xtal);
+	state->cab_state->adc_clk = stv0367cab_get_adc_freq(&state->fe,
+		state->config->xtal);
+
+	state->activedemod = demod_cab;
+}
+
+static int stv0367ddb_set_frontend(struct dvb_frontend *fe)
+{
+	struct stv0367_state *state = fe->demodulator_priv;
+
+	switch (fe->dtv_property_cache.delivery_system) {
+	case SYS_DVBT:
+		if (state->activedemod != demod_ter)
+			stv0367ddb_setup_ter(state);
+
+		return stv0367ter_set_frontend(fe);
+	case SYS_DVBC_ANNEX_A:
+		if (state->activedemod != demod_cab)
+			stv0367ddb_setup_cab(state);
+
+		/* protect against division error oopses */
+		if (fe->dtv_property_cache.symbol_rate == 0) {
+			printk(KERN_ERR "Invalid symbol rate\n");
+			return -EINVAL;
+		}
+
+		return stv0367cab_set_frontend(fe);
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int stv0367ddb_read_status(struct dvb_frontend *fe,
+				  enum fe_status *status)
+{
+	struct stv0367_state *state = fe->demodulator_priv;
+
+	switch (state->activedemod) {
+	case demod_ter:
+		return stv0367ter_read_status(fe, status);
+	case demod_cab:
+		return stv0367cab_read_status(fe, status);
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int stv0367ddb_get_frontend(struct dvb_frontend *fe,
+				   struct dtv_frontend_properties *p)
+{
+	struct stv0367_state *state = fe->demodulator_priv;
+
+	switch (state->activedemod) {
+	case demod_ter:
+		return stv0367ter_get_frontend(fe, p);
+	case demod_cab:
+		return stv0367cab_get_frontend(fe, p);
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int stv0367ddb_sleep(struct dvb_frontend *fe)
+{
+	struct stv0367_state *state = fe->demodulator_priv;
+
+	switch (state->activedemod) {
+	case demod_ter:
+		state->activedemod = demod_none;
+		return stv0367ter_sleep(fe);
+	case demod_cab:
+		state->activedemod = demod_none;
+		return stv0367cab_sleep(fe);
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int stv0367ddb_init(struct stv0367_state *state)
+{
+	struct stv0367ter_state *ter_state = state->ter_state;
+
+	stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
+
+	if (stv0367_deftabs[state->deftabs][STV0367_TAB_BASE])
+		stv0367_write_table(state,
+			stv0367_deftabs[state->deftabs][STV0367_TAB_BASE]);
+
+	stv0367_write_table(state,
+		stv0367_deftabs[state->deftabs][STV0367_TAB_CAB]);
+
+	stv0367_writereg(state, R367TER_TOPCTRL, 0x00);
+	stv0367_write_table(state,
+		stv0367_deftabs[state->deftabs][STV0367_TAB_TER]);
+
+	stv0367_writereg(state, R367TER_GAIN_SRC1, 0x2A);
+	stv0367_writereg(state, R367TER_GAIN_SRC2, 0xD6);
+	stv0367_writereg(state, R367TER_INC_DEROT1, 0x55);
+	stv0367_writereg(state, R367TER_INC_DEROT2, 0x55);
+	stv0367_writereg(state, R367TER_TRL_CTL, 0x14);
+	stv0367_writereg(state, R367TER_TRL_NOMRATE1, 0xAE);
+	stv0367_writereg(state, R367TER_TRL_NOMRATE2, 0x56);
+	stv0367_writereg(state, R367TER_FEPATH_CFG, 0x0);
+
+	/* OFDM TS Setup */
+
+	stv0367_writereg(state, R367TER_TSCFGH, 0x70);
+	stv0367_writereg(state, R367TER_TSCFGM, 0xC0);
+	stv0367_writereg(state, R367TER_TSCFGL, 0x20);
+	stv0367_writereg(state, R367TER_TSSPEED, 0x40); /* Fixed at 54 MHz */
+
+	stv0367_writereg(state, R367TER_TSCFGH, 0x71);
+	stv0367_writereg(state, R367TER_TSCFGH, 0x70);
+
+	stv0367_writereg(state, R367TER_TOPCTRL, 0x10);
+
+	/* Also needed for QAM */
+	stv0367_writereg(state, R367TER_AGC12C, 0x01); /* AGC Pin setup */
+
+	stv0367_writereg(state, R367TER_AGCCTRL1, 0x8A);
+
+	/* QAM TS setup, note exact format also depends on descrambler */
+	/* settings */
+	/* Inverted Clock, Swap, serial */
+	stv0367_writereg(state, R367CAB_OUTFORMAT_0, 0x85);
+
+	/* Clock setup (PLL bypassed and disabled) */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x0D);
+
+	/* IC runs at 58 MHz with a 27 MHz crystal */
+	stv0367_pll_setup(state, STV0367_ICSPEED_58000, state->config->xtal);
+
+	/* Tuner setup */
+	/* Buffer Q disabled, I Enabled, signed ADC */
+	stv0367_writereg(state, R367TER_ANADIGCTRL, 0x8b);
+	stv0367_writereg(state, R367TER_DUAL_AD12, 0x04); /* ADCQ disabled */
+
+	/* Improves the C/N lock limit */
+	stv0367_writereg(state, R367CAB_FSM_SNR2_HTH, 0x23);
+	/* ZIF/IF Automatic mode */
+	stv0367_writereg(state, R367CAB_IQ_QAM, 0x01);
+	/* Improving burst noise performances */
+	stv0367_writereg(state, R367CAB_EQU_FFE_LEAKAGE, 0x83);
+	/* Improving ACI performances */
+	stv0367_writereg(state, R367CAB_IQDEM_ADJ_EN, 0x05);
+
+	/* PLL enabled and used */
+	stv0367_writereg(state, R367TER_ANACTRL, 0x00);
+
+	stv0367_writereg(state, R367TER_I2CRPT, (0x08 | ((5 & 0x07) << 4)));
+
+	ter_state->pBER = 0;
+	ter_state->first_lock = 0;
+	ter_state->unlock_counter = 2;
+
+	return 0;
+}
+
+static const struct dvb_frontend_ops stv0367ddb_ops = {
+	.delsys = { SYS_DVBC_ANNEX_A, SYS_DVBT },
+	.info = {
+		.name			= "ST STV0367 DDB DVB-C/T",
+		.frequency_min		= 47000000,
+		.frequency_max		= 865000000,
+		.frequency_stepsize	= 166667,
+		.frequency_tolerance	= 0,
+		.symbol_rate_min	= 870000,
+		.symbol_rate_max	= 11700000,
+		.caps = /* DVB-C */
+			0x400 |/* FE_CAN_QAM_4 */
+			FE_CAN_QAM_16 | FE_CAN_QAM_32  |
+			FE_CAN_QAM_64 | FE_CAN_QAM_128 |
+			FE_CAN_QAM_256 | FE_CAN_FEC_AUTO |
+			/* DVB-T */
+			FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 |
+			FE_CAN_FEC_3_4 | FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 |
+			FE_CAN_FEC_AUTO |
+			FE_CAN_QPSK | FE_CAN_QAM_16 | FE_CAN_QAM_64 |
+			FE_CAN_QAM_128 | FE_CAN_QAM_256 | FE_CAN_QAM_AUTO |
+			FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_RECOVER |
+			FE_CAN_INVERSION_AUTO |
+			FE_CAN_MUTE_TS
+	},
+	.release = stv0367_release,
+	.sleep = stv0367ddb_sleep,
+	.i2c_gate_ctrl = stv0367cab_gate_ctrl, /* valid for TER and CAB */
+	.set_frontend = stv0367ddb_set_frontend,
+	.get_frontend = stv0367ddb_get_frontend,
+	.get_tune_settings = stv0367_get_tune_settings,
+	.read_status = stv0367ddb_read_status,
+};
+
+struct dvb_frontend *stv0367ddb_attach(const struct stv0367_config *config,
+				   struct i2c_adapter *i2c)
+{
+	struct stv0367_state *state = NULL;
+	struct stv0367ter_state *ter_state = NULL;
+	struct stv0367cab_state *cab_state = NULL;
+
+	/* allocate memory for the internal state */
+	state = kzalloc(sizeof(struct stv0367_state), GFP_KERNEL);
+	if (state == NULL)
+		goto error;
+	ter_state = kzalloc(sizeof(struct stv0367ter_state), GFP_KERNEL);
+	if (ter_state == NULL)
+		goto error;
+	cab_state = kzalloc(sizeof(struct stv0367cab_state), GFP_KERNEL);
+	if (cab_state == NULL)
+		goto error;
+
+	/* setup the state */
+	state->i2c = i2c;
+	state->config = config;
+	state->ter_state = ter_state;
+	cab_state->search_range = 280000;
+	cab_state->qamfec_status_reg = F367CAB_DESCR_SYNCSTATE;
+	state->cab_state = cab_state;
+	state->fe.ops = stv0367ddb_ops;
+	state->fe.demodulator_priv = state;
+	state->chip_id = stv0367_readreg(state, R367TER_ID);
+
+	/* demod operation options */
+	state->use_i2c_gatectrl = 0;
+	state->deftabs = STV0367_DEFTAB_DDB;
+	state->reinit_on_setfrontend = 0;
+	state->auto_if_khz = 1;
+	state->activedemod = demod_none;
+
+	dprintk("%s: chip_id = 0x%x\n", __func__, state->chip_id);
+
+	/* check if the demod is there */
+	if ((state->chip_id != 0x50) && (state->chip_id != 0x60))
+		goto error;
+
+	dev_info(&i2c->dev, "Found %s with ChipID %02X at adr %02X\n",
+		state->fe.ops.info.name, state->chip_id,
+		config->demod_address);
+
+	stv0367ddb_init(state);
+
+	return &state->fe;
+
+error:
+	kfree(cab_state);
+	kfree(ter_state);
+	kfree(state);
+	return NULL;
+}
+EXPORT_SYMBOL(stv0367ddb_attach);
+
 MODULE_PARM_DESC(debug, "Set debug");
 MODULE_PARM_DESC(i2c_debug, "Set i2c debug");
 
diff --git a/drivers/media/dvb-frontends/stv0367.h b/drivers/media/dvb-frontends/stv0367.h
index aaa0236..8f7a314 100644
--- a/drivers/media/dvb-frontends/stv0367.h
+++ b/drivers/media/dvb-frontends/stv0367.h
@@ -44,6 +44,9 @@ dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
 extern struct
 dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 					struct i2c_adapter *i2c);
+extern struct
+dvb_frontend *stv0367ddb_attach(const struct stv0367_config *config,
+					struct i2c_adapter *i2c);
 #else
 static inline struct
 dvb_frontend *stv0367ter_attach(const struct stv0367_config *config,
@@ -59,6 +62,13 @@ dvb_frontend *stv0367cab_attach(const struct stv0367_config *config,
 	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
 	return NULL;
 }
+static inline struct
+dvb_frontend *stv0367ddb_attach(const struct stv0367_config *config,
+					struct i2c_adapter *i2c)
+{
+	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
+	return NULL;
+}
 #endif
 
 #endif
-- 
2.10.2

[PATCH v3 12/13] [media] ddbridge: add i2c_read_regs()

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

Adds new i2c_read_regs() function and make i2c_read_reg() wrap into this
with len=1. Required for the tuner_tda18212_ping() and XO2 handling
functions (part of the Sony CXD28xx support patch series).

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c b/drivers/media/pci/ddbridge/ddbridge-core.c
index 340cff0..acb9cbe 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -54,15 +54,21 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
 	return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
 }
 
-static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
+static int i2c_read_regs(struct i2c_adapter *adapter,
+			 u8 adr, u8 reg, u8 *val, u8 len)
 {
 	struct i2c_msg msgs[2] = {{.addr = adr,  .flags = 0,
 				   .buf  = &reg, .len   = 1 },
 				  {.addr = adr,  .flags = I2C_M_RD,
-				   .buf  = val,  .len   = 1 } };
+				   .buf  = val,  .len   = len } };
 	return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
 }
 
+static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
+{
+	return i2c_read_regs(adapter, adr, reg, val, 1);
+}
+
 static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
 			  u16 reg, u8 *val)
 {
-- 
2.10.2

[PATCH v3 13/13] [media] ddbridge: support STV0367-based cards and modules

[Daniel Scheller]

From: Daniel Scheller <d.scheller@gmx.net>

This adds detection and activation for STV0367-based tuner hardware (namely
CineCTv6 bridge cards and older DuoFlex CT addon modules). Utilises the
extended stv0367 demod driver.

TDA18212 i2c_client/regmap-api code was originally implemented by
Antti Palosaari <crope@iki.fi> in a variant to update the ddbridge code
from the vendor dddvb package (formal ack for these parts received).
Original patch at [1].

When boards with STV0367 are cold-started, there might be issues with the
I2C gate, causing the TDA18212 detection/probe to fail. For these demods,
a workaround (tuner_tda18212_ping) is implemented which probes the tuner
twice on this hardware constellation which will resolve the problem and
put all components into a working state. Other demod/port types won't be
retried.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>

[1] https://patchwork.linuxtv.org/patch/25146/
---
 drivers/media/pci/ddbridge/Kconfig         |   3 +
 drivers/media/pci/ddbridge/ddbridge-core.c | 158 ++++++++++++++++++++++++++++-
 drivers/media/pci/ddbridge/ddbridge.h      |   1 +
 3 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/ddbridge/Kconfig b/drivers/media/pci/ddbridge/Kconfig
index 44e5dc1..16ede23 100644
--- a/drivers/media/pci/ddbridge/Kconfig
+++ b/drivers/media/pci/ddbridge/Kconfig
@@ -6,6 +6,8 @@ config DVB_DDBRIDGE
 	select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT
 	select DVB_DRXK if MEDIA_SUBDRV_AUTOSELECT
 	select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
+	select DVB_STV0367 if MEDIA_SUBDRV_AUTOSELECT
+	select MEDIA_TUNER_TDA18212 if MEDIA_SUBDRV_AUTOSELECT
 	---help---
 	  Support for cards with the Digital Devices PCI express bridge:
 	  - Octopus PCIe Bridge
@@ -14,5 +16,6 @@ config DVB_DDBRIDGE
 	  - DuoFlex S2 Octopus
 	  - DuoFlex CT Octopus
 	  - cineS2(v6)
+	  - CineCTv6 and DuoFlex CT (STV0367-based)
 
 	  Say Y if you own such a card and want to use it.
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c b/drivers/media/pci/ddbridge/ddbridge-core.c
index acb9cbe..12f5aa3 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -39,6 +39,9 @@
 #include "stv090x.h"
 #include "lnbh24.h"
 #include "drxk.h"
+#include "stv0367.h"
+#include "stv0367_priv.h"
+#include "tda18212.h"
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
@@ -615,6 +618,120 @@ static int tuner_attach_tda18271(struct ddb_input *input)
 /******************************************************************************/
 /******************************************************************************/
 
+static struct stv0367_config ddb_stv0367_config[] = {
+	{
+		.demod_address = 0x1f,
+		.xtal = 27000000,
+		.if_khz = 0,
+		.if_iq_mode = FE_TER_NORMAL_IF_TUNER,
+		.ts_mode = STV0367_SERIAL_PUNCT_CLOCK,
+		.clk_pol = STV0367_CLOCKPOLARITY_DEFAULT,
+	}, {
+		.demod_address = 0x1e,
+		.xtal = 27000000,
+		.if_khz = 0,
+		.if_iq_mode = FE_TER_NORMAL_IF_TUNER,
+		.ts_mode = STV0367_SERIAL_PUNCT_CLOCK,
+		.clk_pol = STV0367_CLOCKPOLARITY_DEFAULT,
+	},
+};
+
+static int demod_attach_stv0367(struct ddb_input *input)
+{
+	struct i2c_adapter *i2c = &input->port->i2c->adap;
+
+	/* attach frontend */
+	input->fe = dvb_attach(stv0367ddb_attach,
+		&ddb_stv0367_config[(input->nr & 1)], i2c);
+
+	if (!input->fe) {
+		printk(KERN_ERR "stv0367ddb_attach failed (not found?)\n");
+		return -ENODEV;
+	}
+
+	input->fe->sec_priv = input;
+	input->gate_ctrl = input->fe->ops.i2c_gate_ctrl;
+	input->fe->ops.i2c_gate_ctrl = drxk_gate_ctrl;
+
+	return 0;
+}
+
+static int tuner_tda18212_ping(struct ddb_input *input, unsigned short adr)
+{
+	struct i2c_adapter *adapter = &input->port->i2c->adap;
+	u8 tda_id[2];
+	u8 subaddr = 0x00;
+
+	printk(KERN_DEBUG "stv0367-tda18212 tuner ping\n");
+	if (input->fe->ops.i2c_gate_ctrl)
+		input->fe->ops.i2c_gate_ctrl(input->fe, 1);
+
+	if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
+		printk(KERN_DEBUG "tda18212 ping 1 fail\n");
+	if (i2c_read_regs(adapter, adr, subaddr, tda_id, sizeof(tda_id)) < 0)
+		printk(KERN_DEBUG "tda18212 ping 2 fail\n");
+
+	if (input->fe->ops.i2c_gate_ctrl)
+		input->fe->ops.i2c_gate_ctrl(input->fe, 0);
+
+	return 0;
+}
+
+static int tuner_attach_tda18212(struct ddb_input *input, u32 porttype)
+{
+	struct i2c_adapter *adapter = &input->port->i2c->adap;
+	struct i2c_client *client;
+	struct tda18212_config config = {
+		.fe = input->fe,
+		.if_dvbt_6 = 3550,
+		.if_dvbt_7 = 3700,
+		.if_dvbt_8 = 4150,
+		.if_dvbt2_6 = 3250,
+		.if_dvbt2_7 = 4000,
+		.if_dvbt2_8 = 4000,
+		.if_dvbc = 5000,
+	};
+	struct i2c_board_info board_info = {
+		.type = "tda18212",
+		.platform_data = &config,
+	};
+
+	if (input->nr & 1)
+		board_info.addr = 0x63;
+	else
+		board_info.addr = 0x60;
+
+	/* due to a hardware quirk with the I2C gate on the stv0367+tda18212
+	 * combo, the tda18212 must be probed by reading it's id _twice_ when
+	 * cold started, or it very likely will fail.
+	 */
+	if (porttype == DDB_TUNER_DVBCT_ST)
+		tuner_tda18212_ping(input, board_info.addr);
+
+	request_module(board_info.type);
+
+	/* perform tuner init/attach */
+	client = i2c_new_device(adapter, &board_info);
+	if (client == NULL || client->dev.driver == NULL)
+		goto err;
+
+	if (!try_module_get(client->dev.driver->owner)) {
+		i2c_unregister_device(client);
+		goto err;
+	}
+
+	input->i2c_client[0] = client;
+
+	return 0;
+err:
+	printk(KERN_INFO "TDA18212 tuner not found. Device is not fully operational.\n");
+	return -ENODEV;
+}
+
+/******************************************************************************/
+/******************************************************************************/
+/******************************************************************************/
+
 static struct stv090x_config stv0900 = {
 	.device         = STV0900,
 	.demod_mode     = STV090x_DUAL,
@@ -785,11 +902,19 @@ static void dvb_input_detach(struct ddb_input *input)
 {
 	struct dvb_adapter *adap = &input->adap;
 	struct dvb_demux *dvbdemux = &input->demux;
+	struct i2c_client *client;
 
 	switch (input->attached) {
 	case 5:
-		if (input->fe2)
+		client = input->i2c_client[0];
+		if (client) {
+			module_put(client->dev.driver->owner);
+			i2c_unregister_device(client);
+		}
+		if (input->fe2) {
 			dvb_unregister_frontend(input->fe2);
+			input->fe2 = NULL;
+		}
 		if (input->fe) {
 			dvb_unregister_frontend(input->fe);
 			dvb_frontend_detach(input->fe);
@@ -888,7 +1013,18 @@ static int dvb_input_attach(struct ddb_input *input)
 			       sizeof(struct dvb_tuner_ops));
 		}
 		break;
+	case DDB_TUNER_DVBCT_ST:
+		if (demod_attach_stv0367(input) < 0)
+			return -ENODEV;
+		if (tuner_attach_tda18212(input, port->type) < 0)
+			return -ENODEV;
+		if (input->fe) {
+			if (dvb_register_frontend(adap, input->fe) < 0)
+				return -ENODEV;
+		}
+		break;
 	}
+
 	input->attached = 5;
 	return 0;
 }
@@ -1168,6 +1304,20 @@ static int port_has_drxks(struct ddb_port *port)
 	return 1;
 }
 
+static int port_has_stv0367(struct ddb_port *port)
+{
+	u8 val;
+	if (i2c_read_reg16(&port->i2c->adap, 0x1e, 0xf000, &val) < 0)
+		return 0;
+	if (val != 0x60)
+		return 0;
+	if (i2c_read_reg16(&port->i2c->adap, 0x1f, 0xf000, &val) < 0)
+		return 0;
+	if (val != 0x60)
+		return 0;
+	return 1;
+}
+
 static void ddb_port_probe(struct ddb_port *port)
 {
 	struct ddb *dev = port->dev;
@@ -1194,7 +1344,13 @@ static void ddb_port_probe(struct ddb_port *port)
 		port->class = DDB_PORT_TUNER;
 		port->type = DDB_TUNER_DVBCT_TR;
 		ddbwritel(I2C_SPEED_400, port->i2c->regs + I2C_TIMING);
+	} else if (port_has_stv0367(port)) {
+		modname = "DUAL DVB-C/T";
+		port->class = DDB_PORT_TUNER;
+		port->type = DDB_TUNER_DVBCT_ST;
+		ddbwritel(I2C_SPEED_100, port->i2c->regs + I2C_TIMING);
 	}
+
 	printk(KERN_INFO "Port %d (TAB %d): %s\n",
 			 port->nr, port->nr+1, modname);
 }
diff --git a/drivers/media/pci/ddbridge/ddbridge.h b/drivers/media/pci/ddbridge/ddbridge.h
index 185b423..0898f60 100644
--- a/drivers/media/pci/ddbridge/ddbridge.h
+++ b/drivers/media/pci/ddbridge/ddbridge.h
@@ -86,6 +86,7 @@ struct ddb_input {
 
 	struct dvb_adapter     adap;
 	struct dvb_device     *dev;
+	struct i2c_client     *i2c_client[1];
 	struct dvb_frontend   *fe;
 	struct dvb_frontend   *fe2;
 	struct dmxdev          dmxdev;
-- 
2.10.2

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Wed, 29 Mar 2017 18:43:00 +0200
schrieb Daniel Scheller <d.scheller.oss@gmail.com>:

> From: Daniel Scheller <d.scheller@gmx.net>
> 
> Third iteration of the DD CineCTv6/FlexCT support patches with mostly
> all things cleaned up that popped up so far. Obsoletes V1 and V2
> series.
> 
> These patches enhance the functionality of dvb-frontends/stv0367 to
> work with Digital Devices hardware driven by the ST STV0367
> demodulator chip and adds probe & attach bits to ddbridge to make use
> of them, effectively enabling full support for CineCTv6 PCIe bridges
> and (older) DuoFlex CT addon modules.

Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like to
get this upstreamed.

Regards,
Daniel

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Wed, 12 Apr 2017 21:23:27 +0200
schrieb Daniel Scheller <d.scheller.oss@gmail.com>:

> Am Wed, 29 Mar 2017 18:43:00 +0200
> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> 
> > From: Daniel Scheller <d.scheller@gmx.net>
> > 
> > Third iteration of the DD CineCTv6/FlexCT support patches with
> > mostly all things cleaned up that popped up so far. Obsoletes V1
> > and V2 series.
> > 
> > These patches enhance the functionality of dvb-frontends/stv0367 to
> > work with Digital Devices hardware driven by the ST STV0367
> > demodulator chip and adds probe & attach bits to ddbridge to make
> > use of them, effectively enabling full support for CineCTv6 PCIe
> > bridges and (older) DuoFlex CT addon modules.  
> 
> Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like
> to get this upstreamed.

Don't want to sound impatient, but V1 nears nine weeks, so: Second Ping.

From what I can see, the two affected drivers aren't (at least)
actively maintained anymore, or maintainers may be MIA. So: Mauro, mind
having a look if you've got some spare time?

Thanks & best regards,
Daniel

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Sun, 7 May 2017 17:42:12 +0200
schrieb Daniel Scheller <d.scheller.oss@gmail.com>:

> Am Wed, 12 Apr 2017 21:23:27 +0200
> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> 
> > Am Wed, 29 Mar 2017 18:43:00 +0200
> > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> >   
> > > From: Daniel Scheller <d.scheller@gmx.net>
> > > 
> > > Third iteration of the DD CineCTv6/FlexCT support patches with
> > > mostly all things cleaned up that popped up so far. Obsoletes V1
> > > and V2 series.
> > > 
> > > These patches enhance the functionality of dvb-frontends/stv0367
> > > to work with Digital Devices hardware driven by the ST STV0367
> > > demodulator chip and adds probe & attach bits to ddbridge to make
> > > use of them, effectively enabling full support for CineCTv6 PCIe
> > > bridges and (older) DuoFlex CT addon modules.    
> > 
> > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really like
> > to get this upstreamed.  
> 
> Don't want to sound impatient, but V1 nears nine weeks, so: Second
> Ping.

Friendly third time Ping on this - Really, I'd like to have this
merged so those quite aging (but still fine) DD CineCTv6 boards
finally are supported without having to install out-of-tree drivers
which even break the V4L-DVB subsystem...

Thanks & regards,
Daniel

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Daniel Scheller]

Am Sun, 28 May 2017 23:45:37 +0200
schrieb Daniel Scheller <d.scheller.oss@gmail.com>:

> Am Sun, 7 May 2017 17:42:12 +0200
> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> 
> > Am Wed, 12 Apr 2017 21:23:27 +0200
> > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> >   
> > > Am Wed, 29 Mar 2017 18:43:00 +0200
> > > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> > >     
> > > > From: Daniel Scheller <d.scheller@gmx.net>
> > > > 
> > > > Third iteration of the DD CineCTv6/FlexCT support patches with
> > > > mostly all things cleaned up that popped up so far. Obsoletes V1
> > > > and V2 series.
> > > > 
> > > > These patches enhance the functionality of dvb-frontends/stv0367
> > > > to work with Digital Devices hardware driven by the ST STV0367
> > > > demodulator chip and adds probe & attach bits to ddbridge to
> > > > make use of them, effectively enabling full support for
> > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon
> > > > modules.      
> > > 
> > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
> > > like to get this upstreamed.    
> > 
> > Don't want to sound impatient, but V1 nears nine weeks, so: Second
> > Ping.  
> 
> Friendly third time Ping on this - Really, I'd like to have this
> merged so those quite aging (but still fine) DD CineCTv6 boards
> finally are supported without having to install out-of-tree drivers
> which even break the V4L-DVB subsystem...

Well. From how things look, these and the cxd2841er+C2T2 ddbridge
support patches won't make it in time for the 4.13 merge window.
Also, unfortunately, the original owners and/or maintainers of the
affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
either are MIA or not interested in reviewing or acking this.

I have plenty of more work (patches) done, all building upon this CT
and C2T2 hardware support, which - together with the work Jasmin has
done regarding the en50221 and cxd2099 support - would finally bring
the in-tree ddbridge driver on par with the package Digital Devices'
provides, having addressed most of the critics the previous attempts to
bump the driver received (incremental changes which are more or less
easy to review, from what can be done by tearing tarballs without
proper changelogs apart).

The original series of this will be four(!) months old soon :/

Is there anything wrong with this? How to proceed with this?

(Cc Hans since you also seem to be reviewing patches)

That said, fourth ping.

Best regards,
Daniel Scheller

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Jasmin J.]

Hello !

On 06/19/2017 10:18 PM, Daniel Scheller wrote:
> Am Sun, 28 May 2017 23:45:37 +0200
> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> 
>> Am Sun, 7 May 2017 17:42:12 +0200
>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>
>>> Am Wed, 12 Apr 2017 21:23:27 +0200
>>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>>   
>>>> Am Wed, 29 Mar 2017 18:43:00 +0200
>>>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>>>     
>>>>> From: Daniel Scheller <d.scheller@gmx.net>
>>>>>
>>>>> Third iteration of the DD CineCTv6/FlexCT support patches with
>>>>> mostly all things cleaned up that popped up so far. Obsoletes V1
>>>>> and V2 series.
>>>>>
>>>>> These patches enhance the functionality of dvb-frontends/stv0367
>>>>> to work with Digital Devices hardware driven by the ST STV0367
>>>>> demodulator chip and adds probe & attach bits to ddbridge to
>>>>> make use of them, effectively enabling full support for
>>>>> CineCTv6 PCIe bridges and (older) DuoFlex CT addon
>>>>> modules.      
>>>>
>>>> Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
>>>> like to get this upstreamed.    
>>>
>>> Don't want to sound impatient, but V1 nears nine weeks, so: Second
>>> Ping.  
>>
>> Friendly third time Ping on this - Really, I'd like to have this
>> merged so those quite aging (but still fine) DD CineCTv6 boards
>> finally are supported without having to install out-of-tree drivers
>> which even break the V4L-DVB subsystem...
> 
> Well. From how things look, these and the cxd2841er+C2T2 ddbridge
> support patches won't make it in time for the 4.13 merge window.
> Also, unfortunately, the original owners and/or maintainers of the
> affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
> either are MIA or not interested in reviewing or acking this.
> 
> I have plenty of more work (patches) done, all building upon this CT
> and C2T2 hardware support, which - together with the work Jasmin has
> done regarding the en50221 and cxd2099 support - would finally bring
> the in-tree ddbridge driver on par with the package Digital Devices'
> provides, having addressed most of the critics the previous attempts to
> bump the driver received (incremental changes which are more or less
> easy to review, from what can be done by tearing tarballs without
> proper changelogs apart).
> 
> The original series of this will be four(!) months old soon :/
> 
> Is there anything wrong with this? How to proceed with this?
> 
> (Cc Hans since you also seem to be reviewing patches)
> 
> That said, fourth ping.

May I add another aspect.
Daniel put a lot of effort into this and also other people in testing his
drivers. Daniel was highly motivated to bring this driver into the Kernel.

That sayd, waiting 4 months is pretty frustrating and might reduce the
motivation to continue.

There are 7 more patch series waiting to review and when each of then requires
4 or more months to get into the Kernel, the project is dead before it really
started!

The community using the DD cards is growing and it is often frustrating using
the drivers provided by DD, when you plan to use other cards too, because
the DD drivers are simply not compatible.
Daniel made them working within the current media tree and a lot of people
(including me) would be very happy to see the DD cards supported out of the
box by the Kernel. Hopefully before the Kernel 5.x development hast started.

I hope there will be soon a review of this series, so that we can move forward
with our work!

BR,
   Jasmin

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Thomas Kaiser]

On 20.06.2017 00:14, Jasmin J. wrote:
> Hello !
> 
> On 06/19/2017 10:18 PM, Daniel Scheller wrote:
>> Am Sun, 28 May 2017 23:45:37 +0200
>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>
>>> Am Sun, 7 May 2017 17:42:12 +0200
>>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>>
>>>> Am Wed, 12 Apr 2017 21:23:27 +0200
>>>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>>>    
>>>>> Am Wed, 29 Mar 2017 18:43:00 +0200
>>>>> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
>>>>>      
>>>>>> From: Daniel Scheller <d.scheller@gmx.net>
>>>>>>
>>>>>> Third iteration of the DD CineCTv6/FlexCT support patches with
>>>>>> mostly all things cleaned up that popped up so far. Obsoletes V1
>>>>>> and V2 series.
>>>>>>
>>>>>> These patches enhance the functionality of dvb-frontends/stv0367
>>>>>> to work with Digital Devices hardware driven by the ST STV0367
>>>>>> demodulator chip and adds probe & attach bits to ddbridge to
>>>>>> make use of them, effectively enabling full support for
>>>>>> CineCTv6 PCIe bridges and (older) DuoFlex CT addon
>>>>>> modules.
>>>>>
>>>>> Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
>>>>> like to get this upstreamed.
>>>>
>>>> Don't want to sound impatient, but V1 nears nine weeks, so: Second
>>>> Ping.
>>>
>>> Friendly third time Ping on this - Really, I'd like to have this
>>> merged so those quite aging (but still fine) DD CineCTv6 boards
>>> finally are supported without having to install out-of-tree drivers
>>> which even break the V4L-DVB subsystem...
>>
>> Well. From how things look, these and the cxd2841er+C2T2 ddbridge
>> support patches won't make it in time for the 4.13 merge window.
>> Also, unfortunately, the original owners and/or maintainers of the
>> affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
>> either are MIA or not interested in reviewing or acking this.
>>
>> I have plenty of more work (patches) done, all building upon this CT
>> and C2T2 hardware support, which - together with the work Jasmin has
>> done regarding the en50221 and cxd2099 support - would finally bring
>> the in-tree ddbridge driver on par with the package Digital Devices'
>> provides, having addressed most of the critics the previous attempts to
>> bump the driver received (incremental changes which are more or less
>> easy to review, from what can be done by tearing tarballs without
>> proper changelogs apart).
>>
>> The original series of this will be four(!) months old soon :/
>>
>> Is there anything wrong with this? How to proceed with this?
>>
>> (Cc Hans since you also seem to be reviewing patches)
>>
>> That said, fourth ping.
> 
> May I add another aspect.
> Daniel put a lot of effort into this and also other people in testing his
> drivers. Daniel was highly motivated to bring this driver into the Kernel.
> 
> That sayd, waiting 4 months is pretty frustrating and might reduce the
> motivation to continue.
> 
> There are 7 more patch series waiting to review and when each of then requires
> 4 or more months to get into the Kernel, the project is dead before it really
> started!
> 
> The community using the DD cards is growing and it is often frustrating using
> the drivers provided by DD, when you plan to use other cards too, because
> the DD drivers are simply not compatible.
> Daniel made them working within the current media tree and a lot of people
> (including me) would be very happy to see the DD cards supported out of the
> box by the Kernel. Hopefully before the Kernel 5.x development hast started.
> 
> I hope there will be soon a review of this series, so that we can move forward
> with our work!
> 
> BR,
>     Jasmin
> 

Hello Reviewers

Me too, I would be very happy to see this driver included in the kernel.

Regards,

Thomas

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Mauro Carvalho Chehab]

Em Mon, 19 Jun 2017 22:18:21 +0200
Daniel Scheller <d.scheller.oss@gmail.com> escreveu:

> Am Sun, 28 May 2017 23:45:37 +0200
> schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> 
> > Am Sun, 7 May 2017 17:42:12 +0200
> > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> >   
> > > Am Wed, 12 Apr 2017 21:23:27 +0200
> > > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> > >     
> > > > Am Wed, 29 Mar 2017 18:43:00 +0200
> > > > schrieb Daniel Scheller <d.scheller.oss@gmail.com>:
> > > >       
> > > > > From: Daniel Scheller <d.scheller@gmx.net>
> > > > > 
> > > > > Third iteration of the DD CineCTv6/FlexCT support patches with
> > > > > mostly all things cleaned up that popped up so far. Obsoletes V1
> > > > > and V2 series.
> > > > > 
> > > > > These patches enhance the functionality of dvb-frontends/stv0367
> > > > > to work with Digital Devices hardware driven by the ST STV0367
> > > > > demodulator chip and adds probe & attach bits to ddbridge to
> > > > > make use of them, effectively enabling full support for
> > > > > CineCTv6 PCIe bridges and (older) DuoFlex CT addon
> > > > > modules.        
> > > > 
> > > > Since V1 was sent over five weeks ago: Ping? Anyone? I'd really
> > > > like to get this upstreamed.      
> > > 
> > > Don't want to sound impatient, but V1 nears nine weeks, so: Second
> > > Ping.    
> > 
> > Friendly third time Ping on this - Really, I'd like to have this
> > merged so those quite aging (but still fine) DD CineCTv6 boards
> > finally are supported without having to install out-of-tree drivers
> > which even break the V4L-DVB subsystem...  
> 
> Well. From how things look, these and the cxd2841er+C2T2 ddbridge
> support patches won't make it in time for the 4.13 merge window.

There is time. I just merged this series today.

The thing is that we currently have few developers working on
DVB, and no sub-maintainers. Due to that, I need to review
them myself, with I usually do after reviewing/applying patches
from sub-maintainers.

> Also, unfortunately, the original owners and/or maintainers of the
> affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
> either are MIA or not interested in reviewing or acking this.

Yeah, it would be great if Ralph would have some time to review
them, or to submit a new series adding all pending features from
DD drivers upstream.

> I have plenty of more work (patches) done, all building upon this CT
> and C2T2 hardware support, which - together with the work Jasmin has
> done regarding the en50221 and cxd2099 support - would finally bring
> the in-tree ddbridge driver on par with the package Digital Devices'
> provides, having addressed most of the critics the previous attempts to
> bump the driver received (incremental changes which are more or less
> easy to review, from what can be done by tearing tarballs without
> proper changelogs apart).

Both Jasmin and Thomas could have reviewed it, and replied
if they tested it, and on what conditions. I tend to give
people some time to review/test patches, before doing my
review, as I don't usually have time for testing everything
myself.

> 
> The original series of this will be four(!) months old soon :/
> 
> Is there anything wrong with this? How to proceed with this?
> 
> (Cc Hans since you also seem to be reviewing patches)

Hans is focused at V4L2 side.

> 
> That said, fourth ping.

Btw, while you're here, it would be great if you could take
a look on those warnings (that comes via smatch):

	drivers/media/pci/ddbridge/ddbridge-core.c:1009 input_tasklet() warn: this loop depends on readl() succeeding
	drivers/media/pci/ddbridge/ddbridge-core.c:1353 flashio() warn: this loop depends on readl() succeeding
	drivers/media/pci/ddbridge/ddbridge-core.c:1373 flashio() warn: this loop depends on readl() succeeding

Regards,
Mauro

DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Am Tue, 20 Jun 2017 09:36:45 -0300
schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

Hi Mauro,

> Em Mon, 19 Jun 2017 22:18:21 +0200
> Daniel Scheller <d.scheller.oss@gmail.com> escreveu:
> 
> > Well. From how things look, these and the cxd2841er+C2T2 ddbridge
> > support patches won't make it in time for the 4.13 merge window.  
> 
> There is time. I just merged this series today.

Oh. Well, this, together with the other series, came as a (quite
positive) surprise this morning - thank you very very much!

> The thing is that we currently have few developers working on
> DVB, and no sub-maintainers. Due to that, I need to review
> them myself, with I usually do after reviewing/applying patches
> from sub-maintainers.

Understood. Though, and please don't get me wrong - Tearing apart and
under how things in the driver, the vendor driver package, the media and
DVB subsystem aswell as kernel parts, additionally aligning the
patches/commits with all remarks from previous submissions in mind took
quite some spare time for more than a year now, getting no responses at
all honestly started to get frustrating.

> > Also, unfortunately, the original owners and/or maintainers of the
> > affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
> > either are MIA or not interested in reviewing or acking this.  
> 
> Yeah, it would be great if Ralph would have some time to review
> them, or to submit a new series adding all pending features from
> DD drivers upstream.

This would of course be the way to go. OTOH, the in-kernel driver
already diverged quite a lot to that what DD publishes and maintains,
and lots of people agree this situation must be improved.

> > I have plenty of more work (patches) done, all building upon this CT
> > and C2T2 hardware support, which - together with the work Jasmin has
> > done regarding the en50221 and cxd2099 support - would finally bring
> > the in-tree ddbridge driver on par with the package Digital Devices'
> > provides, having addressed most of the critics the previous
> > attempts to bump the driver received (incremental changes which are
> > more or less easy to review, from what can be done by tearing
> > tarballs without proper changelogs apart).  
> 
> Both Jasmin and Thomas could have reviewed it, and replied
> if they tested it, and on what conditions. I tend to give
> people some time to review/test patches, before doing my
> review, as I don't usually have time for testing everything
> myself.

Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses
such cards. However, for upcoming patches, I'll try to drag people to
the list for some comments, thanks for the pointer.

Speaking of patches and pending features (and generally syncing
drivers), this is what I plan to send to the list (in order, mostly
depending on each other):

- Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
  cards/modules. This mainly involves a new demod driver (stv0910) and
  a new tuner driver (stv6111). Permissions for this are cleared with
  Ralph already. The glue code needed in ddbridge is rather easy, and
  as some ground work (mostly the MachXO2 support from the 2841 series)
  is now in, the changes are quite small. Patches are ready so far but
  need more cleanup (checkpatch fixes, camel case and such things).

- The "big" ddbridge update. I'm thinking of two ways to do this:

  * Do this in one commit, being a huge code bump, bringing ddbridge to
    version 0.9.28 (as per vendor versioning). This is mostly ready and
    successful in use by many testers and in my Gentoo ddbridge kernel
    sources overlay. Should get some more cleanups though (still some
    GTL link bits left which are not needed), and all fixes which went
    to the in-kernel driver like __user annotations need to be put back
    in. Big drawback: A mess to review.

  * Try to tear apart most if not all upstream vendor driver tar
    archives and recreate individual patches out of this. For
    reference, we need to go from what is in the kernel which is
    something inbetween v0.5 and v0.8 up to and including version
    0.9.29. I'm currently working on this from time to time, and I can
    assure you that this is an extremely tedious and unthankful thing
    to do (currently nearly done with 0.9.9b, approx. 20 releases
    left). This might be better to review, but this will also result in
    something like 100-200 commits, without guarantee of having
    everything correct.

  Reviewers will hate me for this, but I'd personally prefer the first
  option (less work, verified working on quite some installs, less
  clutter in GIT, but the drawback of reviewability).

- Last bit: DD MaxS4/S8 support. Requires another new demod driver
  (mxl5xx) and some more bits (not only glue code, but also some
  operation mode control and LNB handling) in ddbridge. Least work went
  into this so far an the mxl5xx driver code needs quite some cleanup.

Note on the ddbridge update: This is mostly code refactoring and
reorganisation, and feature-wise this is MSI interrupt and DD CI
Single/Duo Bridge support. The vendor package also carries support for
their OctoNET SATIP boxes and the DVB-C modulator support, which I
intentionally leave out. Both features require quite some DVB core API
changes which I can't argue on, but everything should be fairly easy to
add back in if desired (that said, I didn't meet anyone with such a
modulator card in the wild yet...)

If you like, I'm happy and very open to discuss this further with you!

> > (Cc Hans since you also seem to be reviewing patches)  
> 
> Hans is focused at V4L2 side.

Wasn't aware of this, sorry.

> Btw, while you're here, it would be great if you could take
> a look on those warnings (that comes via smatch):
> 
> 	drivers/media/pci/ddbridge/ddbridge-core.c:1009
> input_tasklet() warn: this loop depends on readl() succeeding
> drivers/media/pci/ddbridge/ddbridge-core.c:1353 flashio() warn: this
> loop depends on readl() succeeding
> drivers/media/pci/ddbridge/ddbridge-core.c:1373 flashio() warn: this
> loop depends on readl() succeeding

Sure, will take a peek on this.

BTW, you might have seen this - I posted four more patches which'll add
DVBv5 signal stats to the DDB part of the stv0367 code. If you don't
mind doing a quick inbetween-review of this, this would be nice if this
could go in alongside the DD support (so, for 4.13 aswell).

Thanks & best regards,
Daniel Scheller

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Tue, 20 Jun 2017 20:41:21 +0200
Daniel Scheller <d.scheller.oss@gmail.com> escreveu:

> Am Tue, 20 Jun 2017 09:36:45 -0300
> schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> 
> Hi Mauro,
> 
> > Em Mon, 19 Jun 2017 22:18:21 +0200
> > Daniel Scheller <d.scheller.oss@gmail.com> escreveu:
> >   
> > > Well. From how things look, these and the cxd2841er+C2T2 ddbridge
> > > support patches won't make it in time for the 4.13 merge window.    
> > 
> > There is time. I just merged this series today.  
> 
> Oh. Well, this, together with the other series, came as a (quite
> positive) surprise this morning - thank you very very much!

Anytime. Sorry again for taking a long time reviewing it.
> 
> > The thing is that we currently have few developers working on
> > DVB, and no sub-maintainers. Due to that, I need to review
> > them myself, with I usually do after reviewing/applying patches
> > from sub-maintainers.  
> 
> Understood. Though, and please don't get me wrong - Tearing apart and
> under how things in the driver, the vendor driver package, the media and
> DVB subsystem aswell as kernel parts, additionally aligning the
> patches/commits with all remarks from previous submissions in mind took
> quite some spare time for more than a year now, getting no responses at
> all honestly started to get frustrating.

Yes, I know how frustrating it can be. The real fix for this issue
would be to get more people involved on dvb. 

> > > Also, unfortunately, the original owners and/or maintainers of the
> > > affected drivers (besides cxd2841er), namely stv0367 and ddbridge,
> > > either are MIA or not interested in reviewing or acking this.    
> > 
> > Yeah, it would be great if Ralph would have some time to review
> > them, or to submit a new series adding all pending features from
> > DD drivers upstream.  
> 
> This would of course be the way to go. OTOH, the in-kernel driver
> already diverged quite a lot to that what DD publishes and maintains,
> and lots of people agree this situation must be improved.

Ralph went to a media summit we did in Germany a few years ago. At that
time, it sounded that the way to go would be to submit a new version of
the DD driver, based on upstream Kernel, and then DD start maintaining it
for both DD internal tree and Kernel one. Unfortunately, he never had 
the required time for such task.

We usually don't like this kind of change, as it is disruptive, with
regards to bug fixes, but, if we do it only once, and, after that, go
to the normal Kernel way, it could be not that bad.

> > > I have plenty of more work (patches) done, all building upon this CT
> > > and C2T2 hardware support, which - together with the work Jasmin has
> > > done regarding the en50221 and cxd2099 support - would finally bring
> > > the in-tree ddbridge driver on par with the package Digital Devices'
> > > provides, having addressed most of the critics the previous
> > > attempts to bump the driver received (incremental changes which are
> > > more or less easy to review, from what can be done by tearing
> > > tarballs without proper changelogs apart).    
> > 
> > Both Jasmin and Thomas could have reviewed it, and replied
> > if they tested it, and on what conditions. I tend to give
> > people some time to review/test patches, before doing my
> > review, as I don't usually have time for testing everything
> > myself.  
> 
> Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses
> such cards. However, for upcoming patches, I'll try to drag people to
> the list for some comments, thanks for the pointer.

Yeah, if you can drag people to help reviewing/testing (and even
coding), that would be really cool, as we'll be able to better
do our reviews.

> Speaking of patches and pending features (and generally syncing
> drivers), this is what I plan to send to the list (in order, mostly
> depending on each other):
> 
> - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
>   cards/modules. This mainly involves a new demod driver (stv0910) and
>   a new tuner driver (stv6111). Permissions for this are cleared with
>   Ralph already. The glue code needed in ddbridge is rather easy, and
>   as some ground work (mostly the MachXO2 support from the 2841 series)
>   is now in, the changes are quite small. Patches are ready so far but
>   need more cleanup (checkpatch fixes, camel case and such things).

Please try to sync it with Ralph, in a way that his code won't
diverge from the upstream one, as this will make easier for both
sides to keep the Kernel in track with driver improvements.

> 
> - The "big" ddbridge update. I'm thinking of two ways to do this:
> 
>   * Do this in one commit, being a huge code bump, bringing ddbridge to
>     version 0.9.28 (as per vendor versioning). This is mostly ready and
>     successful in use by many testers and in my Gentoo ddbridge kernel
>     sources overlay. Should get some more cleanups though (still some
>     GTL link bits left which are not needed), and all fixes which went
>     to the in-kernel driver like __user annotations need to be put back
>     in. Big drawback: A mess to review.
> 
>   * Try to tear apart most if not all upstream vendor driver tar
>     archives and recreate individual patches out of this. For
>     reference, we need to go from what is in the kernel which is
>     something inbetween v0.5 and v0.8 up to and including version
>     0.9.29. I'm currently working on this from time to time, and I can
>     assure you that this is an extremely tedious and unthankful thing
>     to do (currently nearly done with 0.9.9b, approx. 20 releases
>     left). This might be better to review, but this will also result in
>     something like 100-200 commits, without guarantee of having
>     everything correct.

The second approach is preferred, but, as you said, it is a very
complex task, and has bad effect that, at the time you're updating
it, the DD driver will be changed.

The first approach will require some things to work, though:

- the "legacy" driver should be kept at the Kernel for some time,
  in order to provide a "fall back" for those that find issues with
  the new version;

- you'll still need to patch DD tree, as I'm pretty sure there are
  changes on the upstream driver that will need to be ported there;

- This is a very painful thing to do. While I might accept do it
  once, I won't accept repeat it again a second time. So, if we do
  that, we need to agree with you and Ralph that any change at the
  DD tree will be submitted ASAP upstream, in order to avoid future
  gaps.

>   Reviewers will hate me for this, but I'd personally prefer the first
>   option (less work, verified working on quite some installs, less
>   clutter in GIT, but the drawback of reviewability).
> 
> - Last bit: DD MaxS4/S8 support. Requires another new demod driver
>   (mxl5xx) and some more bits (not only glue code, but also some
>   operation mode control and LNB handling) in ddbridge. Least work went
>   into this so far an the mxl5xx driver code needs quite some cleanup.
> 
> Note on the ddbridge update: This is mostly code refactoring and
> reorganisation, and feature-wise this is MSI interrupt and DD CI
> Single/Duo Bridge support. The vendor package also carries support for
> their OctoNET SATIP boxes and the DVB-C modulator support, which I
> intentionally leave out. Both features require quite some DVB core API
> changes which I can't argue on, but everything should be fairly easy to
> add back in if desired (that said, I didn't meet anyone with such a
> modulator card in the wild yet...)

On the other hand, a modulator card support upstream would be a really
cool thing :-)

But yeah, that sounds a separate project.

> 
> If you like, I'm happy and very open to discuss this further with you!

Feel free to do it ;)
> 
> > > (Cc Hans since you also seem to be reviewing patches)    
> > 
> > Hans is focused at V4L2 side.  
> 
> Wasn't aware of this, sorry.
> 
> > Btw, while you're here, it would be great if you could take
> > a look on those warnings (that comes via smatch):
> > 
> > 	drivers/media/pci/ddbridge/ddbridge-core.c:1009
> > input_tasklet() warn: this loop depends on readl() succeeding
> > drivers/media/pci/ddbridge/ddbridge-core.c:1353 flashio() warn: this
> > loop depends on readl() succeeding
> > drivers/media/pci/ddbridge/ddbridge-core.c:1373 flashio() warn: this
> > loop depends on readl() succeeding  
> 
> Sure, will take a peek on this.
> 
> BTW, you might have seen this - I posted four more patches which'll add
> DVBv5 signal stats to the DDB part of the stv0367 code. If you don't
> mind doing a quick inbetween-review of this, this would be nice if this
> could go in alongside the DD support (so, for 4.13 aswell).

I intend to do more patch reviews this week. I'll try to take a look
on them.

Regards,
Mauro

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

[Jasmin J.]

Hello Mauro!

> Yeah, it would be great if Ralph would have some time to review
> them, or to submit a new series adding all pending features from
> DD drivers upstream.
I am pretty sure he will not do that.

> Both Jasmin and Thomas could have reviewed it, and replied
> if they tested it, and on what conditions.
I can't test this, I have only S2 cards here, sorry. I will not sign
things, which I can't test.

BR,
   Jasmin

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Am Tue, 20 Jun 2017 16:10:43 -0300
schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

> Em Tue, 20 Jun 2017 20:41:21 +0200
> Daniel Scheller <d.scheller.oss@gmail.com> escreveu:
> 
> > Not sure about Thomas, but I know that Jasmin doesn't own and/ore uses
> > such cards. However, for upcoming patches, I'll try to drag people to
> > the list for some comments, thanks for the pointer.  
> 
> Yeah, if you can drag people to help reviewing/testing (and even
> coding), that would be really cool, as we'll be able to better
> do our reviews.

For the upcoming bigger changes around ddbridge and new demod/tuner drivers, I'll try to do so. Though this would mostly be for Tested-By's, but still.


> > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
> >   cards/modules. This mainly involves a new demod driver (stv0910) and
> >   a new tuner driver (stv6111). Permissions for this are cleared with
> >   Ralph already. The glue code needed in ddbridge is rather easy, and
> >   as some ground work (mostly the MachXO2 support from the 2841 series)
> >   is now in, the changes are quite small. Patches are ready so far but
> >   need more cleanup (checkpatch fixes, camel case and such things).  
> 
> Please try to sync it with Ralph, in a way that his code won't
> diverge from the upstream one, as this will make easier for both
> sides to keep the Kernel in track with driver improvements.

This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.

Putting Ralph into "To:", really like to hear an opinion from him on this whole subject.

> > - The "big" ddbridge update. I'm thinking of two ways to do this:
> > 
> >   * Do this in one commit, being a huge code bump, bringing ddbridge to
> >     version 0.9.28 (as per vendor versioning). This is mostly ready and
> >     successful in use by many testers and in my Gentoo ddbridge kernel
> >     sources overlay. Should get some more cleanups though (still some
> >     GTL link bits left which are not needed), and all fixes which went
> >     to the in-kernel driver like __user annotations need to be put back
> >     in. Big drawback: A mess to review.
> > 
> >   * Try to tear apart most if not all upstream vendor driver tar
> >     archives and recreate individual patches out of this. For
> >     reference, we need to go from what is in the kernel which is
> >     something inbetween v0.5 and v0.8 up to and including version
> >     0.9.29. I'm currently working on this from time to time, and I can
> >     assure you that this is an extremely tedious and unthankful thing
> >     to do (currently nearly done with 0.9.9b, approx. 20 releases
> >     left). This might be better to review, but this will also result in
> >     something like 100-200 commits, without guarantee of having
> >     everything correct.  
> 
> The second approach is preferred, but, as you said, it is a very
> complex task, and has bad effect that, at the time you're updating
> it, the DD driver will be changed.

I'd welcome it if we could put approach two somewhat aside for at least the reasons outlined :)

> The first approach will require some things to work, though:
> 
> - the "legacy" driver should be kept at the Kernel for some time,
>   in order to provide a "fall back" for those that find issues with
>   the new version;

From what can be gathered from forums and such, the current ("upstream") version doesn't show some (if any) issues. Though I'm aware that MSI interrupts are still an issue on a lot of hardware platforms, but disabling that option by default in the driver and toggling this via a Kconfig option works around this, since w/o MSI things work like a charm. Thats a problem that needs to be resolved by the vendor though.

Still, I understand you that you'd like to keep this around. Not exactly sure though how to achieve this in detail. Renaming media/pci/ddbridge to e.g. media/pci/ddbridge-legacy is the easy part, but if we don't want to mix up commits, one point in the commit history remains where there's a driver named ddbridge-legacy and no ddbridge (driver missing) exists (commit: "rename ddbridge to ddbridge-legacy", commit+1: "import updated and cleaned ddbridge driver from vendor package"). Also, it must be made sure that both drivers at best won't be built at the same time due to overlapping PCI IDs, possibly leading to additional issues on users installs.

> - you'll still need to patch DD tree, as I'm pretty sure there are
>   changes on the upstream driver that will need to be ported there;

The same as for the stv0910 code applies here, in addition that it's not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some places. And - most importantly - they carry around an old version of the DVB core API (from what it looks, around linux-3.10, not exactly sure) which even was modified by some IOCTLs, vars, defines and the netstream and modulator support. I managed to remove all core API change deps from everything tuner related (and thats the reason things work in harmony with and in current kernels), but getting all this over to DD or even merge things from DD into the media subsystem will get "interesting".

> - This is a very painful thing to do. While I might accept do it
>   once, I won't accept repeat it again a second time. So, if we do
>   that, we need to agree with you and Ralph that any change at the
>   DD tree will be submitted ASAP upstream, in order to avoid future
>   gaps.

Well, I can offer you: For the new STV0910, STV6111 and MXL5XX, as well as ddbridge itself when it's done, I can take over maintainership, in a way that when dddvb upstream changes emerge, I'll take care of submitting (relevant) things to linux-media quickly (as my work and private time schedule allows). However, since I'm not too far into all things kernel and DVB core yet, I would need help on other things from others.

This task is definitely doable when we get to a point that the current bridge code is in the kernel tree. DD recently started to publish driver changes in small increments, which - if you know a few things about the internals and know what differs in both versions - is a rather easy task.

Yet, to achieve this, I'd really propose doing the "big bang" once and do the final cleanup during that process (and yes, the cleanup IS neccessary!).

> > If you like, I'm happy and very open to discuss this further with you!  
> 
> Feel free to do it ;)

On it :)

> > BTW, you might have seen this - I posted four more patches which'll add
> > DVBv5 signal stats to the DDB part of the stv0367 code. If you don't
> > mind doing a quick inbetween-review of this, this would be nice if this
> > could go in alongside the DD support (so, for 4.13 aswell).  
> 
> I intend to do more patch reviews this week. I'll try to take a look
> on them.

Series already posted as v2 with (most of) the remarks from Antti addressed.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Daniel Scheller writes:
 > Am Tue, 20 Jun 2017 16:10:43 -0300
 > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
 > ...
 > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
 > > >   cards/modules. This mainly involves a new demod driver (stv0910) and
 > > >   a new tuner driver (stv6111). Permissions for this are cleared with
 > > >   Ralph already. The glue code needed in ddbridge is rather easy, and
 > > >   as some ground work (mostly the MachXO2 support from the 2841 series)
 > > >   is now in, the changes are quite small. Patches are ready so far but
 > > >   need more cleanup (checkpatch fixes, camel case and such things).  
 > > 
 > > Please try to sync it with Ralph, in a way that his code won't
 > > diverge from the upstream one, as this will make easier for both
 > > sides to keep the Kernel in track with driver improvements.
 > 
 > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.
 > 
 > Putting Ralph into "To:", really like to hear an opinion from him on this whole subject.

Regarding divergence in the tuner/demod drivers I see some concerns. 
The TDA18212 driver as they are presently in kernel and Daniel's  github tree still seems to be missing features
like calibration and spur avoidance. This problem was already discussed here a few years ago.
I would not want to move to these versions if those features are still missing.

I also already told Daniel about our concerns regarding the CXD drivers in private mail.
Sony did not want us to use their code directly and we had to get our code approved
before publishing it. I do not know how the arrangement is regarding the in-kernel driver.
DVB-C2 support also seems to be missing in this.


 > > - you'll still need to patch DD tree, as I'm pretty sure there are
 > >   changes on the upstream driver that will need to be ported there;
 > 
 > The same as for the stv0910 code applies here, in addition that it's not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some places. And - most importantly - they carry around an old version of the DVB core API (from what it looks, around linux-3.10, not exactly sure) which even was modified by some IOCTLs, vars, defines and the netstream and modulator support. I managed to remove all core API change deps from everything tuner related (and thats the reason things work in harmony with and in current kernels), but getting all this over to DD or even merge things from DD into the media subsystem will get "interesting".

We certainly will want to keep supporting older kernels via KERNEL_VERSION.
But I can change the dvb core version in dddvb to a newer version.

Also, some of the new tuning defines and properties are generally useful and
should be added to the kernel.

e.g.:

- adding SYS_DVBC2 to fe_delivery_system 

- DTV_INPUT

  to select an input on cards were demods can choose from several inputs

- DTV_PLS

  to set the gold code used for DVB-S2 physical layer scrambling.
  (btw. the sometimes used root and combo codes are redundant)
  Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but
  PLS and MIS are independent.


I know that the netstream and modulator support are proprietary but we will of course also need to keep
them dddvb package.
Btw., are there any standard APIs for modulator cards in the kernel now?


Regards,
Ralph

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Thu, 22 Jun 2017 23:35:27 +0200
Ralph Metzler <rjkm@metzlerbros.de> escreveu:

> Daniel Scheller writes:
>  > Am Tue, 20 Jun 2017 16:10:43 -0300
>  > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>  > ...  
>  > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
>  > > >   cards/modules. This mainly involves a new demod driver (stv0910) and
>  > > >   a new tuner driver (stv6111). Permissions for this are cleared with
>  > > >   Ralph already. The glue code needed in ddbridge is rather easy, and
>  > > >   as some ground work (mostly the MachXO2 support from the 2841 series)
>  > > >   is now in, the changes are quite small. Patches are ready so far but
>  > > >   need more cleanup (checkpatch fixes, camel case and such things).    
>  > > 
>  > > Please try to sync it with Ralph, in a way that his code won't
>  > > diverge from the upstream one, as this will make easier for both
>  > > sides to keep the Kernel in track with driver improvements.  
>  > 
>  > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.

Ralph, do you share Linux code with Windows, or are you just getting
drivers from the manufacturer and converting them to Linux at dddvb
tree?

Would it be possible to change things at the dddvb tree to make
it to use our coding style (for example, replacing CamelCase by the
kernel_style), in order to minimize the amount of work to sync from
your tree?

>  > 
>  > Putting Ralph into "To:", really like to hear an opinion from him on this whole subject.  
> 
> Regarding divergence in the tuner/demod drivers I see some concerns. 
> The TDA18212 driver as they are presently in kernel and Daniel's  github tree still seems to be missing features
> like calibration and spur avoidance. This problem was already discussed here a few years ago.
> I would not want to move to these versions if those features are still missing.

I don't see any issue on adding the missing features to the existing
tda18212 driver. Maybe Daniel can help adding the missing features there.

The best would be to make those new features opt-in, in order to allow 
drivers to gradually use them (after tests), avoiding regressions.

> I also already told Daniel about our concerns regarding the CXD drivers in private mail.
> Sony did not want us to use their code directly and we had to get our code approved
> before publishing it. I do not know how the arrangement is regarding the in-kernel driver.
> DVB-C2 support also seems to be missing in this.

Sony recently started submitting CXD drivers to us directly (for cxd2880).

The upstream verson for cx2841 came from NetUP. I guess they develop
the drivers themselves, but not really sure.

Perhaps we can ask Sony's help to make easier add the features that are 
missing at the existing driver in a way that DDbridge could also use
the upstream driver, or to do some other sort of agreement that would 
make possible for us to use the same driver as you at the upstream Kernel.

(c/c Takiguchi-san and Tim Bird from Sony)

>  > > - you'll still need to patch DD tree, as I'm pretty sure there are
>  > >   changes on the upstream driver that will need to be ported there;  
>  > 
>  > The same as for the stv0910 code applies here, in addition that it's not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some places. And - most importantly - they carry around an old version of the DVB core API (from what it looks, around linux-3.10, not exactly sure) which even was modified by some IOCTLs, vars, defines and the netstream and modulator support. I managed to remove all core API change deps from everything tuner related (and thats the reason things work in harmony with and in current kernels), but getting all this over to DD or even merge things from DD into the media subsystem will get "interesting".  
> 
> We certainly will want to keep supporting older kernels via KERNEL_VERSION.

In the past, we used a script that "solves" KERNEL_VERSION on our Mercurial
tree (https://linuxtv.org/hg/v4l-dvb) and gets rid of other ifdefs:

	https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/gentree.pl

I don't use it for ages, but I guess it shouldn't be hard to modify it to
get rid of KERNEL_VERSION when submitting stuff from DD tree upstream.

Alternatively, DDbridge could use, instead, a modified version of
media-build tree in order to support backports.

> But I can change the dvb core version in dddvb to a newer version.
> 
> Also, some of the new tuning defines and properties are generally useful and
> should be added to the kernel.
> 
> e.g.:
> 
> - adding SYS_DVBC2 to fe_delivery_system 

OK, we can do that, when adding a driver needing such feature.

> 
> - DTV_INPUT
> 
>   to select an input on cards were demods can choose from several inputs

We're actually wanting to use the media controller to change the
pipeline (selecting inputs and outputs, directing output to a MPEG
decoding pipeline and descrambler, etc).

The needed bits are there already at the DVB core upstream (although
we don't have, currently, any DVB driver allowing changes at the
pipeline). My original intention were to upstream some embedded
drivers with such usage, but, unfortunately, the MC changes took
too many time to be applied. by the time it got merged, it was too
late, due to some internal changes that happened about the same time.

> 
> - DTV_PLS
> 
>   to set the gold code used for DVB-S2 physical layer scrambling.
>   (btw. the sometimes used root and combo codes are redundant)
>   Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but
>   PLS and MIS are independent.

In principle, sounds ok, but we need to take some care to avoid
regressions here.

> I know that the netstream and modulator support are proprietary but we will of course also need to keep
> them dddvb package.
> Btw., are there any standard APIs for modulator cards in the kernel now?

Right now, we don't have. Feel free to propose what you're using at the
dddvb package as standard, if you think it is generic enough to support
other modulators in the future.

Thanks,
Mauro

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Am Sat, 24 Jun 2017 13:50:01 -0300
schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

> Em Thu, 22 Jun 2017 23:35:27 +0200
> Ralph Metzler <rjkm@metzlerbros.de> escreveu:
> 
> Would it be possible to change things at the dddvb tree to make
> it to use our coding style (for example, replacing CamelCase by the
> kernel_style), in order to minimize the amount of work to sync from
> your tree?

Note that this mostly (if not only) applies to the demodulator drivers. ddbridge itself is okay in this regard and has only some minors like indent, whitespace and such. There's one bigger thing though I'm not sure of if it needs to be changed: Beginning with the 0.9.9-tarball release, functionality was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and netstream/octonet related code, which we don't need at this time). The issue is that this wasn't done by updating the build system to build multiple objects, but rather build from ddbridge.c which then does '#include "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. Mauro, do you think this is acceptable?

> > Regarding divergence in the tuner/demod drivers I see some concerns. 
> > The TDA18212 driver as they are presently in kernel and Daniel's  github tree still seems to be missing features
> > like calibration and spur avoidance. This problem was already discussed here a few years ago.
> > I would not want to move to these versions if those features are still missing.  
> 
> I don't see any issue on adding the missing features to the existing
> tda18212 driver. Maybe Daniel can help adding the missing features there.
> 
> The best would be to make those new features opt-in, in order to allow 
> drivers to gradually use them (after tests), avoiding regressions.

I already started something when I searched for possible reasons for the stv0367 I2C bus crashes and implemented the tuner calibration (this wasn't the reason in the end, but still), see [2]. Guess a config flag like in [3] will work. But I'd need advice in what parts are required to be ported over if I should do this.

> > - adding SYS_DVBC2 to fe_delivery_system   
> 
> OK, we can do that, when adding a driver needing such feature.

I might volunteer in adding DVB-C2 support to cxd2841er in porting needed bits over from the cxd2843 driver, but someone else need to do testing on a DVB-C2 enabled coax cable.

Best regards,
Daniel Scheller

[1] https://github.com/herrnst/dddvb-linux-kernel/blob/17d60ca45dd0294120882af9abbbdf9e5a130cb5/drivers/media/pci/ddbridge/ddbridge.c#L50
[2] https://github.com/herrnst/dddvb-linux-kernel/commit/0788bd5e05fffdcd2d00d1fa2732c9712c6c759d
[3] https://patchwork.linuxtv.org/patch/40710/
-- 
https://github.com/herrnst

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Sun, 25 Jun 2017 19:52:59 +0200
Daniel Scheller <d.scheller.oss@gmail.com> escreveu:

> Am Sat, 24 Jun 2017 13:50:01 -0300
> schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
> 
> > Em Thu, 22 Jun 2017 23:35:27 +0200
> > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
> > 
> > Would it be possible to change things at the dddvb tree to make
> > it to use our coding style (for example, replacing CamelCase by the
> > kernel_style), in order to minimize the amount of work to sync from
> > your tree?  
> 
> Note that this mostly (if not only) applies to the demodulator drivers. ddbridge itself is okay in this regard and has only some minors like indent, whitespace and such. There's one bigger thing though I'm not sure of if it needs to be changed: Beginning with the 0.9.9-tarball release, functionality was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and netstream/octonet related code, which we don't need at this time). The issue is that this wasn't done by updating the build system to build multiple objects, but rather build from ddbridge.c which then does '#include "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. Mauro, do you think this is acceptable?

Splitting it is OK. Including a *.c file no. It shouldn't be hard to
change the makefile to:
	obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \
		       ddbridge-modulator.o and ddbridge-ns.o

The only detail is that "ddbridge.c" should be renamed to 
ddbridge-core.c (or something similar) and some *.h files will
be needed.

I would also refrain for using ddbridge-mod, as the Kernel build
system generates file with ".mod.c" extension. Having a file
with "-mod.c" can be confusing.

> > > Regarding divergence in the tuner/demod drivers I see some concerns. 
> > > The TDA18212 driver as they are presently in kernel and Daniel's  github tree still seems to be missing features
> > > like calibration and spur avoidance. This problem was already discussed here a few years ago.
> > > I would not want to move to these versions if those features are still missing.    
> > 
> > I don't see any issue on adding the missing features to the existing
> > tda18212 driver. Maybe Daniel can help adding the missing features there.
> > 
> > The best would be to make those new features opt-in, in order to allow 
> > drivers to gradually use them (after tests), avoiding regressions.  
> 
> I already started something when I searched for possible reasons for the stv0367 I2C bus crashes and implemented the tuner calibration (this wasn't the reason in the end, but still), see [2]. Guess a config flag like in [3] will work. But I'd need advice in what parts are required to be ported over if I should do this.

Yes, config flags work, but please don't use a config flag like this:

	if (initflags & TDA18212_INIT_DDSTV) 

The flags should identify the required functionality, not if the
caller is ddbridge driver. On a quick look at your patch, I suspect
that it would need two flags, like:

	TDA18212_FLAG_SLEEP - with would enable sleep/wakeup/standby
	TDA18212_FLAG_CALIBRATION - with would enable calibration


> 
> > > - adding SYS_DVBC2 to fe_delivery_system     
> > 
> > OK, we can do that, when adding a driver needing such feature.  
> 
> I might volunteer in adding DVB-C2 support to cxd2841er in porting needed bits over from the cxd2843 driver, but someone else need to do testing on a DVB-C2 enabled coax cable.

I can't volunteer myself for the tests, as it depends on how busy
I'll be with other things, but I have an universal standard generator,
and some ddbridge frontends. Not sure if the one I have has
cxd2341er. I won't be able to touch on it for the next month,
though.

I will need ~60 seconds of a DVB-C2 signal, in order to use the
generator, though.

> 
> Best regards,
> Daniel Scheller
> 
> [1] https://github.com/herrnst/dddvb-linux-kernel/blob/17d60ca45dd0294120882af9abbbdf9e5a130cb5/drivers/media/pci/ddbridge/ddbridge.c#L50
> [2] https://github.com/herrnst/dddvb-linux-kernel/commit/0788bd5e05fffdcd2d00d1fa2732c9712c6c759d
> [3] https://patchwork.linuxtv.org/patch/40710/



Thanks,
Mauro

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Mauro Carvalho Chehab writes:
 > Em Thu, 22 Jun 2017 23:35:27 +0200
 > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
 > 
 > > Daniel Scheller writes:
 > >  > Am Tue, 20 Jun 2017 16:10:43 -0300
 > >  > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
 > >  > ...  
 > >  > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
 > >  > > >   cards/modules. This mainly involves a new demod driver (stv0910) and
 > >  > > >   a new tuner driver (stv6111). Permissions for this are cleared with
 > >  > > >   Ralph already. The glue code needed in ddbridge is rather easy, and
 > >  > > >   as some ground work (mostly the MachXO2 support from the 2841 series)
 > >  > > >   is now in, the changes are quite small. Patches are ready so far but
 > >  > > >   need more cleanup (checkpatch fixes, camel case and such things).    
 > >  > > 
 > >  > > Please try to sync it with Ralph, in a way that his code won't
 > >  > > diverge from the upstream one, as this will make easier for both
 > >  > > sides to keep the Kernel in track with driver improvements.  
 > >  > 
 > >  > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.
 > 
 > Ralph, do you share Linux code with Windows, or are you just getting
 > drivers from the manufacturer and converting them to Linux at dddvb
 > tree?

It differs from case to case.
Digital Devices gets drivers and/or documetation from the manufacturer.
Sometimes from this a Windows driver is written which we convert
to Linux or a Linux driver is written directly.



 > Would it be possible to change things at the dddvb tree to make
 > it to use our coding style (for example, replacing CamelCase by the
 > kernel_style), in order to minimize the amount of work to sync from
 > your tree?

Yes

 > > I also already told Daniel about our concerns regarding the CXD drivers in private mail.
 > > Sony did not want us to use their code directly and we had to get our code approved
 > > before publishing it. I do not know how the arrangement is regarding the in-kernel driver.
 > > DVB-C2 support also seems to be missing in this.
 > 
 > Sony recently started submitting CXD drivers to us directly (for cxd2880).
 > 
 > The upstream verson for cx2841 came from NetUP. I guess they develop
 > the drivers themselves, but not really sure.
 > 
 > Perhaps we can ask Sony's help to make easier add the features that are 
 > missing at the existing driver in a way that DDbridge could also use
 > the upstream driver, or to do some other sort of agreement that would 
 > make possible for us to use the same driver as you at the upstream Kernel.
 > 
 > (c/c Takiguchi-san and Tim Bird from Sony)


All I know is that they were strict with Digital Devices. We could not use
their code directly. That's why I am surprised the Netup code contains
Sony code.


 > >  > > - you'll still need to patch DD tree, as I'm pretty sure there are
 > >  > >   changes on the upstream driver that will need to be ported there;  
 > >  > 
 > >  > The same as for the stv0910 code applies here, in addition that it's not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs in some places. And - most importantly - they carry around an old version of the DVB core API (from what it looks, around linux-3.10, not exactly sure) which even was modified by some IOCTLs, vars, defines and the netstream and modulator support. I managed to remove all core API change deps from everything tuner related (and thats the reason things work in harmony with and in current kernels), but getting all this over to DD or even merge things from DD into the media subsystem will get "interesting".  
 > > 
 > > We certainly will want to keep supporting older kernels via KERNEL_VERSION.
 > 
 > In the past, we used a script that "solves" KERNEL_VERSION on our Mercurial
 > tree (https://linuxtv.org/hg/v4l-dvb) and gets rid of other ifdefs:
 > 
 > 	https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/gentree.pl
 > 
 > I don't use it for ages, but I guess it shouldn't be hard to modify it to
 > get rid of KERNEL_VERSION when submitting stuff from DD tree upstream.

I'll see if that works.

 > > e.g.:
 > > 
 > > - adding SYS_DVBC2 to fe_delivery_system 
 > 
 > OK, we can do that, when adding a driver needing such feature.
 > 
 > > 
 > > - DTV_INPUT
 > > 
 > >   to select an input on cards were demods can choose from several inputs
 > 
 > We're actually wanting to use the media controller to change the
 > pipeline (selecting inputs and outputs, directing output to a MPEG
 > decoding pipeline and descrambler, etc).

I this also for selecting frontend inputs?
It sounds more like switching transport stream data paths after the demod.



 > The needed bits are there already at the DVB core upstream (although
 > we don't have, currently, any DVB driver allowing changes at the
 > pipeline). My original intention were to upstream some embedded
 > drivers with such usage, but, unfortunately, the MC changes took
 > too many time to be applied. by the time it got merged, it was too
 > late, due to some internal changes that happened about the same time.
 > 
 > > 
 > > - DTV_PLS
 > > 
 > >   to set the gold code used for DVB-S2 physical layer scrambling.
 > >   (btw. the sometimes used root and combo codes are redundant)
 > >   Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but
 > >   PLS and MIS are independent.
 > 
 > In principle, sounds ok, but we need to take some care to avoid
 > regressions here.

I also support this old method in the stv0900 and stv0910 drivers.


 > > I know that the netstream and modulator support are proprietary but we will of course also need to keep
 > > them dddvb package.
 > > Btw., are there any standard APIs for modulator cards in the kernel now?
 > 
 > Right now, we don't have. Feel free to propose what you're using at the
 > dddvb package as standard, if you think it is generic enough to support
 > other modulators in the future.

OK


Reagards,
Ralph

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Mauro Carvalho Chehab writes:
 > Em Sun, 25 Jun 2017 19:52:59 +0200
 > Daniel Scheller <d.scheller.oss@gmail.com> escreveu:
 > 
 > > Am Sat, 24 Jun 2017 13:50:01 -0300
 > > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
 > > 
 > > > Em Thu, 22 Jun 2017 23:35:27 +0200
 > > > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
 > > > 
 > > > Would it be possible to change things at the dddvb tree to make
 > > > it to use our coding style (for example, replacing CamelCase by the
 > > > kernel_style), in order to minimize the amount of work to sync from
 > > > your tree?  
 > > 
 > > Note that this mostly (if not only) applies to the demodulator drivers. ddbridge itself is okay in this regard and has only some minors like indent, whitespace and such. There's one bigger thing though I'm not sure of if it needs to be changed: Beginning with the 0.9.9-tarball release, functionality was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and netstream/octonet related code, which we don't need at this time). The issue is that this wasn't done by updating the build system to build multiple objects, but rather build from ddbridge.c which then does '#include "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. Mauro, do you think this is acceptable?
 > 
 > Splitting it is OK. Including a *.c file no. It shouldn't be hard to

The main reason for using includes at the time were that the OctopusNet driver
(see https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/octonet.c)
was using the same files but with different defines set.
Those differences are pretty much gone now.


> change the makefile to:
 > 	obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \
 > 		       ddbridge-modulator.o and ddbridge-ns.o
 > 
 > The only detail is that "ddbridge.c" should be renamed to 
 > ddbridge-core.c (or something similar) and some *.h files will
 > be needed.

Hmm, ddbridge -> ddbridge-main would be fine.
Renaming ddbridge to ddbridge-core and ddbridge-core to something else
would be confusing.


Regards,
Ralph

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Mon, 26 Jun 2017 11:59:20 +0200
Ralph Metzler <rjkm@metzlerbros.de> escreveu:

> Mauro Carvalho Chehab writes:
>  > Em Sun, 25 Jun 2017 19:52:59 +0200
>  > Daniel Scheller <d.scheller.oss@gmail.com> escreveu:
>  >   
>  > > Am Sat, 24 Jun 2017 13:50:01 -0300
>  > > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>  > >   
>  > > > Em Thu, 22 Jun 2017 23:35:27 +0200
>  > > > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
>  > > > 
>  > > > Would it be possible to change things at the dddvb tree to make
>  > > > it to use our coding style (for example, replacing CamelCase by the
>  > > > kernel_style), in order to minimize the amount of work to sync from
>  > > > your tree?    
>  > > 
>  > > Note that this mostly (if not only) applies to the demodulator drivers. ddbridge itself is okay in this regard and has only some minors like indent, whitespace and such. There's one bigger thing though I'm not sure of if it needs to be changed: Beginning with the 0.9.9-tarball release, functionality was split from ddbridge-core.c into ddbridge.c, ddbridge-i2c.c, ddbridge-mod.c and ddbridge-ns.c (the two latter being modulator and netstream/octonet related code, which we don't need at this time). The issue is that this wasn't done by updating the build system to build multiple objects, but rather build from ddbridge.c which then does '#include "ddbridge-core.c"', and in that file '#include "ddbridge-i2c.c"'. See [1] for how it actually looks like in the file. Mauro, do you think this is acceptable?  
>  > 
>  > Splitting it is OK. Including a *.c file no. It shouldn't be hard to  
> 
> The main reason for using includes at the time were that the OctopusNet driver
> (see https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/octonet.c)
> was using the same files but with different defines set.
> Those differences are pretty much gone now.

I see. If now there's no defines to patch the code included via
ddbridge-core.c, it should be possible to create a driver with
the ddbridge "core" on it, and use the exported symbols there for
both octonet and ddbridge dvb drivers.

> > change the makefile to:
>  > 	obj-ddbridge = ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \
>  > 		       ddbridge-modulator.o and ddbridge-ns.o
>  > 
>  > The only detail is that "ddbridge.c" should be renamed to 
>  > ddbridge-core.c (or something similar) and some *.h files will
>  > be needed.  
> 
> Hmm, ddbridge -> ddbridge-main would be fine.

Yeah, that's what I meant to say :-)

I noticed that you have already a ddbridge-core. That's why
I added a "ddbridge-main" there. I forgot to change it at the
comment above ;)

> Renaming ddbridge to ddbridge-core and ddbridge-core to something else
> would be confusing.

Indeed.

Thanks,
Mauro

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Mon, 26 Jun 2017 11:45:08 +0200
Ralph Metzler <rjkm@metzlerbros.de> escreveu:

> Mauro Carvalho Chehab writes:
>  > Em Thu, 22 Jun 2017 23:35:27 +0200
>  > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
>  >   
>  > > Daniel Scheller writes:  
>  > >  > Am Tue, 20 Jun 2017 16:10:43 -0300
>  > >  > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>  > >  > ...    
>  > >  > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
>  > >  > > >   cards/modules. This mainly involves a new demod driver (stv0910) and
>  > >  > > >   a new tuner driver (stv6111). Permissions for this are cleared with
>  > >  > > >   Ralph already. The glue code needed in ddbridge is rather easy, and
>  > >  > > >   as some ground work (mostly the MachXO2 support from the 2841 series)
>  > >  > > >   is now in, the changes are quite small. Patches are ready so far but
>  > >  > > >   need more cleanup (checkpatch fixes, camel case and such things).      
>  > >  > > 
>  > >  > > Please try to sync it with Ralph, in a way that his code won't
>  > >  > > diverge from the upstream one, as this will make easier for both
>  > >  > > sides to keep the Kernel in track with driver improvements.    
>  > >  > 
>  > >  > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows 
>  > >  > driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the 
>  > >  > remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). 
>  > >  > I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're 
>  > >  > additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 
>  > >  > patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible 
>  > >  > anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole 
>  > >  > driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.  
>  > 
>  > Ralph, do you share Linux code with Windows, or are you just getting
>  > drivers from the manufacturer and converting them to Linux at dddvb
>  > tree?  
> 
> It differs from case to case.
> Digital Devices gets drivers and/or documetation from the manufacturer.
> Sometimes from this a Windows driver is written which we convert
> to Linux or a Linux driver is written directly.
> 
> 
> 
>  > Would it be possible to change things at the dddvb tree to make
>  > it to use our coding style (for example, replacing CamelCase by the
>  > kernel_style), in order to minimize the amount of work to sync from
>  > your tree?  
> 
> Yes

Good! With that, it should be easier to keep both versions containing
the same stuff.

> 
>  > > I also already told Daniel about our concerns regarding the CXD drivers in private mail.
>  > > Sony did not want us to use their code directly and we had to get our code approved
>  > > before publishing it. I do not know how the arrangement is regarding the in-kernel driver.
>  > > DVB-C2 support also seems to be missing in this.  
>  > 
>  > Sony recently started submitting CXD drivers to us directly (for cxd2880).
>  > 
>  > The upstream verson for cx2841 came from NetUP. I guess they develop
>  > the drivers themselves, but not really sure.
>  > 
>  > Perhaps we can ask Sony's help to make easier add the features that are 
>  > missing at the existing driver in a way that DDbridge could also use
>  > the upstream driver, or to do some other sort of agreement that would 
>  > make possible for us to use the same driver as you at the upstream Kernel.
>  > 
>  > (c/c Takiguchi-san and Tim Bird from Sony)  
> 
> 
> All I know is that they were strict with Digital Devices. We could not use
> their code directly. That's why I am surprised the Netup code contains
> Sony code.

I didn't say they're using Sony code. I actually suspect that they
did the same as you (but I have no means to be sure).

Yet, as Sony recently approached us for cxd2880, and they're now
developing an official driver to be upstreamed, I'm wandering if we
can get a better way to handle the cxd2841 driver in a way that will
make easier for everyone to use the same code.

>  > >  > > - you'll still need to patch DD tree, as I'm pretty sure there are
>  > >  > >   changes on the upstream driver that will need to be ported there;    
>  > >  > 
>  > >  > The same as for the stv0910 code applies here, in addition that it's
>  > >  > not sure if DD even wants this. DD even has KERNEL_VERSION_CODE ifdefs 
>  > >  > in some places. And - most importantly - they carry around an old 
>  > >  > version of the DVB core API (from what it looks, around linux-3.10,
>  > >  >  not exactly sure) which even was modified by some IOCTLs, vars, 
>  > >  > defines and the netstream and modulator support. I managed to
>  > >  >  remove all core API change deps from everything tuner related
>  > >  >  (and thats the reason things work in harmony with and in current
>  > >  >  kernels), but getting all this over to DD or even merge things
>  > >  >  from DD into the media subsystem will get "interesting".    
>  > > 
>  > > We certainly will want to keep supporting older kernels via KERNEL_VERSION.  
>  > 
>  > In the past, we used a script that "solves" KERNEL_VERSION on our Mercurial
>  > tree (https://linuxtv.org/hg/v4l-dvb) and gets rid of other ifdefs:
>  > 
>  > 	https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/gentree.pl
>  > 
>  > I don't use it for ages, but I guess it shouldn't be hard to modify it to
>  > get rid of KERNEL_VERSION when submitting stuff from DD tree upstream.  
> 
> I'll see if that works.
> 
>  > > e.g.:
>  > > 
>  > > - adding SYS_DVBC2 to fe_delivery_system   
>  > 
>  > OK, we can do that, when adding a driver needing such feature.
>  >   
>  > > 
>  > > - DTV_INPUT
>  > > 
>  > >   to select an input on cards were demods can choose from several inputs  
>  > 
>  > We're actually wanting to use the media controller to change the
>  > pipeline (selecting inputs and outputs, directing output to a MPEG
>  > decoding pipeline and descrambler, etc).  
> 
> I this also for selecting frontend inputs?
> It sounds more like switching transport stream data paths after the demod.

The media controller is generic enough to control all pipelines at
the hardware level. It can be used to select frontend inputs, to
dynamically add/remove CAM modules, etc.

If I remember well, in the case of the hardware I was working on that
time, each frontend had 3 inputs (and the hardware had 2 identical
sets of tuner/demod),  plus 3 MPEG-TS demuxes) and 2 CAM modules.

With the media controller, any arrangement between input, tuner,
demod, demux and CAM is possible, as long as supported by
the hardware.

On your case, as you also have a modulator, you could even
use the modulator as a frontend input, as a way to test if
demodulator hardware is OK (again, if your hardware allows
wiring on such way).

The big advantage of using the media controller is that, as all
components of the pipeline are visible, you don't need to have
an enum (or something like that) to identify what each input
number means at the hardware.

Btw, that's an example of a MC pipeline:
	https://www.infradead.org/~mchehab/mc-next-gen/cx231xx_hvr930c_hd.png

The graph is automatically generated from the information
reported by the Kernel.

Unfortunately, the project I was working was shut down before
I was able to implement the MC bits on it, so I don't have
any MC pipelines from any advanced hardware.

So, on all pipelines there at
https://www.infradead.org/~mchehab/mc-next-gen/ have just one input.


>  > The needed bits are there already at the DVB core upstream (although
>  > we don't have, currently, any DVB driver allowing changes at the
>  > pipeline). My original intention were to upstream some embedded
>  > drivers with such usage, but, unfortunately, the MC changes took
>  > too many time to be applied. by the time it got merged, it was too
>  > late, due to some internal changes that happened about the same time.
>  >   
>  > > 
>  > > - DTV_PLS
>  > > 
>  > >   to set the gold code used for DVB-S2 physical layer scrambling.
>  > >   (btw. the sometimes used root and combo codes are redundant)
>  > >   Some driver mods misuse the upper bits of DTV_STREAM_ID (which is for MIS in DVB-S2) for this, but
>  > >   PLS and MIS are independent.  
>  > 
>  > In principle, sounds ok, but we need to take some care to avoid
>  > regressions here.  
> 
> I also support this old method in the stv0900 and stv0910 drivers.

OK!

>  > > I know that the netstream and modulator support are proprietary but we will of course also need to keep
>  > > them dddvb package.
>  > > Btw., are there any standard APIs for modulator cards in the kernel now?  
>  > 
>  > Right now, we don't have. Feel free to propose what you're using at the
>  > dddvb package as standard, if you think it is generic enough to support
>  > other modulators in the future.  
> 
> OK

Thanks,
Mauro

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Resend since I received bad-mail-address bounces, sorry for any
duplicated email.

Am Mon, 26 Jun 2017 11:59:20 +0200
schrieb Ralph Metzler <rjkm@metzlerbros.de>:

> Mauro Carvalho Chehab writes:
>  > 
>  > Splitting it is OK. Including a *.c file no. It shouldn't be hard
>  > to  
> [...]
> > change the makefile to:
>  > 	obj-ddbridge = ddbridge-main.o ddbridge-core.o
>  > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o
>  > 
>  > The only detail is that "ddbridge.c" should be renamed to 
>  > ddbridge-core.c (or something similar) and some *.h files will
>  > be needed.  
> 
> Hmm, ddbridge -> ddbridge-main would be fine.

Funny, that's exactly the naming I had in mind when thinking about this
in the past :)

So, I'll propose a rough todo (commit list) for me (I will do and
care about this) then:

- 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved
  reordering the functions in the code, this will be repeated with the
  current mainline driver (helps keeping the diff with the actual code
  bump cleaner)
- 2/4: Do the split like done in 0.9.9 with the mainline driver, but do
  it by having multiple objects in the makefile, adding header files
  with prototypes where required
- 3/4: Bump the driver code with what is already there (means, the
  pre-cleaned variant w/o modulator and netstream/octonet stuff)
- 4/4 (or 4/x): Apply any additional patches (like the "enable msi by
  default Kconf opt, marked EXPERIMENTAL" thing I did to work around
  the still problematic MSI IRQ stuff to let users have a better
  experience)

When done, I'll post the patches for early review, but they'll have a
hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel
like ripping this out since we want that support anyway).

Additionally,I can do this for dddvb and submit it to the
DigitalDevices dddvb repository (GitHub Pull Request) so we're at least
in-sync wrt building the driver.

Ralph, Mauro, are you ok with this?

Mauro, in the meantime a decision should be made if the current
in-kernel ddbridge should be kept somewhere or not (ie. as legacy
driver). IMHO this is not absolutely neccessary since both driver
variants (dddvb directly and the "castrated" one) are in use by people
all around and besides MSI (which we can workaround until fixed
finally) I don't know of any complaints at all.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Am Mon, 26 Jun 2017 06:19:20 -0300
schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:

> Yes, config flags work, but please don't use a config flag like this:
> 
> 	if (initflags & TDA18212_INIT_DDSTV) 
> 
> The flags should identify the required functionality, not if the
> caller is ddbridge driver. On a quick look at your patch, I suspect
> that it would need two flags, like:
> 
> 	TDA18212_FLAG_SLEEP - with would enable sleep/wakeup/standby
> 	TDA18212_FLAG_CALIBRATION - with would enable calibration

Yes, of course. Actually, this was just some (early) random attempt at
fixing something which turned out unrelated and even doesn't apply as is
anymore. But that patch might be a start to get this done.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Daniel Scheller]

Am Mon, 26 Jun 2017 11:45:08 +0200
schrieb Ralph Metzler <rjkm@metzlerbros.de>:

> Mauro Carvalho Chehab writes:
> 
>  > Would it be possible to change things at the dddvb tree to make
>  > it to use our coding style (for example, replacing CamelCase by the
>  > kernel_style), in order to minimize the amount of work to sync from
>  > your tree?  
> 
> Yes

Addmittedly, this might have been too quick, but I just couldn't
resist :) (thankfully, tools exist for such jobs).

Ralph, please have a look at
https://github.com/DigitalDevices/dddvb/pull/12 - if you're fine with the result, I will start a V2 series based on kernel_case naming.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Daniel Scheller writes:
 > Am Mon, 26 Jun 2017 11:59:20 +0200
 > schrieb Ralph Metzler <rjkm@metzlerbros.de>:
 > 
 > > Mauro Carvalho Chehab writes:
 > >  > 
 > >  > Splitting it is OK. Including a *.c file no. It shouldn't be hard
 > >  > to  
 > > [...]
 > > > change the makefile to:
 > >  > 	obj-ddbridge = ddbridge-main.o ddbridge-core.o
 > >  > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o
 > >  > 
 > >  > The only detail is that "ddbridge.c" should be renamed to 
 > >  > ddbridge-core.c (or something similar) and some *.h files will
 > >  > be needed.  
 > > 
 > > Hmm, ddbridge -> ddbridge-main would be fine.
 > 
 > Funny, that's exactly the naming I had in mind when thinking about this
 > in the past :)
 > 
 > So, I'll propose a rough todo (commit list) for me (I will do and
 > care about this) then:
 > 
 > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved
 >   reordering the functions in the code, this will be repeated with the
 >   current mainline driver (helps keeping the diff with the actual code
 >   bump cleaner)
 > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do
 >   it by having multiple objects in the makefile, adding header files
 >   with prototypes where required
 > - 3/4: Bump the driver code with what is already there (means, the
 >   pre-cleaned variant w/o modulator and netstream/octonet stuff)
 > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by
 >   default Kconf opt, marked EXPERIMENTAL" thing I did to work around
 >   the still problematic MSI IRQ stuff to let users have a better
 >   experience)
 > 
 > When done, I'll post the patches for early review, but they'll have a
 > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel
 > like ripping this out since we want that support anyway).
 > 
 > Additionally,I can do this for dddvb and submit it to the DigitalDevices dddvb
 > repository (GitHub Pull Request) so we're at least in-sync wrt
 > building the driver.
 > 
 > Ralph, Mauro, are you ok with this?

I cannot promise which changes I will accept and when. Some will likely break
other things like building the OctopusNet image.

The public DigitalDevices repository also is not the one I am using for development.
So, changes will first go into our private repository and will only go upstream
for releases.


Regards,
Ralph

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Mauro Carvalho Chehab writes:
 > Em Mon, 26 Jun 2017 11:45:08 +0200
 > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
 > 
 > > Mauro Carvalho Chehab writes:
 > >  > Em Thu, 22 Jun 2017 23:35:27 +0200
 > >  > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
 > >  >   
 > >  > > Daniel Scheller writes:  
 > >  > >  > Am Tue, 20 Jun 2017 16:10:43 -0300
 > >  > >  > schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
 > >  > >  > ...    
 > >  > >  > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
 > >  > >  > > >   cards/modules. This mainly involves a new demod driver (stv0910) and
 > >  > >  > > >   a new tuner driver (stv6111). Permissions for this are cleared with
 > >  > >  > > >   Ralph already. The glue code needed in ddbridge is rather easy, and
 > >  > >  > > >   as some ground work (mostly the MachXO2 support from the 2841 series)
 > >  > >  > > >   is now in, the changes are quite small. Patches are ready so far but
 > >  > >  > > >   need more cleanup (checkpatch fixes, camel case and such things).      
 > >  > >  > > 
 > >  > >  > > Please try to sync it with Ralph, in a way that his code won't
 > >  > >  > > diverge from the upstream one, as this will make easier for both
 > >  > >  > > sides to keep the Kernel in track with driver improvements.    
 > >  > >  > 
 > >  > >  > This is not going to work. DD (Ralph and Manfred Voelkel) sort of maintain a shared code base between their Windows 
 > >  > >  > driver and the Linux kernel driver sources. While they didn't explicitely stated this, this can be noticed by the 
 > >  > >  > remarks and commented code in their OSS code, and the commit messages in their dddvb GIT (e.g. "sync with windows driver"). 
 > >  > >  > I've already cleaned up a lot of this (I believe no one wants to see such stuff in the linux kernel tree). If we're 
 > >  > >  > additionally going to replace all things camel case, with some more cleaning and maybe code shuffling after like a V4 
 > >  > >  > patch series, those two sources are out of sync in a way that no automatic sync by applying patches will be possible 
 > >  > >  > anymore. So, pushing from vendor's upstream to the kernel seems to be the only option, and in fact, if the whole 
 > >  > >  > driver/package stack completely lives in the kernel sources, maybe DD even decide to directly commit upstream (kernel) again.  
 > >  > 
 > >  > Ralph, do you share Linux code with Windows, or are you just getting
 > >  > drivers from the manufacturer and converting them to Linux at dddvb
 > >  > tree?  
 > > 
 > > It differs from case to case.
 > > Digital Devices gets drivers and/or documetation from the manufacturer.
 > > Sometimes from this a Windows driver is written which we convert
 > > to Linux or a Linux driver is written directly.
 > > 
 > > 
 > > 
 > >  > Would it be possible to change things at the dddvb tree to make
 > >  > it to use our coding style (for example, replacing CamelCase by the
 > >  > kernel_style), in order to minimize the amount of work to sync from
 > >  > your tree?  
 > > 
 > > Yes
 > 
 > Good! With that, it should be easier to keep both versions containing
 > the same stuff.
 > 
 > > 
 > >  > > I also already told Daniel about our concerns regarding the CXD drivers in private mail.
 > >  > > Sony did not want us to use their code directly and we had to get our code approved
 > >  > > before publishing it. I do not know how the arrangement is regarding the in-kernel driver.
 > >  > > DVB-C2 support also seems to be missing in this.  
 > >  > 
 > >  > Sony recently started submitting CXD drivers to us directly (for cxd2880).
 > >  > 
 > >  > The upstream verson for cx2841 came from NetUP. I guess they develop
 > >  > the drivers themselves, but not really sure.
 > >  > 
 > >  > Perhaps we can ask Sony's help to make easier add the features that are 
 > >  > missing at the existing driver in a way that DDbridge could also use
 > >  > the upstream driver, or to do some other sort of agreement that would 
 > >  > make possible for us to use the same driver as you at the upstream Kernel.
 > >  > 
 > >  > (c/c Takiguchi-san and Tim Bird from Sony)  
 > > 
 > > 
 > > All I know is that they were strict with Digital Devices. We could not use
 > > their code directly. That's why I am surprised the Netup code contains
 > > Sony code.
 > 
 > I didn't say they're using Sony code. I actually suspect that they
 > did the same as you (but I have no means to be sure).

The code contains a Sony copyright header.
That's why we were surprised. We did not get any GPLed code from Sony.


 > Yet, as Sony recently approached us for cxd2880, and they're now
 > developing an official driver to be upstreamed, I'm wandering if we
 > can get a better way to handle the cxd2841 driver in a way that will
 > make easier for everyone to use the same code.

Yes, that would be nice.


> The media controller is generic enough to control all pipelines at
 > the hardware level. It can be used to select frontend inputs, to
 > dynamically add/remove CAM modules, etc.
 > 
 > If I remember well, in the case of the hardware I was working on that
 > time, each frontend had 3 inputs (and the hardware had 2 identical
 > sets of tuner/demod),  plus 3 MPEG-TS demuxes) and 2 CAM modules.
 > 
 > With the media controller, any arrangement between input, tuner,
 > demod, demux and CAM is possible, as long as supported by
 > the hardware.

OK, for such complex arrangements it makes sense.
I just thought it to be overkill for just the input selection
and it also has to run on older kernels where th MC stuff is
not yet in the DVB core.


 > On your case, as you also have a modulator, you could even
 > use the modulator as a frontend input, as a way to test if
 > demodulator hardware is OK (again, if your hardware allows
 > wiring on such way).

Hmm, no, it cannot do that. 



Regards,
Ralph

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Tue, 27 Jun 2017 07:38:50 +0200
Ralph Metzler <rjkm@metzlerbros.de> escreveu:

> Daniel Scheller writes:
>  > Am Mon, 26 Jun 2017 11:59:20 +0200
>  > schrieb Ralph Metzler <rjkm@metzlerbros.de>:
>  >   
>  > > Mauro Carvalho Chehab writes:  
>  > >  > 
>  > >  > Splitting it is OK. Including a *.c file no. It shouldn't be hard
>  > >  > to    
>  > > [...]  
>  > > > change the makefile to:
>  > >  > 	obj-ddbridge = ddbridge-main.o ddbridge-core.o
>  > >  > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o
>  > >  > 
>  > >  > The only detail is that "ddbridge.c" should be renamed to 
>  > >  > ddbridge-core.c (or something similar) and some *.h files will
>  > >  > be needed.    
>  > > 
>  > > Hmm, ddbridge -> ddbridge-main would be fine.  
>  > 
>  > Funny, that's exactly the naming I had in mind when thinking about this
>  > in the past :)
>  > 
>  > So, I'll propose a rough todo (commit list) for me (I will do and
>  > care about this) then:
>  > 
>  > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved
>  >   reordering the functions in the code, this will be repeated with the
>  >   current mainline driver (helps keeping the diff with the actual code
>  >   bump cleaner)
>  > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do
>  >   it by having multiple objects in the makefile, adding header files
>  >   with prototypes where required
>  > - 3/4: Bump the driver code with what is already there (means, the
>  >   pre-cleaned variant w/o modulator and netstream/octonet stuff)
>  > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by
>  >   default Kconf opt, marked EXPERIMENTAL" thing I did to work around
>  >   the still problematic MSI IRQ stuff to let users have a better
>  >   experience)
>  > 
>  > When done, I'll post the patches for early review, but they'll have a
>  > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel
>  > like ripping this out since we want that support anyway).
>  > 
>  > Additionally,I can do this for dddvb and submit it to the DigitalDevices dddvb
>  > repository (GitHub Pull Request) so we're at least in-sync wrt
>  > building the driver.
>  > 
>  > Ralph, Mauro, are you ok with this?  
> 
> I cannot promise which changes I will accept and when. Some will likely break
> other things like building the OctopusNet image.
> 
> The public DigitalDevices repository also is not the one I am using for development.
> So, changes will first go into our private repository and will only go upstream
> for releases.

Are there any way where we can help to make easier to synchronize
upstream with your internal tree?

As Daniel mentioned that he used some scripts, perhaps he can send
them for you to run on your tree.

Another alternative would be if you could release a "fork" of your
development tree before a release, as sort of "release candidate"
or something similar, at least while we're taking some efforts to
synchronize it with upstream.


Thanks,
Mauro

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Mauro Carvalho Chehab]

Em Tue, 11 Jul 2017 20:12:35 +0200
Ralph Metzler <rjkm@metzlerbros.de> escreveu:

> Mauro Carvalho Chehab writes:
>  > Em Mon, 26 Jun 2017 11:45:08 +0200
>  > Ralph Metzler <rjkm@metzlerbros.de> escreveu:
>  >   

> > The media controller is generic enough to control all pipelines at
>  > the hardware level. It can be used to select frontend inputs, to
>  > dynamically add/remove CAM modules, etc.
>  > 
>  > If I remember well, in the case of the hardware I was working on that
>  > time, each frontend had 3 inputs (and the hardware had 2 identical
>  > sets of tuner/demod),  plus 3 MPEG-TS demuxes) and 2 CAM modules.
>  > 
>  > With the media controller, any arrangement between input, tuner,
>  > demod, demux and CAM is possible, as long as supported by
>  > the hardware.  
> 
> OK, for such complex arrangements it makes sense.
> I just thought it to be overkill for just the input selection

The media controller support is handled by the DVB core for the
general case. The needed bits that would give the flexibility that
ddbridge require shouldn't be hard to add.

> and it also has to run on older kernels where th MC stuff is
> not yet in the DVB core.

The MC DVB support is there since jan/2015 (Kernel 3.20):

commit a0246e02f466482a34c8ad94bedbe4efa498662d
Author: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Date:   Fri Jan 2 12:19:51 2015 -0300

    [media] dvbdev: add support for media controller
    
    Provide a way to register media controller device nodes
    at the DVB core.
    
    Please notice that the dvbdev callers also require changes
    for the devices to be registered via the media controller.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

$ git describe a0246e02f4664
media/v3.20-1-9-ga0246e02f466


For older Kernels, there are a few ways to proceed:

1) use an approach like media_build for the DD tree, where the
   DVB core is replaced by a newer one. I guess it has support
   since v2.6.30, at least for the core.

2) Keep use the solution you have already, using ifdefs on your
   tree to keep it supported with legacy Kernels.

3) you could base DD trees at the backport tree:
	https://backports.wiki.kernel.org/index.php/Main_Page
   I never used it myself, but it should be covering the
   media drivers there too.


Thanks,
Mauro