[PATCH 1/2] em28xx: Fix DVB-C maxsize for em2884

[PATCH 1/2] em28xx: Fix DVB-C maxsize for em2884

[Mauro Carvalho Chehab]

The logic at em28xx_isoc_dvb_max_packetsize() sucks, at least for newer
chips: it just returns a magic number. There's no code there to guess
the needed packet size. Yet, it is better than nothing.

Rewrite the code in order to change the default to 752 for em2884 and
newer chips and provide a better way to handle per-chipset specifics.

For em2874, the current default should be enough, as the only em2874
board is currently a 1-seg ISDB-T board, so, it needs only a limited
amount of bandwidth.

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

diff --git a/drivers/media/video/em28xx/em28xx-core.c b/drivers/media/video/em28xx/em28xx-core.c
index ee0acd8..57b1b5c 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -1113,17 +1113,19 @@ EXPORT_SYMBOL_GPL(em28xx_init_isoc);
 int em28xx_isoc_dvb_max_packetsize(struct em28xx *dev)
 {
 	unsigned int chip_cfg2;
-	unsigned int packet_size = 564;
+	unsigned int packet_size;
 
-	if (dev->chip_id == CHIP_ID_EM2874) {
-		/* FIXME - for now assume 564 like it was before, but the
-		   em2874 code should be added to return the proper value... */
-		packet_size = 564;
-	} else if (dev->chip_id == CHIP_ID_EM28174 || dev->chip_id == CHIP_ID_EM2884) {
-		/* FIXME same as em2874. 564 was enough for 22 Mbit DVB-T
-		   but too much for 44 Mbit DVB-C. */
-		packet_size = 752;
-	} else {
+	switch (dev->chip_id) {
+	case CHIP_ID_EM2710:
+	case CHIP_ID_EM2750:
+	case CHIP_ID_EM2800:
+	case CHIP_ID_EM2820:
+	case CHIP_ID_EM2840:
+	case CHIP_ID_EM2860:
+		/* No DVB support */
+		return -EINVAL;
+	case CHIP_ID_EM2870:
+	case CHIP_ID_EM2883:
 		/* TS max packet size stored in bits 1-0 of R01 */
 		chip_cfg2 = em28xx_read_reg(dev, EM28XX_R01_CHIPCFG2);
 		switch (chip_cfg2 & EM28XX_CHIPCFG2_TS_PACKETSIZE_MASK) {
@@ -1140,9 +1142,24 @@ int em28xx_isoc_dvb_max_packetsize(struct em28xx *dev)
 			packet_size = 752;
 			break;
 		}
+		break;
+	case CHIP_ID_EM2874:
+		/*
+		 * FIXME: for now assumes 564 like it was before, but the
+		 * em2874 code should be added to return the proper value
+		 */
+		packet_size = 564;
+		break;
+	case CHIP_ID_EM2884:
+	case CHIP_ID_EM28174:
+	default:
+		/*
+		 * FIXME: same as em2874. 564 was enough for 22 Mbit DVB-T
+		 * but not enough for 44 Mbit DVB-C.
+		 */
+		packet_size = 752;
 	}
 
-	em28xx_coredbg("dvb max packet size=%d\n", packet_size);
 	return packet_size;
 }
 EXPORT_SYMBOL_GPL(em28xx_isoc_dvb_max_packetsize);
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c b/drivers/media/video/em28xx/em28xx-dvb.c
index ab8a740..e5916de 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -167,6 +167,11 @@ static int start_streaming(struct em28xx_dvb *dvb)
 		return rc;
 
 	max_dvb_packet_size = em28xx_isoc_dvb_max_packetsize(dev);
+	if (max_dvb_packet_size < 0)
+		return max_dvb_packet_size;
+	dprintk(1, "Using %d buffers each with %d bytes\n",
+		EM28XX_DVB_NUM_BUFS,
+		max_dvb_packet_size);
 
 	return em28xx_init_isoc(dev, EM28XX_DVB_MAX_PACKETS,
 				EM28XX_DVB_NUM_BUFS, max_dvb_packet_size,
-- 
1.7.1

[PATCH 2/2] tda18271c2dd: Fix saw filter configuration for DVB-6 @ 6MHz

[Mauro Carvalho Chehab]

Currently, the driver assumes that all QAM carriers are spaced with
8MHz. This is wrong, and may decrease QoS on Countries like Brazil,
that have DVB-C carriers with 6MHz-spaced.

Fortunately, both ITU-T J-83 and EN 300 429 specifies a way to
associate the symbol rate with the bandwidth needed for it.

For ITU-T J-83 2007 annex A, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.15 = 5217391 Bauds
For  ITU-T J-83 2007 annex C, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.13 = 5309735 Bauds.

As this tuner is currently used only for DRX-K, and it is currently
hard-coded to annex A, I've opted to use the roll-off factor of 0.15,
instead of 0.13.

If we ever support annex C, the better would be to add a DVB S2API
call to allow changing between Annex A and C, and add the 0.13 roll-off
factor to it.

This code is currently being used on other frontends, so I think we
should later add a core function with this code, to warrant that
it will be properly implemented everywhere.

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

diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c b/drivers/media/dvb/frontends/tda18271c2dd.c
index 2eb3a31..9aa4c09 100644
--- a/drivers/media/dvb/frontends/tda18271c2dd.c
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -1123,6 +1123,21 @@ static int release(struct dvb_frontend *fe)
 	return 0;
 }
 
+/*
+ * As defined on EN 300 429 Annex A and on ITU-T J.83 annex A, the DVB-C
+ * roll-off factor is 0.15.
+ * According with the specs, the amount of the needed bandwith is given by:
+ * 	Bw = Symbol_rate * (1 + 0.15)
+ * As such, the maximum symbol rate supported by 6 MHz is
+ *	max_symbol_rate = 6 MHz / 1.15 = 5217391 Bauds
+ *NOTE: For ITU-T J.83 Annex C, the roll-off factor is 0.13. So:
+ *	max_symbol_rate = 6 MHz / 1.13 = 5309735 Baud
+ *	That means that an adjustment is needed for Japan,
+ *	but, as currently DRX-K is hardcoded to Annex A, let's stick
+ *	with 0.15 roll-off factor.
+ */
+#define MAX_SYMBOL_RATE_6MHz	5217391
+
 static int set_params(struct dvb_frontend *fe,
 		      struct dvb_frontend_parameters *params)
 {
@@ -1146,7 +1161,10 @@ static int set_params(struct dvb_frontend *fe,
 			break;
 		}
 	else if (fe->ops.info.type == FE_QAM) {
-		Standard = HF_DVBC_8MHZ;
+		if (params->u.qam.symbol_rate <= MAX_SYMBOL_RATE_6MHz)
+			Standard = HF_DVBC_6MHZ;
+		else
+			Standard = HF_DVBC_8MHZ;
 	} else
 		return -EINVAL;
 	do {
-- 
1.7.1