[PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Mauro Carvalho Chehab]

This patch series contain one feature and two bug fixes:

1) it ports the DRX-K driver to use just one frontend for all three
   delivery systems (DVB-C Annex A, DVB-C Annex C and DVB-T).
   As not all DRX-K supports all three, it also adds a logic there to
   show and accept only the delivery systems that are valid to the
   detected DRX-K version;

2) fixes a bug at dvb_frontend that causes it to wait forever, while
   changing to the second or upper delivery system (a var were not
   incremented inside it);

3) fixes a bug that a delivery system change would appear only on the
   second call, for a DVBv3 application.

With all these series applied, it is now possible to use frontend 0
for all delivery systems. As the current tools don't support changing
the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
be used to change between them:

For example, to use DVB-T with the standard scan:

$ ./dvb-fe-tool -d DVBT && scan /usr/share/dvb/dvb-t/au-Adelaide

[1] http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils


Mauro Carvalho Chehab (5):
  [media] drxk: remove ops.info.frequency_stepsize from DVB-C
  [media] drxk: create only one frontend for both DVB-C and DVB-T
  [media] drxk_hard: fix locking issues when changing the delsys
  [media] dvb_frontend: regression fix: add a missing inc inside the
    loop
  [media] dvb_frontend: Update ops.info.type earlier

 drivers/media/dvb/ddbridge/ddbridge-core.c |    2 +-
 drivers/media/dvb/dvb-core/dvb_frontend.c  |   11 +-
 drivers/media/dvb/frontends/drxk.h         |    6 +-
 drivers/media/dvb/frontends/drxk_hard.c    |  206 ++++++++++++----------------
 drivers/media/dvb/frontends/drxk_hard.h    |    4 +-
 drivers/media/dvb/ngene/ngene-cards.c      |    2 +-
 drivers/media/video/em28xx/em28xx-dvb.c    |   28 +----
 7 files changed, 104 insertions(+), 155 deletions(-)

-- 
1.7.7.5

[PATCH 1/5] [media] drxk: remove ops.info.frequency_stepsize from DVB-C

[Mauro Carvalho Chehab]

ops.info.frequency_stepsize is used only for DVB-T & friends. For
DVB-C, the step size is calculated using the symbol rate.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/frontends/drxk_hard.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c
index c8213f6..77e78f4 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6356,7 +6356,6 @@ static struct dvb_frontend_ops drxk_c_ops = {
 	.delsys = { SYS_DVBC_ANNEX_A, SYS_DVBC_ANNEX_C },
 	.info = {
 		 .name = "DRXK DVB-C",
-		 .frequency_stepsize = 62500,
 		 .frequency_min = 47000000,
 		 .frequency_max = 862000000,
 		 .symbol_rate_min = 870000,
-- 
1.7.7.5

[PATCH 2/5] [media] drxk: create only one frontend for both DVB-C and DVB-T

[Mauro Carvalho Chehab]

Instead of creating two DVB frontend entries for the same device,
create just one entry, and fill the delivery_system according with
the supported standards.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/ddbridge/ddbridge-core.c |    2 +-
 drivers/media/dvb/frontends/drxk.h         |    6 +-
 drivers/media/dvb/frontends/drxk_hard.c    |  192 ++++++++++++----------------
 drivers/media/dvb/frontends/drxk_hard.h    |    3 +-
 drivers/media/dvb/ngene/ngene-cards.c      |    2 +-
 drivers/media/video/em28xx/em28xx-dvb.c    |   28 +----
 6 files changed, 88 insertions(+), 145 deletions(-)

diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ba9a643..2f31648 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -580,7 +580,7 @@ static int demod_attach_drxk(struct ddb_input *input)
 	memset(&config, 0, sizeof(config));
 	config.adr = 0x29 + (input->nr & 1);
 
-	fe = input->fe = dvb_attach(drxk_attach, &config, i2c, &input->fe2);
+	fe = input->fe = dvb_attach(drxk_attach, &config, i2c);
 	if (!input->fe) {
 		printk(KERN_ERR "No DRXK found!\n");
 		return -ENODEV;
diff --git a/drivers/media/dvb/frontends/drxk.h b/drivers/media/dvb/frontends/drxk.h
index 870432f..0209818 100644
--- a/drivers/media/dvb/frontends/drxk.h
+++ b/drivers/media/dvb/frontends/drxk.h
@@ -37,12 +37,10 @@ struct drxk_config {
 #if defined(CONFIG_DVB_DRXK) || (defined(CONFIG_DVB_DRXK_MODULE) \
         && defined(MODULE))
 extern struct dvb_frontend *drxk_attach(const struct drxk_config *config,
-					struct i2c_adapter *i2c,
-					struct dvb_frontend **fe_t);
+					struct i2c_adapter *i2c);
 #else
 static inline struct dvb_frontend *drxk_attach(const struct drxk_config *config,
-					struct i2c_adapter *i2c,
-					struct dvb_frontend **fe_t)
+					struct i2c_adapter *i2c)
 {
         printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
         return NULL;
diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c
index 77e78f4..a95fb44 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6174,7 +6174,7 @@ error:
 	return status;
 }
 
-static void drxk_c_release(struct dvb_frontend *fe)
+static void drxk_release(struct dvb_frontend *fe)
 {
 	struct drxk_state *state = fe->demodulator_priv;
 
@@ -6182,21 +6182,7 @@ static void drxk_c_release(struct dvb_frontend *fe)
 	kfree(state);
 }
 
-static int drxk_c_init(struct dvb_frontend *fe)
-{
-	struct drxk_state *state = fe->demodulator_priv;
-
-	dprintk(1, "\n");
-	if (mutex_trylock(&state->ctlock) == 0)
-		return -EBUSY;
-	if (state->m_itut_annex_c)
-		SetOperationMode(state, OM_QAM_ITU_C);
-	else
-		SetOperationMode(state, OM_QAM_ITU_A);
-	return 0;
-}
-
-static int drxk_c_sleep(struct dvb_frontend *fe)
+static int drxk_sleep(struct dvb_frontend *fe)
 {
 	struct drxk_state *state = fe->demodulator_priv;
 
@@ -6229,24 +6215,36 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
 		return -EINVAL;
 	}
 
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+	if (fe->ops.tuner_ops.set_params)
+		fe->ops.tuner_ops.set_params(fe);
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+	state->props = *p;
+
 	switch (delsys) {
 	case SYS_DVBC_ANNEX_A:
-		state->m_itut_annex_c = false;
-		break;
 	case SYS_DVBC_ANNEX_C:
+		if (!state->m_hasDVBC)
+			return -EINVAL;
+		state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : false;
+		if (state->m_itut_annex_c)
+			SetOperationMode(state, OM_QAM_ITU_C);
+		else
+			SetOperationMode(state, OM_QAM_ITU_A);
+			break;
 		state->m_itut_annex_c = true;
 		break;
+	case SYS_DVBT:
+		if (!state->m_hasDVBT)
+			return -EINVAL;
+		SetOperationMode(state, OM_DVBT);
+		break;
 	default:
 		return -EINVAL;
 	}
 
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
-	if (fe->ops.tuner_ops.set_params)
-		fe->ops.tuner_ops.set_params(fe);
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
-	state->props = *p;
 	fe->ops.tuner_ops.get_if_frequency(fe, &IF);
 	Start(state, 0, IF);
 
@@ -6314,91 +6312,54 @@ static int drxk_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
 	return 0;
 }
 
-static int drxk_c_get_tune_settings(struct dvb_frontend *fe, struct dvb_frontend_tune_settings
+static int drxk_get_tune_settings(struct dvb_frontend *fe, struct dvb_frontend_tune_settings
 				    *sets)
 {
-	dprintk(1, "\n");
-	sets->min_delay_ms = 3000;
-	sets->max_drift = 0;
-	sets->step_size = 0;
-	return 0;
-}
-
-static void drxk_t_release(struct dvb_frontend *fe)
-{
-	/*
-	 * There's nothing to release here, as the state struct
-	 * is already freed by drxk_c_release.
-	 */
-}
-
-static int drxk_t_init(struct dvb_frontend *fe)
-{
-	struct drxk_state *state = fe->demodulator_priv;
-
-	dprintk(1, "\n");
-	if (mutex_trylock(&state->ctlock) == 0)
-		return -EBUSY;
-	SetOperationMode(state, OM_DVBT);
-	return 0;
-}
-
-static int drxk_t_sleep(struct dvb_frontend *fe)
-{
-	struct drxk_state *state = fe->demodulator_priv;
+	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
 
 	dprintk(1, "\n");
-	mutex_unlock(&state->ctlock);
-	return 0;
+	switch (p->delivery_system) {
+	case SYS_DVBC_ANNEX_A:
+	case SYS_DVBC_ANNEX_C:
+		sets->min_delay_ms = 3000;
+		sets->max_drift = 0;
+		sets->step_size = 0;
+		return 0;
+	default:
+		/*
+		 * For DVB-T, let it use the default DVB core way, that is:
+		 *	fepriv->step_size = fe->ops.info.frequency_stepsize * 2
+		 */
+		return -EINVAL;
+	}
 }
 
-static struct dvb_frontend_ops drxk_c_ops = {
-	.delsys = { SYS_DVBC_ANNEX_A, SYS_DVBC_ANNEX_C },
-	.info = {
-		 .name = "DRXK DVB-C",
-		 .frequency_min = 47000000,
-		 .frequency_max = 862000000,
-		 .symbol_rate_min = 870000,
-		 .symbol_rate_max = 11700000,
-		 .caps = FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
-		 FE_CAN_QAM_128 | FE_CAN_QAM_256 | FE_CAN_FEC_AUTO},
-	.release = drxk_c_release,
-	.init = drxk_c_init,
-	.sleep = drxk_c_sleep,
-	.i2c_gate_ctrl = drxk_gate_ctrl,
-
-	.set_frontend = drxk_set_parameters,
-	.get_tune_settings = drxk_c_get_tune_settings,
-
-	.read_status = drxk_read_status,
-	.read_ber = drxk_read_ber,
-	.read_signal_strength = drxk_read_signal_strength,
-	.read_snr = drxk_read_snr,
-	.read_ucblocks = drxk_read_ucblocks,
-};
-
-static struct dvb_frontend_ops drxk_t_ops = {
-	.delsys = { SYS_DVBT },
+static struct dvb_frontend_ops drxk_ops = {
+	/* .delsys will be filled dynamically */
 	.info = {
-		 .name = "DRXK DVB-T",
-		 .frequency_min = 47125000,
-		 .frequency_max = 865000000,
-		 .frequency_stepsize = 166667,
-		 .frequency_tolerance = 0,
-		 .caps = 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_QAM_16 | FE_CAN_QAM_64 |
-		 FE_CAN_QAM_AUTO |
-		 FE_CAN_TRANSMISSION_MODE_AUTO |
-		 FE_CAN_GUARD_INTERVAL_AUTO |
-		 FE_CAN_HIERARCHY_AUTO | FE_CAN_RECOVER | FE_CAN_MUTE_TS},
-	.release = drxk_t_release,
-	.init = drxk_t_init,
-	.sleep = drxk_t_sleep,
+		.name = "DRXK",
+		.frequency_min = 47000000,
+		.frequency_max = 865000000,
+		 /* For DVB-C */
+		.symbol_rate_min = 870000,
+		.symbol_rate_max = 11700000,
+		/* For DVB-T */
+		.frequency_stepsize = 166667,
+
+		.caps = FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
+			FE_CAN_QAM_128 | FE_CAN_QAM_256 | FE_CAN_FEC_AUTO |
+			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_MUTE_TS |
+			FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_RECOVER |
+			FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO
+	},
+
+	.release = drxk_release,
+	.sleep = drxk_sleep,
 	.i2c_gate_ctrl = drxk_gate_ctrl,
 
 	.set_frontend = drxk_set_parameters,
+	.get_tune_settings = drxk_get_tune_settings,
 
 	.read_status = drxk_read_status,
 	.read_ber = drxk_read_ber,
@@ -6408,9 +6369,10 @@ static struct dvb_frontend_ops drxk_t_ops = {
 };
 
 struct dvb_frontend *drxk_attach(const struct drxk_config *config,
-				 struct i2c_adapter *i2c,
-				 struct dvb_frontend **fe_t)
+				 struct i2c_adapter *i2c)
 {
+	int n;
+
 	struct drxk_state *state = NULL;
 	u8 adr = config->adr;
 
@@ -6445,21 +6407,29 @@ struct dvb_frontend *drxk_attach(const struct drxk_config *config,
 	mutex_init(&state->mutex);
 	mutex_init(&state->ctlock);
 
-	memcpy(&state->c_frontend.ops, &drxk_c_ops,
-	       sizeof(struct dvb_frontend_ops));
-	memcpy(&state->t_frontend.ops, &drxk_t_ops,
-	       sizeof(struct dvb_frontend_ops));
-	state->c_frontend.demodulator_priv = state;
-	state->t_frontend.demodulator_priv = state;
+	memcpy(&state->frontend.ops, &drxk_ops, sizeof(drxk_ops));
+	state->frontend.demodulator_priv = state;
 
 	init_state(state);
 	if (init_drxk(state) < 0)
 		goto error;
-	*fe_t = &state->t_frontend;
 
-	printk(KERN_INFO "drxk: frontend initialized.\n");
+	/* Initialize the supported delivery systems */
+	n = 0;
+	if (state->m_hasDVBC) {
+		state->frontend.ops.delsys[n++] = SYS_DVBC_ANNEX_A;
+		state->frontend.ops.delsys[n++] = SYS_DVBC_ANNEX_C;
+		strlcat(state->frontend.ops.info.name, " DVB-C",
+			sizeof(state->frontend.ops.info.name));
+	}
+	if (state->m_hasDVBT) {
+		state->frontend.ops.delsys[n++] = SYS_DVBT;
+		strlcat(state->frontend.ops.info.name, " DVB-T",
+			sizeof(state->frontend.ops.info.name));
+	}
 
-	return &state->c_frontend;
+	printk(KERN_INFO "drxk: frontend initialized.\n");
+	return &state->frontend;
 
 error:
 	printk(KERN_ERR "drxk: not found\n");
diff --git a/drivers/media/dvb/frontends/drxk_hard.h b/drivers/media/dvb/frontends/drxk_hard.h
index 60bcd61..7e3e4cf 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -195,8 +195,7 @@ struct DRXKOfdmScCmd_t {
 };
 
 struct drxk_state {
-	struct dvb_frontend c_frontend;
-	struct dvb_frontend t_frontend;
+	struct dvb_frontend frontend;
 	struct dtv_frontend_properties props;
 	struct device *dev;
 
diff --git a/drivers/media/dvb/ngene/ngene-cards.c b/drivers/media/dvb/ngene/ngene-cards.c
index 0564192..8418c02 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -218,7 +218,7 @@ static int demod_attach_drxk(struct ngene_channel *chan,
 	memset(&config, 0, sizeof(config));
 	config.adr = 0x29 + (chan->number ^ 2);
 
-	chan->fe = dvb_attach(drxk_attach, &config, i2c, &chan->fe2);
+	chan->fe = dvb_attach(drxk_attach, &config, i2c);
 	if (!chan->fe) {
 		printk(KERN_ERR "No DRXK found!\n");
 		return -ENODEV;
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c
index 1194631..ac55de9 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -874,11 +874,8 @@ static int em28xx_dvb_init(struct em28xx *dev)
 		struct xc5000_config cfg;
 		hauppauge_hvr930c_init(dev);
 
-		dvb->dont_attach_fe1 = 1;
-
 		dvb->fe[0] = dvb_attach(drxk_attach,
-					&hauppauge_930c_drxk, &dev->i2c_adap,
-					&dvb->fe[1]);
+					&hauppauge_930c_drxk, &dev->i2c_adap);
 		if (!dvb->fe[0]) {
 			result = -EINVAL;
 			goto out_free;
@@ -888,7 +885,6 @@ static int em28xx_dvb_init(struct em28xx *dev)
 		sema_init(&dvb->pll_mutex, 1);
 		dvb->gate_ctrl = dvb->fe[0]->ops.i2c_gate_ctrl;
 		dvb->fe[0]->ops.i2c_gate_ctrl = drxk_gate_ctrl;
-		dvb->fe[1]->id = 1;
 
 		/* Attach xc5000 */
 		memset(&cfg, 0, sizeof(cfg));
@@ -902,27 +898,16 @@ static int em28xx_dvb_init(struct em28xx *dev)
 			result = -EINVAL;
 			goto out_free;
 		}
-
 		if (dvb->fe[0]->ops.i2c_gate_ctrl)
 			dvb->fe[0]->ops.i2c_gate_ctrl(dvb->fe[0], 0);
 
-		/* Hack - needed by drxk/tda18271c2dd */
-		dvb->fe[1]->tuner_priv = dvb->fe[0]->tuner_priv;
-		memcpy(&dvb->fe[1]->ops.tuner_ops,
-		       &dvb->fe[0]->ops.tuner_ops,
-		       sizeof(dvb->fe[0]->ops.tuner_ops));
-
-		mfe_shared = 1;
-
 		break;
 	}
 	case EM2884_BOARD_TERRATEC_H5:
 	case EM2884_BOARD_CINERGY_HTC_STICK:
 		terratec_h5_init(dev);
 
-		dvb->dont_attach_fe1 = 1;
-
-		dvb->fe[0] = dvb_attach(drxk_attach, &terratec_h5_drxk, &dev->i2c_adap, &dvb->fe[1]);
+		dvb->fe[0] = dvb_attach(drxk_attach, &terratec_h5_drxk, &dev->i2c_adap);
 		if (!dvb->fe[0]) {
 			result = -EINVAL;
 			goto out_free;
@@ -932,7 +917,6 @@ static int em28xx_dvb_init(struct em28xx *dev)
 		sema_init(&dvb->pll_mutex, 1);
 		dvb->gate_ctrl = dvb->fe[0]->ops.i2c_gate_ctrl;
 		dvb->fe[0]->ops.i2c_gate_ctrl = drxk_gate_ctrl;
-		dvb->fe[1]->id = 1;
 
 		/* Attach tda18271 to DVB-C frontend */
 		if (dvb->fe[0]->ops.i2c_gate_ctrl)
@@ -944,14 +928,6 @@ static int em28xx_dvb_init(struct em28xx *dev)
 		if (dvb->fe[0]->ops.i2c_gate_ctrl)
 			dvb->fe[0]->ops.i2c_gate_ctrl(dvb->fe[0], 0);
 
-		/* Hack - needed by drxk/tda18271c2dd */
-		dvb->fe[1]->tuner_priv = dvb->fe[0]->tuner_priv;
-		memcpy(&dvb->fe[1]->ops.tuner_ops,
-		       &dvb->fe[0]->ops.tuner_ops,
-		       sizeof(dvb->fe[0]->ops.tuner_ops));
-
-		mfe_shared = 1;
-
 		break;
 	case EM28174_BOARD_PCTV_460E:
 		/* attach demod */
-- 
1.7.7.5

[PATCH 3/5] [media] drxk_hard: fix locking issues when changing the delsys

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/frontends/drxk_hard.c |   45 ++++++++++++++++--------------
 drivers/media/dvb/frontends/drxk_hard.h |    1 -
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c
index a95fb44..97670db 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6188,7 +6188,6 @@ static int drxk_sleep(struct dvb_frontend *fe)
 
 	dprintk(1, "\n");
 	ShutDown(state);
-	mutex_unlock(&state->ctlock);
 	return 0;
 }
 
@@ -6203,7 +6202,7 @@ static int drxk_gate_ctrl(struct dvb_frontend *fe, int enable)
 static int drxk_set_parameters(struct dvb_frontend *fe)
 {
 	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
-	u32 delsys  = p->delivery_system;
+	u32 delsys  = p->delivery_system, old_delsys;
 	struct drxk_state *state = fe->demodulator_priv;
 	u32 IF;
 
@@ -6221,28 +6220,33 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
 		fe->ops.tuner_ops.set_params(fe);
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
+
+	old_delsys = state->props.delivery_system;
 	state->props = *p;
 
-	switch (delsys) {
-	case SYS_DVBC_ANNEX_A:
-	case SYS_DVBC_ANNEX_C:
-		if (!state->m_hasDVBC)
-			return -EINVAL;
-		state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : false;
-		if (state->m_itut_annex_c)
-			SetOperationMode(state, OM_QAM_ITU_C);
-		else
-			SetOperationMode(state, OM_QAM_ITU_A);
+	if (old_delsys != delsys) {
+		ShutDown(state);
+		switch (delsys) {
+		case SYS_DVBC_ANNEX_A:
+		case SYS_DVBC_ANNEX_C:
+			if (!state->m_hasDVBC)
+				return -EINVAL;
+			state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : false;
+			if (state->m_itut_annex_c)
+				SetOperationMode(state, OM_QAM_ITU_C);
+			else
+				SetOperationMode(state, OM_QAM_ITU_A);
+				break;
+			state->m_itut_annex_c = true;
 			break;
-		state->m_itut_annex_c = true;
-		break;
-	case SYS_DVBT:
-		if (!state->m_hasDVBT)
+		case SYS_DVBT:
+			if (!state->m_hasDVBT)
+				return -EINVAL;
+			SetOperationMode(state, OM_DVBT);
+			break;
+		default:
 			return -EINVAL;
-		SetOperationMode(state, OM_DVBT);
-		break;
-	default:
-		return -EINVAL;
+		}
 	}
 
 	fe->ops.tuner_ops.get_if_frequency(fe, &IF);
@@ -6405,7 +6409,6 @@ struct dvb_frontend *drxk_attach(const struct drxk_config *config,
 		state->m_GPIO &= ~state->antenna_gpio;
 
 	mutex_init(&state->mutex);
-	mutex_init(&state->ctlock);
 
 	memcpy(&state->frontend.ops, &drxk_ops, sizeof(drxk_ops));
 	state->frontend.demodulator_priv = state;
diff --git a/drivers/media/dvb/frontends/drxk_hard.h b/drivers/media/dvb/frontends/drxk_hard.h
index 7e3e4cf..3a58b73 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -204,7 +204,6 @@ struct drxk_state {
 	void  *priv;
 
 	struct mutex mutex;
-	struct mutex ctlock;
 
 	u32    m_Instance;           /**< Channel 1,2,3 or 4 */
 
-- 
1.7.7.5

[PATCH 4/5] [media] dvb_frontend: regression fix: add a missing inc inside the loop

[Mauro Carvalho Chehab]

without it, the loop will run forever!

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 678e329..cd3c0f6 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1481,6 +1481,7 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system)
 					__func__, desired_system);
 				return 0;
 			}
+			ncaps++;
 		}
 		type = dvbv3_type(desired_system);
 
-- 
1.7.7.5

[PATCH 5/5] [media] dvb_frontend: Update ops.info.type earlier

[Mauro Carvalho Chehab]

ops.info.type should be updated before copying it into the
memory buffer that will be returned to userspace.

Also add some debug messages to help tracking such issues.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index cd3c0f6..1e1265e 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1551,6 +1551,8 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system)
 			}
 		}
 	}
+	dprintk("change delivery system on cache to %d\n", c->delivery_system);
+
 	return 0;
 }
 
@@ -1965,9 +1967,6 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 	switch (cmd) {
 	case FE_GET_INFO: {
 		struct dvb_frontend_info* info = parg;
-		memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
-		dvb_frontend_get_frequency_limits(fe, &info->frequency_min, &info->frequency_max);
-
 		/*
 		 * Associate the 4 delivery systems supported by DVBv3
 		 * API with their DVBv5 counterpart. For the other standards,
@@ -1998,6 +1997,11 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 			       __func__, c->delivery_system);
 			fe->ops.info.type = FE_OFDM;
 		}
+		dprintk("current delivery system on cache: %d, V3 type: %d\n",
+			c->delivery_system, fe->ops.info.type);
+
+		memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
+		dvb_frontend_get_frequency_limits(fe, &info->frequency_min, &info->frequency_max);
 
 		/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
 		 * do it, it is done for it. */
-- 
1.7.7.5

[PATCH v2] [media] dvb_frontend: Update the dynamic info->type

[Mauro Carvalho Chehab]

Instead of changing the ops.info.type struct, updates only
the data that will be returned to userspace.

Also add some debug messages to help tracking such issues.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index cd3c0f6..128f677 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1551,6 +1551,8 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system)
 			}
 		}
 	}
+	dprintk("change delivery system on cache to %d\n", c->delivery_system);
+
 	return 0;
 }
 
@@ -1965,6 +1967,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 	switch (cmd) {
 	case FE_GET_INFO: {
 		struct dvb_frontend_info* info = parg;
+
 		memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
 		dvb_frontend_get_frequency_limits(fe, &info->frequency_min, &info->frequency_max);
 
@@ -1981,16 +1984,16 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 		 */
 		switch (dvbv3_type(c->delivery_system)) {
 		case DVBV3_QPSK:
-			fe->ops.info.type = FE_QPSK;
+			info->type = FE_QPSK;
 			break;
 		case DVBV3_ATSC:
-			fe->ops.info.type = FE_ATSC;
+			info->type = FE_ATSC;
 			break;
 		case DVBV3_QAM:
-			fe->ops.info.type = FE_QAM;
+			info->type = FE_QAM;
 			break;
 		case DVBV3_OFDM:
-			fe->ops.info.type = FE_OFDM;
+			info->type = FE_OFDM;
 			break;
 		default:
 			printk(KERN_ERR
@@ -1998,6 +2001,8 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 			       __func__, c->delivery_system);
 			fe->ops.info.type = FE_OFDM;
 		}
+		dprintk("current delivery system on cache: %d, V3 type: %d\n",
+			c->delivery_system, fe->ops.info.type);
 
 		/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
 		 * do it, it is done for it. */
-- 
1.7.7.5

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Devin Heitmueller]

On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> With all these series applied, it is now possible to use frontend 0
> for all delivery systems. As the current tools don't support changing
> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
> be used to change between them:

Hi Mauro,

While from a functional standpoint I think this is a good change (and
we probably should have done it this way all along), is there not
concern that this could be interpreted by regular users as a
regression?  Right now they get two frontends, and they can use all
their existing tools.  We're moving to a model where if users upgraded
their kernel they would now require some new userland tool to do
something that the kernel was allowing them to do previously.

Sure, it's not "ABI breakage" in the classic sense but the net effect
is the same - stuff that used to work stops working and now they need
new tools or to recompile their existing tools to include new
functionality (which as you mentioned, none of those tools have
today).

Perhaps you would consider some sort of module option that would let
users fall back to the old behavior?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Mauro Carvalho Chehab]

On 05-01-2012 14:40, Devin Heitmueller wrote:
> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> With all these series applied, it is now possible to use frontend 0
>> for all delivery systems. As the current tools don't support changing
>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>> be used to change between them:
> 
> Hi Mauro,
> 
> While from a functional standpoint I think this is a good change (and
> we probably should have done it this way all along), is there not
> concern that this could be interpreted by regular users as a
> regression?  Right now they get two frontends, and they can use all
> their existing tools.  We're moving to a model where if users upgraded
> their kernel they would now require some new userland tool to do
> something that the kernel was allowing them to do previously.
> 
> Sure, it's not "ABI breakage" in the classic sense but the net effect
> is the same - stuff that used to work stops working and now they need
> new tools or to recompile their existing tools to include new
> functionality (which as you mentioned, none of those tools have
> today).
> 
> Perhaps you would consider some sort of module option that would let
> users fall back to the old behavior?

I see your point, but I can't see a simple way for fixing it. Thankfully,
there aren't many drivers yet that support multiple delivery systems
with different ops.info.type.

So, the better is to fix it earlier than later.

The issue with a fall-back option is that the end result will be the same:
it won't work as-is by default. The user will need to seek at the ML's
in order to discover about that. After discovering what is needed to fix
their environments, a simple tool that allows changing the delivery 
system at runtime  works better than a modprobe option to select it at
module load time, as it gives more flexibility to the user.

The real fix is to add support at the userspace applications for
using either the full DVBv5 API or, at least, to implement DTV_ENUM_DELSYS
and use a DVBv5 call to change the cache, on multi-frontend devices.

Btw, I just patched both my dvbv5-zap and dvbv5-scan applications to
work on that way.

Other GPL'd tools can just use my implementation as a reference if they
want, or write a simple code that will just add this on their code,
before checking if the delivery system matches their needs:

int set_delivery_system(uint32_t delivery_system)
{
	struct dtv_properties props;
	struct dtv_property dvb_prop[1];

       	dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
	dvb_prop[0].u.data = delivery_system;
        props.num = 1;
        props.props = dvb_prop;
        if (ioctl(fd, FE_SET_PROPERTY, &props) >= 0
		return 0;
	return errno;
}

Regards,
Mauro

PS.: As a reference, the enclosed patch adds support for changing the
delivery system at the dvb-apps scan.c. Similar changes are needed at
the other dvb-apps tools.

--
scan: allow it to work with multiple delivery-systems frontends

Add support for changing the delivery system to the one specified
at the channels/transponders file.

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

diff -r bec11f78be51 util/scan/scan.c
--- a/util/scan/scan.c	Wed Dec 07 15:26:50 2011 +0100
+++ b/util/scan/scan.c	Thu Jan 05 15:28:14 2012 -0500
@@ -1934,14 +1934,54 @@
 	return -1;
 }
 
+static set_delivery_system(int fd, unsigned type)
+{
+	struct dtv_properties props;
+	struct dtv_property dvb_prop[1];
+	unsigned delsys;
+
+	switch (type) {
+		case FE_QPSK:
+			delsys = SYS_DVBS;
+			break;
+		case FE_QAM:
+			delsys = SYS_DVBC_ANNEX_AC;
+			break;
+		case FE_OFDM:
+			delsys = SYS_DVBT;
+			break;
+		case FE_ATSC:
+			delsys = SYS_ATSC;
+			break;
+		default:
+			return -1;
+	}
+
+	dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
+	dvb_prop[0].u.data = delsys;
+	props.num = 1;
+	props.props = dvb_prop;
+	if (ioctl(fd, FE_SET_PROPERTY, &props) >= 0)
+		return 0;
+	return errno;
+}
+
 static int tune_to_transponder (int frontend_fd, struct transponder *t)
 {
+	int rc;
+
 	/* move TP from "new" to "scanned" list */
 	list_del_init(&t->list);
 	list_add_tail(&t->list, &scanned_transponders);
 	t->scan_done = 1;
 
 	if (t->type != fe_info.type) {
+		rc = set_delivery_system(frontend_fd, t->type);
+		if (!rc)
+			fe_info.type = t->type;
+	}
+
+	if (t->type != fe_info.type) {
 		warning("frontend type (%s) is not compatible with requested tuning type (%s)\n",
 				fe_type2str(fe_info.type),fe_type2str(t->type));
 		/* ignore cable descriptors in sat NIT and vice versa */

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Lars Hanisch]

Hi,

  First: I'm no driver but an application developer.

Am 05.01.2012 17:40, schrieb Devin Heitmueller:
> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com>  wrote:
>> With all these series applied, it is now possible to use frontend 0
>> for all delivery systems. As the current tools don't support changing
>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>> be used to change between them:
>
> Hi Mauro,
>
> While from a functional standpoint I think this is a good change (and
> we probably should have done it this way all along), is there not
> concern that this could be interpreted by regular users as a
> regression?  Right now they get two frontends, and they can use all
> their existing tools.  We're moving to a model where if users upgraded
> their kernel they would now require some new userland tool to do
> something that the kernel was allowing them to do previously.
>
> Sure, it's not "ABI breakage" in the classic sense but the net effect
> is the same - stuff that used to work stops working and now they need
> new tools or to recompile their existing tools to include new
> functionality (which as you mentioned, none of those tools have
> today).

  Since now there isn't any consistent behaviour of hybrid multifrontend devices. Some create multiple frontends but 
only one demux/dvr (like drx-k), others create all devices for every delivery system (HVR 4000). But they all could only 
be opened mutually exclusive. In case of vdr (my favourite app) you have to trick with udev, symlinks, "remove unwanted 
frontends" etc. to get the devices in a shape so the application can use it. I don't know how mythtv is handling such 
devices, but I think there will be something like driver-dependend code in the one or other way.

  The spec isn't really meaningful for hybrid devices. Maybe we should start there and claim something the driver 
developer can follow.

> Perhaps you would consider some sort of module option that would let
> users fall back to the old behavior?

  That would be fine but better would be a module option that will initialize frontend0 to the "connected" delivery 
system. In case of DVB-C/-T you don't switch frequently from one to the other. You would need extra hardware like a 
splitter which switches inputs if there are e.g. 5V for an active antenna (which means: switch to the dvb-t-input). Is 
there any DVB-T card which can supply such voltage? And is it controllable via an ioctl (like LNB power supply in DVB-S)?

  Anyway, I think, if there's finally a solution so all drivers behave the same, the tools and applications will handle 
this new model in the near future.

  Please do something... :-)

Regards,
Lars.

>
> Devin
>

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Mauro Carvalho Chehab]

On 05-01-2012 16:38, Lars Hanisch wrote:
> Hi,
> 
>  First: I'm no driver but an application developer.
> 
> Am 05.01.2012 17:40, schrieb Devin Heitmueller:
>> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com>  wrote:
>>> With all these series applied, it is now possible to use frontend 0
>>> for all delivery systems. As the current tools don't support changing
>>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>>> be used to change between them:
>>
>> Hi Mauro,
>>
>> While from a functional standpoint I think this is a good change (and
>> we probably should have done it this way all along), is there not
>> concern that this could be interpreted by regular users as a
>> regression?  Right now they get two frontends, and they can use all
>> their existing tools.  We're moving to a model where if users upgraded
>> their kernel they would now require some new userland tool to do
>> something that the kernel was allowing them to do previously.
>>
>> Sure, it's not "ABI breakage" in the classic sense but the net effect
>> is the same - stuff that used to work stops working and now they need
>> new tools or to recompile their existing tools to include new
>> functionality (which as you mentioned, none of those tools have
>> today).
> 
> Since now there isn't any consistent behaviour of hybrid multifrontend devices.
> Some create multiple frontends but only one demux/dvr (like drx-k), others create 
> all devices for every delivery system (HVR 4000). But they all could only be opened 
> mutually exclusive. In case of vdr (my favourite app) you have to trick with udev,
> symlinks, "remove unwanted frontends" etc. to get the devices in a shape so the 
> application can use it. I don't know how mythtv is handling such devices, but I 
> think there will be something like driver-dependend code in the one or other way.
> 
> The spec isn't really meaningful for hybrid devices. Maybe we should start 
> there and claim something the driver developer can follow.

We had some discussions about that at the KS workshop. All people there
agreed that the better is to use one frontend by physical device.

So, in the end of the day, all drivers should behave like what those DRX-K
patches are doing.

>> Perhaps you would consider some sort of module option that would let
>> users fall back to the old behavior?
> 
>  That would be fine but better would be a module option that will 
>  initialize frontend0 to the "connected" delivery system. In case of DVB-C/-T
>  you don't switch frequently from one to the other. You would need extra hardware 
>  like a splitter which switches inputs if there are e.g. 5V for an active antenna
>  (which means: switch to the dvb-t-input). Is there any DVB-T card which can supply
>  such voltage? And is it controllable via an ioctl (like LNB power supply in DVB-S)?

This is called LNA. A proper LNA support is missing. I think we should 
add a DVBv5 property to control it, on the devices that supports this feature.

The DRX-K chips described at the drxk_hard.c don't support such feature, but
there are other devices that supports it.

Btw, there are some DRX-K devices with two separate demods and two separate
frontends. A driver option won't work on such devices, as one frontend may
be connected to DVB-C, and the other one to DVB-T.

Also, the user may have more than one device of the same type (I have 3 sticks here
with em28xx/drx-k) that could be used simultaneously. Again, a modprobe
parameter won't fit, if the user wants to use some devices for one type, and
the other ones for the second type.

> 
>  Anyway, I think, if there's finally a solution so all drivers behave the same,
>  the tools and applications will handle this new model in the near future.

Yes, that's what we expect ;)

The DTV_ENUM_DELSYS and DTV_DELIVERY_SYSTEM properties are enough to
properly support such devices.
> 
>  Please do something... :-)
> 
> Regards,
> Lars.
> 
>>
>> Devin
>>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Oliver Endriss]

On Thursday 05 January 2012 17:40:54 Devin Heitmueller wrote:
> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > With all these series applied, it is now possible to use frontend 0
> > for all delivery systems. As the current tools don't support changing
> > the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
> > be used to change between them:
> 
> Hi Mauro,
> 
> While from a functional standpoint I think this is a good change (and
> we probably should have done it this way all along), is there not
> concern that this could be interpreted by regular users as a
> regression?  Right now they get two frontends, and they can use all
> their existing tools.  We're moving to a model where if users upgraded
> their kernel they would now require some new userland tool to do
> something that the kernel was allowing them to do previously.
> 
> Sure, it's not "ABI breakage" in the classic sense but the net effect
> is the same - stuff that used to work stops working and now they need
> new tools or to recompile their existing tools to include new
> functionality (which as you mentioned, none of those tools have
> today).
> 
> Perhaps you would consider some sort of module option that would let
> users fall back to the old behavior?

Imho it is not worth the effort. ;-)

Usually there is a single type of signal on the cable (for example
DVB-T or DVB-C, but not both). So the delivery system will not
change during normal operation.

If an old application cannot setup the delivery system,
and the default delivery system is the wrong one:
Run a small tool to setup to the desired delivery system.

Afterwards the old application will work 'as is' with the combined
frontend.

I see no major problems with the new behaviour.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Antti Palosaari]

On 01/05/2012 05:37 PM, Mauro Carvalho Chehab wrote:
> With all these series applied, it is now possible to use frontend 0
> for all delivery systems. As the current tools don't support changing
> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
> be used to change between them:
>
> For example, to use DVB-T with the standard scan:
>
> $ ./dvb-fe-tool -d DVBT&&  scan /usr/share/dvb/dvb-t/au-Adelaide
>
> [1] http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils

I tested that now using nanoStick T2 cxd2820r driver. I got it working 
somehow, but I suspect there is some bugs at least for DVB-C. But forget 
those as now.

As it now registers only one frontend I must switch mode using 
dvb-fe-tool when I want to use DVB-C. Argh.

I don't see reason why it was needed to remove old DVB-C frontend1. Why 
it wasn't possible to leave FE1 as it was and enhance only functionality 
of FE0 like it is now? For that strategy we doesn't break old set-ups as 
now happens.

regards
Antti


-- 
http://palosaari.fi/

Re: [PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

[Mauro Carvalho Chehab]

On 10-01-2012 19:45, Antti Palosaari wrote:
> On 01/05/2012 05:37 PM, Mauro Carvalho Chehab wrote:
>> With all these series applied, it is now possible to use frontend 0
>> for all delivery systems. As the current tools don't support changing
>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>> be used to change between them:
>>
>> For example, to use DVB-T with the standard scan:
>>
>> $ ./dvb-fe-tool -d DVBT&&  scan /usr/share/dvb/dvb-t/au-Adelaide
>>
>> [1] http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils
> 
> I tested that now using nanoStick T2 cxd2820r driver. I got it working somehow, but I suspect there is some bugs at least for DVB-C. But forget those as now.

Well, we need to hardly test the DVB drivers after a 200+ patch series.
Regressions will happen. I've cached a few already, but I'm sure there
are others that are not that trivial.

> As it now registers only one frontend I must switch mode using dvb-fe-tool when I want to use DVB-C. Argh.
> 
> I don't see reason why it was needed to remove old DVB-C frontend1. Why it wasn't possible to leave FE1
> as it was and enhance only functionality of FE0 like it is now? For that strategy we doesn't break old set-ups as now happens.

This were discussed in the past:

	http://www.spinics.net/lists/linux-media/msg35542.html

In fact, I've proposed this strategy as one of the alternatives for MFE
(approach 4):

>>>>> Approach 4) fe0 is a frontend "superset"
>>>>>
>>>>> *adapter0
>>>>> *frontend0 (DVB-S/DVB-S2/DVB-T/DVB-T2/DVB-C/ISDB-T) - aka: FE superset
>>>>> *frontend1 (DVB-S/DVB-S2)
>>>>> *frontend2 (DVB-T/DVB-T2)
>>>>> *frontend3 (DVB-C)
>>>>> *frontend4 (ISDB-T)

The arguments where that it would be confusing and it could be complex
to maintain.

I think that the better is to see what happens with the applications
during this kernel cycle, and then decide what to do. A quick fix for 
the issue at the applications side is very easy: for DVBv5.5 and upper,
just try to force the frontend to change to the new delivery system
via a DVBv5 call. If it accepts, it is a multi frontend devnode.

A better fix is to also implement DTV_ENUM_DELSYS.

Regards,
Mauro