[PATCH RFCv10 00/15] DVB QoS statistics API

[PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Add DVBv5 methods to retrieve QoS statistics.

Those methods allow per-layer and global statistics.

Implemented 2 QoS statistics on mb86a20s, one global only
(signal strengh), and one per layer (BER).

Tested with a modified version of dvbv5-zap, that allows monitoring
those stats. Test data follows

Tested with 1-segment at layer A, and 12-segment at layer B:

[ 3735.973058] i2c i2c-4: mb86a20s_layer_bitrate: layer A bitrate: 440 kbps; counter = 196608 (0x030000)
[ 3735.976803] i2c i2c-4: mb86a20s_layer_bitrate: layer B bitrate: 16851 kbps; counter = 8257536 (0x7e0000)

a) Global stats:

Signal strength:
	QOS_SIGNAL_STRENGTH[0] = 4096

BER (sum of BE count and bit counts for both layers):
	QOS_BIT_ERROR_COUNT[0] = 1087865
	QOS_TOTAL_BITS_COUNT[0] = 67043313

b) Per-layer stats:

Layer A BER:
	QOS_BIT_ERROR_COUNT[1] = 236
	QOS_TOTAL_BITS_COUNT[1] = 917490

Layer B BER:
	QOS_BIT_ERROR_COUNT[2] = 1087629
	QOS_TOTAL_BITS_COUNT[2] = 66125823

TODO:
	- add more statistics at mb86a20s;
	- implement support for DTV_QOS_ENUM;
	- some cleanups at get_frontend logic at dvb core, to avoid
	  it to be called outside the DVB thread loop.

All the above changes can be done a little later during this development
cycle, so my plan is to merge it upstream at the beginning of the 
next week, to allow others to test.

I added an ugly hack on my experimental v4l-utils tree, to allow
testing it:
	http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/stats

GIT url for it is:
	git://linuxtv.org/mchehab/experimental-v4l-utils.git stats


---

    v6: Add DocBook documentation.
    v7: Some fixes as suggested by Antti
    v8: Documentation fix, compilation fix and name the stats struct,
        for its reusage inside the core
    v9: counters need 32 bits. So, change the return data types to
        s32/u32 types
    v10: Counters changed to 64 bits for monotonic increment
	 Don't create a separate get_stats callback. get_frontend
	 is already good enough for it.


Mauro Carvalho Chehab (15):
  mb86a20s: improve error handling at get_frontend
  dvb: Add DVBv5 stats properties for Quality of Service
  dvb: the core logic to handle the DVBv5 QoS properties
  mb86a20s: Update QoS statistics at FE read_status
  mb86a20s: functions reorder
  mb86a20s: Fix i2c gate on error
  mb86a20s: improve debug for RF level
  mb86a20s: fix interleaving and FEC retrival
  mb86a20s: convert it to use dev_info/dev_err/dev_dbg
  mb86a20s: -EBUSY is expected when getting QoS measures
  mb86a20s: make AGC work better
  mb86a20s: Some improvements for BER measurement
  mb86a20s: improve bit error count for BER
  dvb: increase API version
  mb86a20s: global stat is just a sum, and not an increment

 Documentation/DocBook/media/dvb/dvbapi.xml      |    2 +-
 Documentation/DocBook/media/dvb/dvbproperty.xml |  115 ++-
 drivers/media/dvb-core/dvb_frontend.c           |   53 ++
 drivers/media/dvb-core/dvb_frontend.h           |   11 +
 drivers/media/dvb-frontends/mb86a20s.c          | 1024 ++++++++++++++++++-----
 include/uapi/linux/dvb/frontend.h               |   83 +-
 include/uapi/linux/dvb/version.h                |    2 +-
 7 files changed, 1066 insertions(+), 224 deletions(-)

-- 
1.7.11.7

[PATCH RFCv10 01/15] mb86a20s: improve error handling at get_frontend

[Mauro Carvalho Chehab]

The read/write errors are not handled well on get_frontend. Fix it,
by letting the frontend cached values to represent the DVB properties
that were successfully retrieved.

While here, use "c" for dtv_frontend_properties cache, instead of
"p", as this is more common.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 138 +++++++++++++++++++--------------
 1 file changed, 80 insertions(+), 58 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index fade566..4ff3a0c 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -1,11 +1,9 @@
 /*
  *   Fujitu mb86a20s ISDB-T/ISDB-Tsb Module driver
  *
- *   Copyright (C) 2010 Mauro Carvalho Chehab <mchehab@redhat.com>
+ *   Copyright (C) 2010-2013 Mauro Carvalho Chehab <mchehab@redhat.com>
  *   Copyright (C) 2009-2010 Douglas Landgraf <dougsland@redhat.com>
  *
- *   FIXME: Need to port to DVB v5.2 API
- *
  *   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 version 2.
@@ -360,7 +358,7 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
 	/*
 	 * FIXME: Properly implement the set frontend properties
 	 */
-	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 #endif
 
 	dprintk("\n");
@@ -507,93 +505,117 @@ static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
 	return count;
 }
 
+static void mb86a20s_reset_frontend_cache(struct dvb_frontend *fe)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+	/* Fixed parameters */
+	c->delivery_system = SYS_ISDBT;
+	c->bandwidth_hz = 6000000;
+
+	/* Initialize values that will be later autodetected */
+	c->isdbt_layer_enabled = 0;
+	c->transmission_mode = TRANSMISSION_MODE_AUTO;
+	c->guard_interval = GUARD_INTERVAL_AUTO;
+	c->isdbt_sb_mode = 0;
+	c->isdbt_sb_segment_count = 0;
+}
+
 static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
-	struct dtv_frontend_properties *p = &fe->dtv_property_cache;
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int i, rc;
 
-	/* Fixed parameters */
-	p->delivery_system = SYS_ISDBT;
-	p->bandwidth_hz = 6000000;
+	/* Reset frontend cache to default values */
+	mb86a20s_reset_frontend_cache(fe);
 
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
 
 	/* Check for partial reception */
 	rc = mb86a20s_writereg(state, 0x6d, 0x85);
-	if (rc >= 0)
-		rc = mb86a20s_readreg(state, 0x6e);
-	if (rc >= 0)
-		p->isdbt_partial_reception = (rc & 0x10) ? 1 : 0;
+	if (rc < 0)
+		return rc;
+	rc = mb86a20s_readreg(state, 0x6e);
+	if (rc < 0)
+		return rc;
+	c->isdbt_partial_reception = (rc & 0x10) ? 1 : 0;
 
 	/* Get per-layer data */
-	p->isdbt_layer_enabled = 0;
+
 	for (i = 0; i < 3; i++) {
 		rc = mb86a20s_get_segment_count(state, i);
-			if (rc >= 0 && rc < 14)
-				p->layer[i].segment_count = rc;
-		if (rc == 0x0f)
+		if (rc < 0)
+			goto error;
+		if (rc >= 0 && rc < 14)
+			c->layer[i].segment_count = rc;
+		else {
+			c->layer[i].segment_count = 0;
 			continue;
-		p->isdbt_layer_enabled |= 1 << i;
+		}
+		c->isdbt_layer_enabled |= 1 << i;
 		rc = mb86a20s_get_modulation(state, i);
-			if (rc >= 0)
-				p->layer[i].modulation = rc;
+		if (rc < 0)
+			goto error;
+		c->layer[i].modulation = rc;
 		rc = mb86a20s_get_fec(state, i);
-			if (rc >= 0)
-				p->layer[i].fec = rc;
+		if (rc < 0)
+			goto error;
+		c->layer[i].fec = rc;
 		rc = mb86a20s_get_interleaving(state, i);
-			if (rc >= 0)
-				p->layer[i].interleaving = rc;
+		if (rc < 0)
+			goto error;
+		c->layer[i].interleaving = rc;
 	}
 
-	p->isdbt_sb_mode = 0;
 	rc = mb86a20s_writereg(state, 0x6d, 0x84);
-	if ((rc >= 0) && ((rc & 0x60) == 0x20)) {
-		p->isdbt_sb_mode = 1;
+	if (rc < 0)
+		return rc;
+	if ((rc & 0x60) == 0x20) {
+		c->isdbt_sb_mode = 1;
 		/* At least, one segment should exist */
-		if (!p->isdbt_sb_segment_count)
-			p->isdbt_sb_segment_count = 1;
-	} else
-		p->isdbt_sb_segment_count = 0;
+		if (!c->isdbt_sb_segment_count)
+			c->isdbt_sb_segment_count = 1;
+	}
 
 	/* Get transmission mode and guard interval */
-	p->transmission_mode = TRANSMISSION_MODE_AUTO;
-	p->guard_interval = GUARD_INTERVAL_AUTO;
 	rc = mb86a20s_readreg(state, 0x07);
-	if (rc >= 0) {
-		if ((rc & 0x60) == 0x20) {
-			switch (rc & 0x0c >> 2) {
-			case 0:
-				p->transmission_mode = TRANSMISSION_MODE_2K;
-				break;
-			case 1:
-				p->transmission_mode = TRANSMISSION_MODE_4K;
-				break;
-			case 2:
-				p->transmission_mode = TRANSMISSION_MODE_8K;
-				break;
-			}
+	if (rc < 0)
+		return rc;
+	if ((rc & 0x60) == 0x20) {
+		switch (rc & 0x0c >> 2) {
+		case 0:
+			c->transmission_mode = TRANSMISSION_MODE_2K;
+			break;
+		case 1:
+			c->transmission_mode = TRANSMISSION_MODE_4K;
+			break;
+		case 2:
+			c->transmission_mode = TRANSMISSION_MODE_8K;
+			break;
 		}
-		if (!(rc & 0x10)) {
-			switch (rc & 0x3) {
-			case 0:
-				p->guard_interval = GUARD_INTERVAL_1_4;
-				break;
-			case 1:
-				p->guard_interval = GUARD_INTERVAL_1_8;
-				break;
-			case 2:
-				p->guard_interval = GUARD_INTERVAL_1_16;
-				break;
-			}
+	}
+	if (!(rc & 0x10)) {
+		switch (rc & 0x3) {
+		case 0:
+			c->guard_interval = GUARD_INTERVAL_1_4;
+			break;
+		case 1:
+			c->guard_interval = GUARD_INTERVAL_1_8;
+			break;
+		case 2:
+			c->guard_interval = GUARD_INTERVAL_1_16;
+			break;
 		}
 	}
 
+error:
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
 
-	return 0;
+	return rc;
+
 }
 
 static int mb86a20s_tune(struct dvb_frontend *fe,
-- 
1.7.11.7

[PATCH RFCv10 02/15] dvb: Add DVBv5 stats properties for Quality of Service

[Mauro Carvalho Chehab]

The DVBv3 quality parameters are limited on several ways:

        - Doesn't provide any way to indicate the used measure,
	  so userspace need to guess how to calculate the measure;

        - Only a limited set of stats are supported;

        - Can't be called in a way to require them to be filled
          all at once (atomic reads from the hardware), with may
          cause troubles on interpreting them on userspace;

        - On some OFDM delivery systems, the carriers can be
          independently modulated, having different properties.
          Currently, there's no way to report per-layer stats.

To address the above issues, adding a new DVBv5-based stats
API.

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

---

v6: Add DocBook documentation.
v7: Some fixes as suggested by Antti
v8: Documentation fix, compilation fix and name the stats struct,
    for its reusage inside the core
v9: counters need 32 bits. So, change the return data types to
    s32/u32 types
v10: Counters changed to 64 bits for monotonic increment
---
 Documentation/DocBook/media/dvb/dvbproperty.xml | 115 +++++++++++++++++++++++-
 include/uapi/linux/dvb/frontend.h               |  83 ++++++++++++++++-
 2 files changed, 195 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 957e3ac..b46a3d8 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -7,16 +7,46 @@ the capability ioctls weren't implemented yet via the new way.</para>
 <para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
 API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
 struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
+<section id="dtv-stats">
+<title>DTV stats type</title>
+<programlisting>
+struct dtv_stats {
+	__u8 scale;	/* enum fecap_scale_params type */
+	union {
+		__u64 uvalue;	/* for counters and relative scales */
+		__s64 svalue;	/* for 0.1 dB measures */
+	};
+} __attribute__ ((packed));
+</programlisting>
+</section>
+<section id="dtv-fe-stats">
+<title>DTV stats type</title>
+<programlisting>
+#define MAX_QOS_STATS   4
+
+struct dtv_fe_stats {
+	__u8 len;
+	struct dtv_stats stat[MAX_QOS_STATS];
+} __attribute__ ((packed));
+</programlisting>
+</section>
+
 <section id="dtv-property">
 <title>DTV property type</title>
 <programlisting>
 /* Reserved fields should be set to 0 */
+
 struct dtv_property {
 	__u32 cmd;
+	__u32 reserved[3];
 	union {
 		__u32 data;
+		struct dtv_fe_stats st;
 		struct {
-			__u8 data[32];
+			union {
+				__u8 data[32];
+				__u16 data16[16];
+			};
 			__u32 len;
 			__u32 reserved1[3];
 			void *reserved2;
@@ -850,6 +880,79 @@ enum fe_interleaving {
 	<para>use the special macro LNA_AUTO to set LNA auto</para>
 	</section>
 </section>
+
+	<section id="frontend-qos-properties">
+	<title>Frontend Quality of Service/Statistics indicators</title>
+	<para>Except for <link linkend="DTV-QOS-ENUM"><constant>DTV_QOS_ENUM</constant></link>,
+	the values are returned via <constant>dtv_property.stat</constant>.</para>
+	<para>For most delivery systems, this will return a single value for each parameter.</para>
+	<para>It should be noticed, however, that new OFDM delivery systems
+	like ISDB can use different modulation types for each group of carriers.
+	On such standards, up to 3 groups of statistics can be provided, one
+	for each carrier group (called "layer" on ISDB).
+	In order to be consistent with other delivery systems, the first
+	value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link> array refers to
+	a global indicator, if any. The other elements of the array represent
+	each layer, starting from layer A(index 1), layer B (index 2) and so on</para>
+	<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
+	<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
+	<itemizedlist mark='opencircle'>
+		<listitem><para><constant>value</constant> - Value of the measure</para></listitem>
+		<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
+			<section id = "fecap-scale-params">
+			<itemizedlist mark='bullet'>
+				<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - If it is not possible to collect a given parameter (could be a transitory or permanent condition)</para></listitem>
+				<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 0.1 dB</para></listitem>
+				<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
+				<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
+			</itemizedlist>
+			</section>
+		</listitem>
+	</itemizedlist>
+	<section id="DTV-QOS-ENUM">
+		<title><constant>DTV_QOS_ENUM</constant></title>
+		<para>A frontend needs to advertise the statistics it provides. This property allows to enumerate all
+			<link linkend="frontend-qos-properties">DTV QoS statistics</link> that are
+			supported by a given frontend.</para>
+
+		<para><constant>dtv_property.len</constant> indicates the number of supported
+		<link linkend="frontend-qos-properties">DTV QoS statistics</link>.</para>
+		<para><constant>dtv_property.data16</constant> is an 16 bits array of the supported properties.</para>
+	</section>
+	<section id="DTV-QOS-SIGNAL-STRENGTH">
+		<title><constant>DTV_QOS_SIGNAL_STRENGTH</constant></title>
+		<para>Indicates the signal strength level at the analog part of the tuner.</para>
+		<para>When measured in 0.1 dB scale(<link linkend="fecap-scale-params"><constant>FE_SCALE_DECIBEL</constant></link>), is measured in mili Watts, e. g.,  a value of 1 means 0.1 dBm.</para>
+	</section>
+	<section id="DTV-QOS-CNR">
+		<title><constant>DTV_QOS_CNR</constant></title>
+		<para>Indicates the signal to noise relation for the main carrier.</para>
+
+	</section>
+	<section id="DTV-QOS-BIT-ERROR-COUNT">
+		<title><constant>DTV_QOS_BIT_ERROR_COUNT</constant></title>
+		<para>Measures the number of bit errors since the last counter reset.</para>
+		<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+		<link linkend="DTV-QOS-TOTAL-BITS-COUNT"><constant>DTV_QOS_TOTAL_BITS_COUNT</constant></link>.</para>
+	</section>
+	<section id="DTV-QOS-TOTAL-BITS-COUNT">
+		<title><constant>DTV_QOS_TOTAL_BITS_COUNT</constant></title>
+		<para>Measures the amount of bits received since the last <link linkend="DTV-QOS-BIT-ERROR-COUNT"><constant>DTV_QOS_BIT_ERROR_COUNT</constant></link> reset.</para>
+	</section>
+	<section id="DTV-QOS-ERROR-BLOCK-COUNT">
+		<title><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></title>
+		<para>Measures the number of block errors since the last counter reset.</para>
+	</section>
+	<section id="DTV-QOS-TOTAL-BLOCKS-COUNT">
+		<title><constant>DTV-QOS_TOTAL_BLOCKS_COUNT</constant></title>
+		<para>Measures the total number of blocks since the last
+		<link linkend="DTV-QOS-ERROR-BLOCK-COUNT"><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></link> reset.</para>
+		<para>It can be used to calculate the PER indicator, by dividing
+		<link linkend="DTV-QOS-ERROR-BLOCK-COUNT"><constant>DTV_QOS_ERROR_BLOCK_COUNT</constant></link>
+		by <link linkend="DTV-QOS-TOTAL-BLOCKS-COUNT"><constant>DTV-QOS-TOTAL-BLOCKS-COUNT</constant></link>.</para>
+	</section>
+	</section>
+
 	<section id="frontend-property-terrestrial-systems">
 	<title>Properties used on terrestrial delivery systems</title>
 		<section id="dvbt-params">
@@ -871,6 +974,7 @@ enum fe_interleaving {
 				<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
 				<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
 			</itemizedlist>
+			<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 		<section id="dvbt2-params">
 			<title>DVB-T2 delivery system</title>
@@ -895,6 +999,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 		<section id="isdbt">
 		<title>ISDB-T delivery system</title>
@@ -948,6 +1053,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 		<section id="atsc-params">
 			<title>ATSC delivery system</title>
@@ -961,6 +1067,7 @@ enum fe_interleaving {
 				<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
 				<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
 			</itemizedlist>
+			<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 		<section id="atscmh-params">
 			<title>ATSC-MH delivery system</title>
@@ -988,6 +1095,7 @@ enum fe_interleaving {
 				<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
 				<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
 			</itemizedlist>
+			<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 		<section id="dtmb-params">
 			<title>DTMB delivery system</title>
@@ -1007,6 +1115,7 @@ enum fe_interleaving {
 				<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
 				<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
 			</itemizedlist>
+			<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		</section>
 	</section>
 	<section id="frontend-property-cable-systems">
@@ -1028,6 +1137,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 	</section>
 	<section id="dvbc-annex-b-params">
 		<title>DVB-C Annex B delivery system</title>
@@ -1043,6 +1153,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 	</section>
 	</section>
 	<section id="frontend-property-satellital-systems">
@@ -1062,6 +1173,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 		<para>Future implementations might add those two missing parameters:</para>
 		<itemizedlist mark='opencircle'>
 			<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@@ -1077,6 +1189,7 @@ enum fe_interleaving {
 			<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
 			<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
 		</itemizedlist>
+		<para>In addition, the <link linkend="frontend-qos-properties">DTV QoS statistics</link> are also valid.</para>
 	</section>
 	<section id="turbo-params">
 		<title>Turbo code delivery system</title>
diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h
index c12d452..e9dc164 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -365,7 +365,16 @@ struct dvb_frontend_event {
 #define DTV_INTERLEAVING			60
 #define DTV_LNA					61
 
-#define DTV_MAX_COMMAND				DTV_LNA
+/* Quality parameters */
+#define DTV_QOS_ENUM			62
+#define DTV_QOS_SIGNAL_STRENGTH		63
+#define DTV_QOS_CNR			64
+#define DTV_QOS_BIT_ERROR_COUNT		65
+#define DTV_QOS_TOTAL_BITS_COUNT	66
+#define DTV_QOS_ERROR_BLOCK_COUNT	67
+#define DTV_QOS_TOTAL_BLOCKS_COUNT	68
+
+#define DTV_MAX_COMMAND		DTV_QOS_TOTAL_BLOCKS_COUNT
 
 typedef enum fe_pilot {
 	PILOT_ON,
@@ -452,13 +461,83 @@ struct dtv_cmds_h {
 	__u32	reserved:30;	/* Align */
 };
 
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_NOT_AVAILABLE: That QoS measure is not available. That
+ *			    could indicate a temporary or a permanent
+ *			    condition.
+ * @FE_SCALE_DECIBEL: The scale is measured in 0.1 dB steps, typically
+ *		  used on signal measures.
+ * @FE_SCALE_RELATIVE: The scale is a relative percentual measure,
+ *			ranging from 0 (0%) to 0xffff (100%).
+ * @FE_SCALE_COUNTER: The scale counts the occurrence of an event, like
+ *			bit error, block error, lapsed time.
+ */
+enum fecap_scale_params {
+	FE_SCALE_NOT_AVAILABLE = 0,
+	FE_SCALE_DECIBEL,
+	FE_SCALE_RELATIVE,
+	FE_SCALE_COUNTER
+};
+
+/**
+ * struct dtv_stats - Used for reading a DTV status property
+ *
+ * @value:	value of the measure. Should range from 0 to 0xffff;
+ * @scale:	Filled with enum fecap_scale_params - the scale
+ *		in usage for that parameter
+ *
+ * For most delivery systems, this will return a single value for each
+ * parameter.
+ * It should be noticed, however, that new OFDM delivery systems like
+ * ISDB can use different modulation types for each group of carriers.
+ * On such standards, up to 8 groups of statistics can be provided, one
+ * for each carrier group (called "layer" on ISDB).
+ * In order to be consistent with other delivery systems, the first
+ * value refers to the entire set of carriers ("global").
+ * dtv_status:scale should use the value FE_SCALE_NOT_AVAILABLE when
+ * the value for the entire group of carriers or from one specific layer
+ * is not provided by the hardware.
+ * st.len should be filled with the latest filled status + 1.
+ *
+ * In other words, for ISDB, those values should be filled like:
+ *	u.st.stat.svalue[0] = global statistics;
+ *	u.st.stat.scale[0] = FE_SCALE_DECIBELS;
+ *	u.st.stat.value[1] = layer A statistics;
+ *	u.st.stat.scale[1] = FE_SCALE_NOT_AVAILABLE (if not available);
+ *	u.st.stat.svalue[2] = layer B statistics;
+ *	u.st.stat.scale[2] = FE_SCALE_DECIBELS;
+ *	u.st.stat.svalue[3] = layer C statistics;
+ *	u.st.stat.scale[3] = FE_SCALE_DECIBELS;
+ *	u.st.len = 4;
+ */
+struct dtv_stats {
+	__u8 scale;	/* enum fecap_scale_params type */
+	union {
+		__u64 uvalue;	/* for counters and relative scales */
+		__s64 svalue;	/* for 0.1 dB measures */
+	};
+} __attribute__ ((packed));
+
+
+#define MAX_QOS_STATS   4
+
+struct dtv_fe_stats {
+	__u8 len;
+	struct dtv_stats stat[MAX_QOS_STATS];
+} __attribute__ ((packed));
+
 struct dtv_property {
 	__u32 cmd;
 	__u32 reserved[3];
 	union {
 		__u32 data;
+		struct dtv_fe_stats st;
 		struct {
-			__u8 data[32];
+			union {
+				__u8 data[32];
+				__u16 data16[16];
+			};
 			__u32 len;
 			__u32 reserved1[3];
 			void *reserved2;
-- 
1.7.11.7

[PATCH RFCv10 03/15] dvb: the core logic to handle the DVBv5 QoS properties

[Mauro Carvalho Chehab]

Add the logic to poll, reset counters and report the QoS stats
to the end user.

The idea is that the core will periodically poll the frontend for
the stats. The frontend may return -EBUSY, if the previous collect
didn't finish, or it may fill the cached data.

The value returned to the end user is always the cached data.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-core/dvb_frontend.c | 53 +++++++++++++++++++++++++++++++++++
 drivers/media/dvb-core/dvb_frontend.h | 11 ++++++++
 2 files changed, 64 insertions(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index dd35fa9..e48e46fb 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1053,6 +1053,15 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
 	_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_B, 0, 0),
 	_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_C, 0, 0),
 	_DTV_CMD(DTV_ATSCMH_SCCC_CODE_MODE_D, 0, 0),
+
+	/* Statistics API */
+	_DTV_CMD(DTV_QOS_ENUM, 0, 0),
+	_DTV_CMD(DTV_QOS_SIGNAL_STRENGTH, 0, 0),
+	_DTV_CMD(DTV_QOS_CNR, 0, 0),
+	_DTV_CMD(DTV_QOS_BIT_ERROR_COUNT, 0, 0),
+	_DTV_CMD(DTV_QOS_TOTAL_BITS_COUNT, 0, 0),
+	_DTV_CMD(DTV_QOS_ERROR_BLOCK_COUNT, 0, 0),
+	_DTV_CMD(DTV_QOS_TOTAL_BLOCKS_COUNT, 0, 0),
 };
 
 static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property *tvp)
@@ -1443,6 +1452,25 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
 		tvp->u.data = c->lna;
 		break;
 
+	/* Fill quality measures */
+	case DTV_QOS_SIGNAL_STRENGTH:
+		tvp->u.st = c->strength;
+		break;
+	case DTV_QOS_CNR:
+		tvp->u.st = c->cnr;
+		break;
+	case DTV_QOS_BIT_ERROR_COUNT:
+		tvp->u.st = c->bit_error;
+		break;
+	case DTV_QOS_TOTAL_BITS_COUNT:
+		tvp->u.st = c->bit_count;
+		break;
+	case DTV_QOS_ERROR_BLOCK_COUNT:
+		tvp->u.st = c->block_error;
+		break;
+	case DTV_QOS_TOTAL_BLOCKS_COUNT:
+		tvp->u.st = c->block_count;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -1646,6 +1674,26 @@ static int set_delivery_system(struct dvb_frontend *fe, u32 desired_system)
 	return 0;
 }
 
+static int reset_qos_counters(struct dvb_frontend *fe)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+	/* Reset QoS cache */
+
+	memset (&c->strength, 0, sizeof(c->strength));
+	memset (&c->cnr, 0, sizeof(c->cnr));
+	memset (&c->bit_error, 0, sizeof(c->bit_error));
+	memset (&c->bit_count, 0, sizeof(c->bit_count));
+	memset (&c->block_error, 0, sizeof(c->block_error));
+	memset (&c->block_count, 0, sizeof(c->block_count));
+
+	/* Call frontend reset counter method, if available */
+	if (fe->ops.reset_qos_counters)
+		return fe->ops.reset_qos_counters(fe);
+
+	return 0;
+}
+
 static int dtv_property_process_set(struct dvb_frontend *fe,
 				    struct dtv_property *tvp,
 				    struct file *file)
@@ -1705,6 +1753,8 @@ static int dtv_property_process_set(struct dvb_frontend *fe,
 		break;
 	case DTV_DELIVERY_SYSTEM:
 		r = set_delivery_system(fe, tvp->u.data);
+		if (r >= 0)
+			reset_qos_counters(fe);
 		break;
 	case DTV_VOLTAGE:
 		c->voltage = tvp->u.data;
@@ -2305,6 +2355,9 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 		if (err)
 			break;
 		err = dtv_set_frontend(fe);
+		if (err >= 0)
+			reset_qos_counters(fe);
+
 		break;
 	case FE_GET_EVENT:
 		err = dvb_frontend_get_event (fe, parg, file->f_flags);
diff --git a/drivers/media/dvb-core/dvb_frontend.h b/drivers/media/dvb-core/dvb_frontend.h
index 97112cd..b7aa815 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -315,6 +315,9 @@ struct dvb_frontend_ops {
 
 	int (*set_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
 	int (*get_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
+
+	/* QoS statistics callbacks */
+	int (*reset_qos_counters)(struct dvb_frontend *fe);
 };
 
 #ifdef __DVB_CORE__
@@ -393,6 +396,14 @@ struct dtv_frontend_properties {
 	u8			atscmh_sccc_code_mode_d;
 
 	u32			lna;
+
+	/* QoS statistics data */
+	struct dtv_fe_stats 	strength;
+	struct dtv_fe_stats	cnr;
+	struct dtv_fe_stats	bit_error;
+	struct dtv_fe_stats	bit_count;
+	struct dtv_fe_stats	block_error;
+	struct dtv_fe_stats	block_count;
 };
 
 struct dvb_frontend {
-- 
1.7.11.7

[PATCH RFCv10 04/15] mb86a20s: Update QoS statistics at FE read_status

[Mauro Carvalho Chehab]

Instead of providing separate callbacks to read the several FE
status properties, the better seems to use just one method that will:

    - Read lock status;
    - Read signal strength;
    - if locked, get TMCC data;
    - if locked, get DVB status.

As the DVB frontend thread will call this method on every 3 seconds,
all QoS data will be updated together, with is a good thing.

It also prevents userspace to generate undesired I2C traffic.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 372 +++++++++++++++++++++++++++++----
 1 file changed, 336 insertions(+), 36 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 4ff3a0c..0f8d9bc 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -43,6 +43,12 @@ struct mb86a20s_state {
 	struct dvb_frontend frontend;
 
 	bool need_init;
+
+	/*
+	 * QoS measure flags to be used to know when it is possible to
+	 * artificially generate a "global" measure, based on all 3 layers
+	 */
+	bool read_ber[3];
 };
 
 struct regdata {
@@ -92,7 +98,7 @@ static struct regdata mb86a20s_init[] = {
 	{ 0x04, 0x13 }, { 0x05, 0xff },
 	{ 0x04, 0x15 }, { 0x05, 0x4e },
 	{ 0x04, 0x16 }, { 0x05, 0x20 },
-	{ 0x52, 0x01 },
+	{ 0x52, 0x01 },				/* Turn on BER before Viterbi */
 	{ 0x50, 0xa7 }, { 0x51, 0xff },
 	{ 0x50, 0xa8 }, { 0x51, 0xff },
 	{ 0x50, 0xa9 }, { 0x51, 0xff },
@@ -117,8 +123,8 @@ static struct regdata mb86a20s_init[] = {
 	{ 0x50, 0xb6 }, { 0x51, 0xff },
 	{ 0x50, 0xb7 }, { 0x51, 0xff },
 	{ 0x50, 0x50 }, { 0x51, 0x02 },
-	{ 0x50, 0x51 }, { 0x51, 0x04 },
-	{ 0x45, 0x04 },
+	{ 0x50, 0x51 }, { 0x51, 0x04 },		/* MER symbol 4 */
+	{ 0x45, 0x04 },				/* CN symbol 4 */
 	{ 0x48, 0x04 },
 	{ 0x50, 0xd5 }, { 0x51, 0x01 },		/* Serial */
 	{ 0x50, 0xd6 }, { 0x51, 0x1f },
@@ -174,6 +180,20 @@ static struct regdata mb86a20s_reset_reception[] = {
 	{ 0x08, 0x00 },
 };
 
+static struct regdata mb86a20s_vber_reset[] = {
+	{ 0x53, 0x00 },	/* VBER Counter reset */
+	{ 0x53, 0x07 },
+};
+
+static struct regdata mb86a20s_clear_stats[] = {
+	{ 0x5f, 0x00 },	/* SBER Counter reset */
+	{ 0x5f, 0x07 },
+
+	{ 0x50, 0xb1 },	/* PBER Counter reset */
+	{ 0x51, 0x07 },
+	{ 0x51, 0x01 },
+};
+
 static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
 			     u8 i2c_addr, int reg, int data)
 {
@@ -221,7 +241,7 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state *state,
 
 	if (rc != 2) {
 		rc("%s: reg=0x%x (error=%d)\n", __func__, reg, rc);
-		return rc;
+		return (rc < 0) ? rc : -EIO;
 	}
 
 	return val;
@@ -276,59 +296,61 @@ err:
 	return rc;
 }
 
-static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
+static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
+	int rc;
 	unsigned rf_max, rf_min, rf;
-	u8	 val;
-
-	dprintk("\n");
-
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
 
 	/* Does a binary search to get RF strength */
 	rf_max = 0xfff;
 	rf_min = 0;
 	do {
 		rf = (rf_max + rf_min) / 2;
-		mb86a20s_writereg(state, 0x04, 0x1f);
-		mb86a20s_writereg(state, 0x05, rf >> 8);
-		mb86a20s_writereg(state, 0x04, 0x20);
-		mb86a20s_writereg(state, 0x04, rf);
+		rc = mb86a20s_writereg(state, 0x04, 0x1f);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x05, rf >> 8);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x04, 0x20);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x04, rf);
+		if (rc < 0)
+			return rc;
 
-		val = mb86a20s_readreg(state, 0x02);
-		if (val & 0x08)
+		rc = mb86a20s_readreg(state, 0x02);
+		if (rc < 0)
+			return rc;
+		if (rc & 0x08)
 			rf_min = (rf_max + rf_min) / 2;
 		else
 			rf_max = (rf_max + rf_min) / 2;
 		if (rf_max - rf_min < 4) {
-			*strength = (((rf_max + rf_min) / 2) * 65535) / 4095;
-			break;
+			rf = (rf_max + rf_min) / 2;
+
+			/* Rescale it from 2^12 (4096) to 2^16 */
+			rf <<= (16 - 12);
+			dprintk("signal strength = %d\n", rf);
+			return (rf);
 		}
 	} while (1);
 
-	dprintk("signal strength = %d\n", *strength);
-
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
-
 	return 0;
 }
 
 static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
-	u8 val;
+	int val;
 
 	dprintk("\n");
 	*status = 0;
 
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
 	val = mb86a20s_readreg(state, 0x0a) & 0xf;
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
+	if (val < 0)
+		return val;
 
 	if (val >= 2)
 		*status |= FE_HAS_SIGNAL;
@@ -530,9 +552,6 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 	/* Reset frontend cache to default values */
 	mb86a20s_reset_frontend_cache(fe);
 
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
-
 	/* Check for partial reception */
 	rc = mb86a20s_writereg(state, 0x6d, 0x85);
 	if (rc < 0)
@@ -609,15 +628,295 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 			break;
 		}
 	}
+	return 0;
+
+error:
+	/* per-layer info is incomplete; discard all per-layer */
+	c->isdbt_layer_enabled = 0;
+
+	return rc;
+}
+
+static int mb86a20s_reset_counters(struct dvb_frontend *fe)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	int rc, val, i;
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+
+	/* Set the QoS clear status for most stats */
+
+	/* BER counter reset */
+	rc = mb86a20s_writeregdata(state, mb86a20s_vber_reset);
+	if (rc < 0)
+		goto err;
+	for (i = 0; i < 3; i++)
+		state->read_ber[i] = true;
+
+	/* MER, PER counter reset */
+	rc = mb86a20s_writeregdata(state, mb86a20s_clear_stats);
+	if (rc < 0)
+		goto err;
+
+	/* CNR counter reset */
+	rc = mb86a20s_readreg(state, 0x45);
+	if (rc < 0)
+		goto err;
+	val = rc;
+	rc = mb86a20s_writereg(state, 0x45, val | 0x10);
+	if (rc < 0)
+		goto err;
+	rc = mb86a20s_writereg(state, 0x45, val & 0x6f);
+	if (rc < 0)
+		goto err;
+
+	/* MER counter reset */
+	rc = mb86a20s_writereg(state, 0x50, 0x50);
+	if (rc < 0)
+		goto err;
+	rc = mb86a20s_readreg(state, 0x51);
+	if (rc < 0)
+		goto err;
+	val = rc;
+	rc = mb86a20s_writereg(state, 0x51, val | 0x01);
+	if (rc < 0)
+		goto err;
+	rc = mb86a20s_writereg(state, 0x51, val & 0x06);
+	if (rc < 0)
+		goto err;
+
+err:
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+
+	return rc;
+}
+
+static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
+					  unsigned layer,
+					  u32 *error, u32 *count)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	u8 byte[3];
+	int rc;
+
+	if (layer >= 3)
+		return -EINVAL;
+
+	/* Check if the BER measures are already available */
+	rc = mb86a20s_readreg(state, 0x54);
+	if (rc < 0)
+		return rc;
+
+	/* Check if data is available for that layer */
+	if (!(rc & (1 << layer)))
+		return -EBUSY;
+
+	/* Read Bit Error Count */
+	rc = mb86a20s_readreg(state, 0x55 + layer * 3);
+	if (rc < 0)
+		return rc;
+	byte[0] = rc;
+	rc = mb86a20s_readreg(state, 0x56 + layer * 3);
+	if (rc < 0)
+		return rc;
+	byte[1] = rc;
+	rc = mb86a20s_readreg(state, 0x57 + layer * 3);
+	if (rc < 0)
+		return rc;
+	byte[2] = rc;
+	*error = byte[0] << 16 | byte[1] << 8 | byte[2];
+
+	/* Read Bit Count */
+	rc = mb86a20s_writereg(state, 0x50, 0xa7 + layer * 3);
+	if (rc < 0)
+		return rc;
+	rc = mb86a20s_readreg(state, 0x51);
+	if (rc < 0)
+		return rc;
+	byte[0] = rc;
+	rc = mb86a20s_writereg(state, 0x50, 0xa8 + layer * 3);
+	if (rc < 0)
+		return rc;
+	rc = mb86a20s_readreg(state, 0x51);
+	if (rc < 0)
+		return rc;
+	byte[1] = rc;
+	rc = mb86a20s_writereg(state, 0x50, 0xa9 + layer * 3);
+	if (rc < 0)
+		return rc;
+	rc = mb86a20s_readreg(state, 0x51);
+	if (rc < 0)
+		return rc;
+	byte[2] = rc;
+	*count = byte[0] << 16 | byte[1] << 8 | byte[2];
+
+	return rc;
+}
+
+static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+	int i;
+
+	/* Fill the length of each status counter */
+
+	/* Only global stats */
+	c->strength.len = 1;
+
+	/* Per-layer stats - 3 layers + global */
+	c->cnr.len = 4;
+	c->bit_error.len = 4;
+	c->bit_count.len = 4;
+	c->block_error.len = 4;
+	c->block_count.len = 4;
+
+	/* Signal is always available */
+	c->strength.stat[0].scale = FE_SCALE_RELATIVE;
+	c->strength.stat[0].uvalue = 0;
+
+	/* Put all of them at FE_SCALE_NOT_AVAILABLE */
+	for (i = 0; i < 4; i++) {
+		c->cnr.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->bit_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->bit_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->block_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->block_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+	}
+}
+
+static int mb86a20s_get_stats(struct dvb_frontend *fe)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+	int rc = 0, i;
+	u32 bit_error = 0, bit_count = 0;
+	u32 t_bit_error = 0, t_bit_count = 0;
+	int active_layers = 0, ber_layers = 0;
+
+	/* Get per-layer stats */
+	for (i = 0; i < 3; i++) {
+		if (c->isdbt_layer_enabled & (1 << i)) {
+			/* Layer is active and has rc segments */
+			active_layers++;
+
+			if (state->read_ber[i]) {
+				/* Handle BER before vterbi */
+				rc = mb86a20s_get_ber_before_vterbi(fe, i, &bit_error,
+								&bit_count);
+				if (rc >= 0) {
+					c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
+					c->bit_error.stat[1 + i].uvalue += bit_error;
+					c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
+					c->bit_count.stat[1 + i].uvalue += bit_count;
+
+					state->read_ber[i] = false;
+				} else if (rc != -EBUSY) {
+					/*
+					 * If an I/O error happened,
+					 * measures are now unavailable
+					 */
+					c->bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
+					c->bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
+				}
+			}
+			if (!state->read_ber[i]) {
+				/* Update total BER counter */
+				t_bit_error += c->bit_error.stat[1 + i].uvalue;
+				t_bit_count += c->bit_count.stat[1 + i].uvalue;
+
+				ber_layers++;
+			}
+		}
+	}
+
+	if (active_layers == ber_layers) {
+		/*
+		 * All BER values are read. We can now calculate the total BER
+		 * And ask for another BER measure
+		 *
+		 * Total Bit Error/Count is calculated as the sum of the
+		 * bit errors on all active layers.
+		 */
+		c->bit_error.stat[0].scale = FE_SCALE_COUNTER;
+		c->bit_error.stat[0].uvalue += t_bit_error;
+		c->bit_count.stat[0].scale = FE_SCALE_COUNTER;
+		c->bit_count.stat[0].uvalue += t_bit_count;
+
+		/* Reset counters to collect new data */
+		rc = mb86a20s_writeregdata(state, mb86a20s_vber_reset);
+
+		/* All BER measures need to be collected when ready */
+		for (i = 0; i < 3; i++)
+			state->read_ber[i] = true;
+	}
+	return rc;
+}
+
+static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
+					  fe_status_t *status)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+	int rc;
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+
+	/* Get lock */
+	rc = mb86a20s_read_status(fe, status);
+	if (!(*status & FE_HAS_LOCK)) {
+		mb86a20s_stats_not_ready(fe);
+		mb86a20s_reset_frontend_cache(fe);
+	}
+	if (rc < 0)
+		goto error;
+
+	/* Get signal strength */
+	rc = mb86a20s_read_signal_strength(fe);
+	if (rc < 0) {
+		mb86a20s_stats_not_ready(fe);
+		mb86a20s_reset_frontend_cache(fe);
+		goto error;
+	}
+	/* Fill signal strength */
+	c->strength.stat[0].uvalue = rc;
+
+	if (*status & FE_HAS_LOCK) {
+		/* Get TMCC info*/
+		rc = mb86a20s_get_frontend(fe);
+		if (rc < 0)
+			goto error;
+
+		/* Get QoS statistics */
+		rc = mb86a20s_get_stats(fe);
+		if (rc < 0)
+			goto error;
+	}
+	goto ok;
 
 error:
+	mb86a20s_stats_not_ready(fe);
+
+ok:
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
 
 	return rc;
+}
+
+static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
+						    u16 *strength)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 
+
+	*strength = c->strength.stat[0].uvalue;
+
+	return 0;
 }
 
+
 static int mb86a20s_tune(struct dvb_frontend *fe,
 			bool re_tune,
 			unsigned int mode_flags,
@@ -632,7 +931,7 @@ static int mb86a20s_tune(struct dvb_frontend *fe,
 		rc = mb86a20s_set_frontend(fe);
 
 	if (!(mode_flags & FE_TUNE_MODE_ONESHOT))
-		mb86a20s_read_status(fe, status);
+		mb86a20s_read_status_and_stats(fe, status);
 
 	return rc;
 }
@@ -712,10 +1011,11 @@ static struct dvb_frontend_ops mb86a20s_ops = {
 
 	.init = mb86a20s_initfe,
 	.set_frontend = mb86a20s_set_frontend,
-	.get_frontend = mb86a20s_get_frontend,
-	.read_status = mb86a20s_read_status,
-	.read_signal_strength = mb86a20s_read_signal_strength,
+	.read_status = mb86a20s_read_status_and_stats,
+	.read_signal_strength = mb86a20s_read_signal_strength_from_cache,
 	.tune = mb86a20s_tune,
+
+	.reset_qos_counters = mb86a20s_reset_counters,
 };
 
 MODULE_DESCRIPTION("DVB Frontend module for Fujitsu mb86A20s hardware");
-- 
1.7.11.7

[PATCH RFCv10 05/15] mb86a20s: functions reorder

[Mauro Carvalho Chehab]

No functional changes here. Just re-organizes the functions
inside the file.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 217 +++++++++++++++++----------------
 1 file changed, 115 insertions(+), 102 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 0f8d9bc..c91e9b9 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -194,6 +194,10 @@ static struct regdata mb86a20s_clear_stats[] = {
 	{ 0x51, 0x01 },
 };
 
+/*
+ * I2C read/write functions and macros
+ */
+
 static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
 			     u8 i2c_addr, int reg, int data)
 {
@@ -255,45 +259,42 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state *state,
 	mb86a20s_i2c_writeregdata(state, state->config->demod_address, \
 	regdata, ARRAY_SIZE(regdata))
 
-static int mb86a20s_initfe(struct dvb_frontend *fe)
+/*
+ * Ancillary internal routines (likely compiled inlined)
+ *
+ * The functions below assume that gateway lock has already obtained
+ */
+
+static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
-	int rc;
-	u8  regD5 = 1;
+	int val;
 
 	dprintk("\n");
+	*status = 0;
 
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
+	val = mb86a20s_readreg(state, 0x0a) & 0xf;
+	if (val < 0)
+		return val;
 
-	/* Initialize the frontend */
-	rc = mb86a20s_writeregdata(state, mb86a20s_init);
-	if (rc < 0)
-		goto err;
+	if (val >= 2)
+		*status |= FE_HAS_SIGNAL;
 
-	if (!state->config->is_serial) {
-		regD5 &= ~1;
+	if (val >= 4)
+		*status |= FE_HAS_CARRIER;
 
-		rc = mb86a20s_writereg(state, 0x50, 0xd5);
-		if (rc < 0)
-			goto err;
-		rc = mb86a20s_writereg(state, 0x51, regD5);
-		if (rc < 0)
-			goto err;
-	}
+	if (val >= 5)
+		*status |= FE_HAS_VITERBI;
 
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
+	if (val >= 7)
+		*status |= FE_HAS_SYNC;
 
-err:
-	if (rc < 0) {
-		state->need_init = true;
-		printk(KERN_INFO "mb86a20s: Init failed. Will try again later\n");
-	} else {
-		state->need_init = false;
-		dprintk("Initialization succeeded.\n");
-	}
-	return rc;
+	if (val >= 8)				/* Maybe 9? */
+		*status |= FE_HAS_LOCK;
+
+	dprintk("val = %d, status = 0x%02x\n", val, *status);
+
+	return 0;
 }
 
 static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
@@ -340,78 +341,6 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
 	return 0;
 }
 
-static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
-{
-	struct mb86a20s_state *state = fe->demodulator_priv;
-	int val;
-
-	dprintk("\n");
-	*status = 0;
-
-	val = mb86a20s_readreg(state, 0x0a) & 0xf;
-	if (val < 0)
-		return val;
-
-	if (val >= 2)
-		*status |= FE_HAS_SIGNAL;
-
-	if (val >= 4)
-		*status |= FE_HAS_CARRIER;
-
-	if (val >= 5)
-		*status |= FE_HAS_VITERBI;
-
-	if (val >= 7)
-		*status |= FE_HAS_SYNC;
-
-	if (val >= 8)				/* Maybe 9? */
-		*status |= FE_HAS_LOCK;
-
-	dprintk("val = %d, status = 0x%02x\n", val, *status);
-
-	return 0;
-}
-
-static int mb86a20s_set_frontend(struct dvb_frontend *fe)
-{
-	struct mb86a20s_state *state = fe->demodulator_priv;
-	int rc;
-#if 0
-	/*
-	 * FIXME: Properly implement the set frontend properties
-	 */
-	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
-#endif
-
-	dprintk("\n");
-
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
-	dprintk("Calling tuner set parameters\n");
-	fe->ops.tuner_ops.set_params(fe);
-
-	/*
-	 * Make it more reliable: if, for some reason, the initial
-	 * device initialization doesn't happen, initialize it when
-	 * a SBTVD parameters are adjusted.
-	 *
-	 * Unfortunately, due to a hard to track bug at tda829x/tda18271,
-	 * the agc callback logic is not called during DVB attach time,
-	 * causing mb86a20s to not be initialized with Kworld SBTVD.
-	 * So, this hack is needed, in order to make Kworld SBTVD to work.
-	 */
-	if (state->need_init)
-		mb86a20s_initfe(fe);
-
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 0);
-	rc = mb86a20s_writeregdata(state, mb86a20s_reset_reception);
-	if (fe->ops.i2c_gate_ctrl)
-		fe->ops.i2c_gate_ctrl(fe, 1);
-
-	return rc;
-}
-
 static int mb86a20s_get_modulation(struct mb86a20s_state *state,
 				   unsigned layer)
 {
@@ -854,6 +783,91 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 	return rc;
 }
 
+/*
+ * The functions below are called via DVB callbacks, so they need to
+ * properly use the I2C gate control
+ */
+static int mb86a20s_initfe(struct dvb_frontend *fe)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	int rc;
+	u8  regD5 = 1;
+
+	dprintk("\n");
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+
+	/* Initialize the frontend */
+	rc = mb86a20s_writeregdata(state, mb86a20s_init);
+	if (rc < 0)
+		goto err;
+
+	if (!state->config->is_serial) {
+		regD5 &= ~1;
+
+		rc = mb86a20s_writereg(state, 0x50, 0xd5);
+		if (rc < 0)
+			goto err;
+		rc = mb86a20s_writereg(state, 0x51, regD5);
+		if (rc < 0)
+			goto err;
+	}
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+
+err:
+	if (rc < 0) {
+		state->need_init = true;
+		printk(KERN_INFO "mb86a20s: Init failed. Will try again later\n");
+	} else {
+		state->need_init = false;
+		dprintk("Initialization succeeded.\n");
+	}
+	return rc;
+}
+
+static int mb86a20s_set_frontend(struct dvb_frontend *fe)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	int rc;
+#if 0
+	/*
+	 * FIXME: Properly implement the set frontend properties
+	 */
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+#endif
+
+	dprintk("\n");
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+	dprintk("Calling tuner set parameters\n");
+	fe->ops.tuner_ops.set_params(fe);
+
+	/*
+	 * Make it more reliable: if, for some reason, the initial
+	 * device initialization doesn't happen, initialize it when
+	 * a SBTVD parameters are adjusted.
+	 *
+	 * Unfortunately, due to a hard to track bug at tda829x/tda18271,
+	 * the agc callback logic is not called during DVB attach time,
+	 * causing mb86a20s to not be initialized with Kworld SBTVD.
+	 * So, this hack is needed, in order to make Kworld SBTVD to work.
+	 */
+	if (state->need_init)
+		mb86a20s_initfe(fe);
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 0);
+	rc = mb86a20s_writeregdata(state, mb86a20s_reset_reception);
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+
+	return rc;
+}
+
 static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
 					  fe_status_t *status)
 {
@@ -916,7 +930,6 @@ static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
 	return 0;
 }
 
-
 static int mb86a20s_tune(struct dvb_frontend *fe,
 			bool re_tune,
 			unsigned int mode_flags,
-- 
1.7.11.7

[PATCH RFCv10 06/15] mb86a20s: Fix i2c gate on error

[Mauro Carvalho Chehab]

If an error happens, restore tuner I2C gate to the right
value.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index c91e9b9..06e5d35 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -814,10 +814,10 @@ static int mb86a20s_initfe(struct dvb_frontend *fe)
 			goto err;
 	}
 
+err:
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
 
-err:
 	if (rc < 0) {
 		state->need_init = true;
 		printk(KERN_INFO "mb86a20s: Init failed. Will try again later\n");
@@ -841,6 +841,10 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
 
 	dprintk("\n");
 
+	/*
+	 * Gate should already be opened, but it doesn't hurt to
+	 * double-check
+	 */
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
 	dprintk("Calling tuner set parameters\n");
-- 
1.7.11.7

[PATCH RFCv10 07/15] mb86a20s: improve debug for RF level

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 06e5d35..e069c9b 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -333,7 +333,8 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
 
 			/* Rescale it from 2^12 (4096) to 2^16 */
 			rf <<= (16 - 12);
-			dprintk("signal strength = %d\n", rf);
+			dprintk("signal strength = %d (%d < RF=%d < %d)\n", rf,
+				rf_min, rf, rf_max);
 			return (rf);
 		}
 	} while (1);
-- 
1.7.11.7

[PATCH RFCv10 08/15] mb86a20s: fix interleaving and FEC retrival

[Mauro Carvalho Chehab]

Get the proper bits from the TMCC table registers.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index e069c9b..d14824a 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -360,7 +360,7 @@ static int mb86a20s_get_modulation(struct mb86a20s_state *state,
 	rc = mb86a20s_readreg(state, 0x6e);
 	if (rc < 0)
 		return rc;
-	switch ((rc & 0x70) >> 4) {
+	switch ((rc >> 4) & 0x07) {
 	case 0:
 		return DQPSK;
 	case 1:
@@ -393,7 +393,7 @@ static int mb86a20s_get_fec(struct mb86a20s_state *state,
 	rc = mb86a20s_readreg(state, 0x6e);
 	if (rc < 0)
 		return rc;
-	switch (rc) {
+	switch ((rc >> 4) & 0x07) {
 	case 0:
 		return FEC_1_2;
 	case 1:
@@ -428,9 +428,7 @@ static int mb86a20s_get_interleaving(struct mb86a20s_state *state,
 	rc = mb86a20s_readreg(state, 0x6e);
 	if (rc < 0)
 		return rc;
-	if (rc > 3)
-		return -EINVAL;	/* Not used */
-	return rc;
+	return (rc >> 4) & 0x07;
 }
 
 static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
-- 
1.7.11.7

[PATCH RFCv10 09/15] mb86a20s: convert it to use dev_info/dev_err/dev_dbg

[Mauro Carvalho Chehab]

Also add some additional debug and error messages when needed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 156 +++++++++++++++++++++++----------
 1 file changed, 111 insertions(+), 45 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index d14824a..e73f66d 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -24,18 +24,6 @@ static int debug = 1;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Activates frontend debugging (default:0)");
 
-#define rc(args...)  do {						\
-	printk(KERN_ERR  "mb86a20s: " args);				\
-} while (0)
-
-#define dprintk(args...)						\
-	do {								\
-		if (debug) {						\
-			printk(KERN_DEBUG "mb86a20s: %s: ", __func__);	\
-			printk(args);					\
-		}							\
-	} while (0)
-
 struct mb86a20s_state {
 	struct i2c_adapter *i2c;
 	const struct mb86a20s_config *config;
@@ -209,8 +197,9 @@ static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
 
 	rc = i2c_transfer(state->i2c, &msg, 1);
 	if (rc != 1) {
-		printk("%s: writereg error (rc == %i, reg == 0x%02x,"
-			 " data == 0x%02x)\n", __func__, rc, reg, data);
+		dev_err(&state->i2c->dev,
+			"%s: writereg error (rc == %i, reg == 0x%02x, data == 0x%02x)\n",
+			__func__, rc, reg, data);
 		return rc;
 	}
 
@@ -244,7 +233,8 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state *state,
 	rc = i2c_transfer(state->i2c, msg, 2);
 
 	if (rc != 2) {
-		rc("%s: reg=0x%x (error=%d)\n", __func__, reg, rc);
+		dev_err(&state->i2c->dev, "%s: reg=0x%x (error=%d)\n",
+			__func__, reg, rc);
 		return (rc < 0) ? rc : -EIO;
 	}
 
@@ -270,7 +260,6 @@ static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
 	struct mb86a20s_state *state = fe->demodulator_priv;
 	int val;
 
-	dprintk("\n");
 	*status = 0;
 
 	val = mb86a20s_readreg(state, 0x0a) & 0xf;
@@ -292,7 +281,8 @@ static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
 	if (val >= 8)				/* Maybe 9? */
 		*status |= FE_HAS_LOCK;
 
-	dprintk("val = %d, status = 0x%02x\n", val, *status);
+	dev_dbg(&state->i2c->dev, "%s: Status = 0x%02x (state = %d)\n",
+		 __func__, *status, val);
 
 	return 0;
 }
@@ -333,8 +323,9 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe)
 
 			/* Rescale it from 2^12 (4096) to 2^16 */
 			rf <<= (16 - 12);
-			dprintk("signal strength = %d (%d < RF=%d < %d)\n", rf,
-				rf_min, rf, rf_max);
+			dev_dbg(&state->i2c->dev,
+				"%s: signal strength = %d (%d < RF=%d < %d)\n",
+				__func__, rf, rf_min, rf >> 4, rf_max);
 			return (rf);
 		}
 	} while (1);
@@ -435,15 +426,17 @@ static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
 				      unsigned layer)
 {
 	int rc, count;
-
 	static unsigned char reg[] = {
 		[0] = 0x89,	/* Layer A */
 		[1] = 0x8d,	/* Layer B */
 		[2] = 0x91,	/* Layer C */
 	};
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	if (layer >= ARRAY_SIZE(reg))
 		return -EINVAL;
+
 	rc = mb86a20s_writereg(state, 0x6d, reg[layer]);
 	if (rc < 0)
 		return rc;
@@ -452,13 +445,18 @@ static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
 		return rc;
 	count = (rc >> 4) & 0x0f;
 
+	dev_dbg(&state->i2c->dev, "%s: segments: %d.\n", __func__, count);
+
 	return count;
 }
 
 static void mb86a20s_reset_frontend_cache(struct dvb_frontend *fe)
 {
+	struct mb86a20s_state *state = fe->demodulator_priv;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	/* Fixed parameters */
 	c->delivery_system = SYS_ISDBT;
 	c->bandwidth_hz = 6000000;
@@ -477,6 +475,8 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int i, rc;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	/* Reset frontend cache to default values */
 	mb86a20s_reset_frontend_cache(fe);
 
@@ -492,9 +492,12 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 	/* Get per-layer data */
 
 	for (i = 0; i < 3; i++) {
+		dev_dbg(&state->i2c->dev, "%s: getting data for layer %c.\n",
+			__func__, 'A' + i);
+
 		rc = mb86a20s_get_segment_count(state, i);
 		if (rc < 0)
-			goto error;
+			goto noperlayer_error;
 		if (rc >= 0 && rc < 14)
 			c->layer[i].segment_count = rc;
 		else {
@@ -504,15 +507,21 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 		c->isdbt_layer_enabled |= 1 << i;
 		rc = mb86a20s_get_modulation(state, i);
 		if (rc < 0)
-			goto error;
+			goto noperlayer_error;
+		dev_dbg(&state->i2c->dev, "%s: modulation %d.\n",
+			__func__, rc);
 		c->layer[i].modulation = rc;
 		rc = mb86a20s_get_fec(state, i);
 		if (rc < 0)
-			goto error;
+			goto noperlayer_error;
+		dev_dbg(&state->i2c->dev, "%s: FEC %d.\n",
+			__func__, rc);
 		c->layer[i].fec = rc;
 		rc = mb86a20s_get_interleaving(state, i);
 		if (rc < 0)
-			goto error;
+			goto noperlayer_error;
+		dev_dbg(&state->i2c->dev, "%s: interleaving %d.\n",
+			__func__, rc);
 		c->layer[i].interleaving = rc;
 	}
 
@@ -558,7 +567,8 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 	}
 	return 0;
 
-error:
+noperlayer_error:
+
 	/* per-layer info is incomplete; discard all per-layer */
 	c->isdbt_layer_enabled = 0;
 
@@ -570,6 +580,8 @@ static int mb86a20s_reset_counters(struct dvb_frontend *fe)
 	struct mb86a20s_state *state = fe->demodulator_priv;
 	int rc, val, i;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
 
@@ -614,7 +626,12 @@ static int mb86a20s_reset_counters(struct dvb_frontend *fe)
 	if (rc < 0)
 		goto err;
 
+	goto ok;
 err:
+	dev_err(&state->i2c->dev,
+		"%s: Can't reset FE QoS counters (error %d).\n",
+		__func__, rc);
+ok:
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
 
@@ -629,6 +646,8 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 	u8 byte[3];
 	int rc;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	if (layer >= 3)
 		return -EINVAL;
 
@@ -638,8 +657,12 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 		return rc;
 
 	/* Check if data is available for that layer */
-	if (!(rc & (1 << layer)))
+	if (!(rc & (1 << layer))) {
+		dev_info(&state->i2c->dev,
+			"%s: BER for layer %c is not available yet.\n",
+			__func__, 'A' + layer);
 		return -EBUSY;
+	}
 
 	/* Read Bit Error Count */
 	rc = mb86a20s_readreg(state, 0x55 + layer * 3);
@@ -656,6 +679,10 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 	byte[2] = rc;
 	*error = byte[0] << 16 | byte[1] << 8 | byte[2];
 
+	dev_err(&state->i2c->dev,
+		"%s: bit error before Viterbi for layer %c: %d.\n",
+		__func__, 'A' + layer, *error);
+
 	/* Read Bit Count */
 	rc = mb86a20s_writereg(state, 0x50, 0xa7 + layer * 3);
 	if (rc < 0)
@@ -679,15 +706,21 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 		return rc;
 	byte[2] = rc;
 	*count = byte[0] << 16 | byte[1] << 8 | byte[2];
+	dev_dbg(&state->i2c->dev,
+		"%s: bit count before Viterbi for layer %c: %d.\n",
+		__func__, 'A' + layer, *count);
 
-	return rc;
+	return 0;
 }
 
 static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
 {
+	struct mb86a20s_state *state = fe->demodulator_priv;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int i;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	/* Fill the length of each status counter */
 
 	/* Only global stats */
@@ -723,6 +756,8 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 	u32 t_bit_error = 0, t_bit_count = 0;
 	int active_layers = 0, ber_layers = 0;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	/* Get per-layer stats */
 	for (i = 0; i < 3; i++) {
 		if (c->isdbt_layer_enabled & (1 << i)) {
@@ -747,6 +782,10 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 					 */
 					c->bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
 					c->bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
+					dev_err(&state->i2c->dev,
+						"%s: Can't get BER for layer %c (error %d).\n",
+						__func__, 'A' + i, rc);
+
 				}
 			}
 			if (!state->read_ber[i]) {
@@ -774,6 +813,9 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 
 		/* Reset counters to collect new data */
 		rc = mb86a20s_writeregdata(state, mb86a20s_vber_reset);
+		if (rc < 0)
+			dev_err(&state->i2c->dev,
+				"%s: Can't reset VBER registers.\n", __func__);
 
 		/* All BER measures need to be collected when ready */
 		for (i = 0; i < 3; i++)
@@ -792,7 +834,7 @@ static int mb86a20s_initfe(struct dvb_frontend *fe)
 	int rc;
 	u8  regD5 = 1;
 
-	dprintk("\n");
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
@@ -819,10 +861,11 @@ err:
 
 	if (rc < 0) {
 		state->need_init = true;
-		printk(KERN_INFO "mb86a20s: Init failed. Will try again later\n");
+		dev_info(&state->i2c->dev,
+			 "mb86a20s: Init failed. Will try again later\n");
 	} else {
 		state->need_init = false;
-		dprintk("Initialization succeeded.\n");
+		dev_dbg(&state->i2c->dev, "Initialization succeeded.\n");
 	}
 	return rc;
 }
@@ -831,6 +874,9 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
 	int rc;
+
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 #if 0
 	/*
 	 * FIXME: Properly implement the set frontend properties
@@ -838,15 +884,12 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 #endif
 
-	dprintk("\n");
-
 	/*
 	 * Gate should already be opened, but it doesn't hurt to
 	 * double-check
 	 */
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 1);
-	dprintk("Calling tuner set parameters\n");
 	fe->ops.tuner_ops.set_params(fe);
 
 	/*
@@ -874,9 +917,12 @@ static int mb86a20s_set_frontend(struct dvb_frontend *fe)
 static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
 					  fe_status_t *status)
 {
+	struct mb86a20s_state *state = fe->demodulator_priv;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int rc;
 
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
+
 	if (fe->ops.i2c_gate_ctrl)
 		fe->ops.i2c_gate_ctrl(fe, 0);
 
@@ -886,14 +932,21 @@ static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
 		mb86a20s_stats_not_ready(fe);
 		mb86a20s_reset_frontend_cache(fe);
 	}
-	if (rc < 0)
+	if (rc < 0) {
+		dev_err(&state->i2c->dev,
+			"%s: Can't read frontend lock status\n", __func__);
 		goto error;
+	}
 
 	/* Get signal strength */
 	rc = mb86a20s_read_signal_strength(fe);
 	if (rc < 0) {
+		dev_err(&state->i2c->dev,
+			"%s: Can't reset VBER registers.\n", __func__);
 		mb86a20s_stats_not_ready(fe);
 		mb86a20s_reset_frontend_cache(fe);
+
+		rc = 0;		/* Status is OK */
 		goto error;
 	}
 	/* Fill signal strength */
@@ -902,13 +955,21 @@ static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
 	if (*status & FE_HAS_LOCK) {
 		/* Get TMCC info*/
 		rc = mb86a20s_get_frontend(fe);
-		if (rc < 0)
+		if (rc < 0) {
+			dev_err(&state->i2c->dev,
+				"%s: Can't get FE TMCC data.\n", __func__);
+			rc = 0;		/* Status is OK */
 			goto error;
+		}
 
 		/* Get QoS statistics */
 		rc = mb86a20s_get_stats(fe);
-		if (rc < 0)
+		if (rc < 0) {
+			dev_err(&state->i2c->dev,
+				"%s: Can't get FE QoS statistics.\n", __func__);
+			rc = 0;
 			goto error;
+		}
 	}
 	goto ok;
 
@@ -939,9 +1000,10 @@ static int mb86a20s_tune(struct dvb_frontend *fe,
 			unsigned int *delay,
 			fe_status_t *status)
 {
+	struct mb86a20s_state *state = fe->demodulator_priv;
 	int rc = 0;
 
-	dprintk("\n");
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 
 	if (re_tune)
 		rc = mb86a20s_set_frontend(fe);
@@ -956,7 +1018,7 @@ static void mb86a20s_release(struct dvb_frontend *fe)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
 
-	dprintk("\n");
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 
 	kfree(state);
 }
@@ -967,14 +1029,16 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
 				    struct i2c_adapter *i2c)
 {
 	u8	rev;
+	struct mb86a20s_state *state;
 
 	/* allocate memory for the internal state */
-	struct mb86a20s_state *state =
-		kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
+	state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
+
+	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 
-	dprintk("\n");
 	if (state == NULL) {
-		rc("Unable to kzalloc\n");
+		dev_err(&state->i2c->dev,
+			"%s: unable to allocate memory for state\n", __func__);
 		goto error;
 	}
 
@@ -991,10 +1055,12 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
 	rev = mb86a20s_readreg(state, 0);
 
 	if (rev == 0x13) {
-		printk(KERN_INFO "Detected a Fujitsu mb86a20s frontend\n");
+		dev_info(&state->i2c->dev,
+			 "Detected a Fujitsu mb86a20s frontend\n");
 	} else {
-		printk(KERN_ERR "Frontend revision %d is unknown - aborting.\n",
-		       rev);
+		dev_err(&state->i2c->dev,
+		        "Frontend revision %d is unknown - aborting.\n",
+		        rev);
 		goto error;
 	}
 
-- 
1.7.11.7

[PATCH RFCv10 10/15] mb86a20s: -EBUSY is expected when getting QoS measures

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index e73f66d..c4bf428 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -964,12 +964,13 @@ static int mb86a20s_read_status_and_stats(struct dvb_frontend *fe,
 
 		/* Get QoS statistics */
 		rc = mb86a20s_get_stats(fe);
-		if (rc < 0) {
+		if (rc < 0 && rc != -EBUSY) {
 			dev_err(&state->i2c->dev,
 				"%s: Can't get FE QoS statistics.\n", __func__);
 			rc = 0;
 			goto error;
 		}
+		rc = 0;	/* Don't return EBUSY to userspace */
 	}
 	goto ok;
 
-- 
1.7.11.7

[PATCH RFCv10 11/15] mb86a20s: make AGC work better

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index c4bf428..21e7e68 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -120,7 +120,8 @@ static struct regdata mb86a20s_init[] = {
 	{ 0x50, 0xd7 }, { 0x51, 0x3f },
 	{ 0x28, 0x74 }, { 0x29, 0x00 }, { 0x28, 0x74 }, { 0x29, 0x40 },
 	{ 0x28, 0x46 }, { 0x29, 0x2c }, { 0x28, 0x46 }, { 0x29, 0x0c },
-	{ 0x04, 0x40 }, { 0x05, 0x01 },
+
+	{ 0x04, 0x40 }, { 0x05, 0x00 },
 	{ 0x28, 0x00 }, { 0x29, 0x10 },
 	{ 0x28, 0x05 }, { 0x29, 0x02 },
 	{ 0x1c, 0x01 },
-- 
1.7.11.7

[PATCH RFCv10 12/15] mb86a20s: Some improvements for BER measurement

[Mauro Carvalho Chehab]

Reduce the bit count from 2^24-1 to 2^16-1 to speedup
BER measurement;

Do a per-layer reset, instead of waiting for data on all
layers;

Global stats now start to appear as soon as the first layer
(e. g. the one with the biggest number of segments) start to
have collected data.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 52 +++++++++++++++++++++++++---------
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 21e7e68..0d13c87 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -86,16 +86,36 @@ static struct regdata mb86a20s_init[] = {
 	{ 0x04, 0x13 }, { 0x05, 0xff },
 	{ 0x04, 0x15 }, { 0x05, 0x4e },
 	{ 0x04, 0x16 }, { 0x05, 0x20 },
+
+	/*
+	 * On this demod, when the bit count reaches the count below,
+	 * it collects the bit error count.
+	 *
+	 * As FE thread runs on every 3 seconds, adjust the counters to
+	 * provide one collect before 3 seconds, at the worse case (DQPSK,
+	 * 1/4 guard interval, 1/2 FEC, 1-seg rate is 280 Mbps, and
+	 * 3 seconds takes 0xcdb9f bits. Rounds it down to 0xccfff
+	 *
+	 * It should be noticed, however, that, with QAM-64 1/32 guard interval,
+	 * 1 segment bit rate is 1.78 Mbps, and 12-seg is about 21.5 Mbps.
+	 * At such rate, the time to measure BER is about 40 ms.
+	 *
+	 * It makes sense to change the logic there to use TMCC parameters and
+	 * adjust the counters in order to have all of them to take a little
+	 * less than 3 seconds, in order to have a more realistic BER rate,
+	 * instead of having short samples for 12-segs.
+	 */
 	{ 0x52, 0x01 },				/* Turn on BER before Viterbi */
-	{ 0x50, 0xa7 }, { 0x51, 0xff },
-	{ 0x50, 0xa8 }, { 0x51, 0xff },
+	{ 0x50, 0xa7 }, { 0x51, 0x0c },
+	{ 0x50, 0xa8 }, { 0x51, 0xcf },
 	{ 0x50, 0xa9 }, { 0x51, 0xff },
-	{ 0x50, 0xaa }, { 0x51, 0xff },
-	{ 0x50, 0xab }, { 0x51, 0xff },
+	{ 0x50, 0xaa }, { 0x51, 0x0c },
+	{ 0x50, 0xab }, { 0x51, 0xcf },
 	{ 0x50, 0xac }, { 0x51, 0xff },
-	{ 0x50, 0xad }, { 0x51, 0xff },
-	{ 0x50, 0xae }, { 0x51, 0xff },
+	{ 0x50, 0xad }, { 0x51, 0x0c },
+	{ 0x50, 0xae }, { 0x51, 0xcf },
 	{ 0x50, 0xaf }, { 0x51, 0xff },
+
 	{ 0x5e, 0x07 },
 	{ 0x50, 0xdc }, { 0x51, 0x01 },
 	{ 0x50, 0xdd }, { 0x51, 0xf4 },
@@ -711,6 +731,14 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 		"%s: bit count before Viterbi for layer %c: %d.\n",
 		__func__, 'A' + layer, *count);
 
+	/* Reset counter to collect new data */
+	rc = mb86a20s_writereg(state, 0x53, 0x07 & ~(1 << layer));
+	if (rc < 0)
+		return rc;
+	rc = mb86a20s_writereg(state, 0x53, 0x07);
+	if (rc < 0)
+		return rc;
+
 	return 0;
 }
 
@@ -799,7 +827,11 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 		}
 	}
 
-	if (active_layers == ber_layers) {
+	/*
+	 * Start showing global count if at least one error count is
+	 * available.
+	 */
+	if (ber_layers) {
 		/*
 		 * All BER values are read. We can now calculate the total BER
 		 * And ask for another BER measure
@@ -812,12 +844,6 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 		c->bit_count.stat[0].scale = FE_SCALE_COUNTER;
 		c->bit_count.stat[0].uvalue += t_bit_count;
 
-		/* Reset counters to collect new data */
-		rc = mb86a20s_writeregdata(state, mb86a20s_vber_reset);
-		if (rc < 0)
-			dev_err(&state->i2c->dev,
-				"%s: Can't reset VBER registers.\n", __func__);
-
 		/* All BER measures need to be collected when ready */
 		for (i = 0; i < 3; i++)
 			state->read_ber[i] = true;
-- 
1.7.11.7

[PATCH RFCv10 13/15] mb86a20s: improve bit error count for BER

[Mauro Carvalho Chehab]

Do a better job on setting the bit error counters, in order to
have all layer measures to happen in a little less than one
second.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 drivers/media/dvb-frontends/mb86a20s.c | 204 +++++++++++++++++++++++++++++----
 1 file changed, 179 insertions(+), 25 deletions(-)

diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 0d13c87..2f3e4b3 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -30,6 +30,8 @@ struct mb86a20s_state {
 
 	struct dvb_frontend frontend;
 
+	u32 estimated_rate[3];
+
 	bool need_init;
 
 	/*
@@ -89,31 +91,20 @@ static struct regdata mb86a20s_init[] = {
 
 	/*
 	 * On this demod, when the bit count reaches the count below,
-	 * it collects the bit error count.
-	 *
-	 * As FE thread runs on every 3 seconds, adjust the counters to
-	 * provide one collect before 3 seconds, at the worse case (DQPSK,
-	 * 1/4 guard interval, 1/2 FEC, 1-seg rate is 280 Mbps, and
-	 * 3 seconds takes 0xcdb9f bits. Rounds it down to 0xccfff
-	 *
-	 * It should be noticed, however, that, with QAM-64 1/32 guard interval,
-	 * 1 segment bit rate is 1.78 Mbps, and 12-seg is about 21.5 Mbps.
-	 * At such rate, the time to measure BER is about 40 ms.
-	 *
-	 * It makes sense to change the logic there to use TMCC parameters and
-	 * adjust the counters in order to have all of them to take a little
-	 * less than 3 seconds, in order to have a more realistic BER rate,
-	 * instead of having short samples for 12-segs.
+	 * it collects the bit error count. The bit counters are initialized
+	 * to 65535 here. This warrants that all of them will be quickly
+	 * calculated when device gets locked. As TMCC is parsed, the values
+	 * will be adjusted later in the driver's code.
 	 */
 	{ 0x52, 0x01 },				/* Turn on BER before Viterbi */
-	{ 0x50, 0xa7 }, { 0x51, 0x0c },
-	{ 0x50, 0xa8 }, { 0x51, 0xcf },
+	{ 0x50, 0xa7 }, { 0x51, 0x00 },
+	{ 0x50, 0xa8 }, { 0x51, 0xff },
 	{ 0x50, 0xa9 }, { 0x51, 0xff },
-	{ 0x50, 0xaa }, { 0x51, 0x0c },
-	{ 0x50, 0xab }, { 0x51, 0xcf },
+	{ 0x50, 0xaa }, { 0x51, 0x00 },
+	{ 0x50, 0xab }, { 0x51, 0xff },
 	{ 0x50, 0xac }, { 0x51, 0xff },
-	{ 0x50, 0xad }, { 0x51, 0x0c },
-	{ 0x50, 0xae }, { 0x51, 0xcf },
+	{ 0x50, 0xad }, { 0x51, 0x00 },
+	{ 0x50, 0xae }, { 0x51, 0xff },
 	{ 0x50, 0xaf }, { 0x51, 0xff },
 
 	{ 0x5e, 0x07 },
@@ -208,7 +199,7 @@ static struct regdata mb86a20s_clear_stats[] = {
  */
 
 static int mb86a20s_i2c_writereg(struct mb86a20s_state *state,
-			     u8 i2c_addr, int reg, int data)
+			     u8 i2c_addr, u8 reg, u8 data)
 {
 	u8 buf[] = { reg, data };
 	struct i2c_msg msg = {
@@ -440,7 +431,21 @@ static int mb86a20s_get_interleaving(struct mb86a20s_state *state,
 	rc = mb86a20s_readreg(state, 0x6e);
 	if (rc < 0)
 		return rc;
-	return (rc >> 4) & 0x07;
+
+	switch ((rc >> 4) & 0x07) {
+	case 1:
+		return GUARD_INTERVAL_1_4;
+	case 2:
+		return GUARD_INTERVAL_1_8;
+	case 3:
+		return GUARD_INTERVAL_1_16;
+	case 4:
+		return GUARD_INTERVAL_1_32;
+
+	default:
+	case 0:
+		return GUARD_INTERVAL_AUTO;
+	}
 }
 
 static int mb86a20s_get_segment_count(struct mb86a20s_state *state,
@@ -490,6 +495,112 @@ static void mb86a20s_reset_frontend_cache(struct dvb_frontend *fe)
 	c->isdbt_sb_segment_count = 0;
 }
 
+/*
+ * Estimates the bit rate using the per-segment bit rate given by
+ * ABNT/NBR 15601 spec (table 4).
+ */
+static u32 isdbt_rate[3][5][4] = {
+	{	/* DQPSK/QPSK */
+		{  280850,  312060,  330420,  340430 },	/* 1/2 */
+		{  374470,  416080,  440560,  453910 },	/* 2/3 */
+		{  421280,  468090,  495630,  510650 },	/* 3/4 */
+		{  468090,  520100,  550700,  567390 },	/* 5/6 */
+		{  491500,  546110,  578230,  595760 },	/* 7/8 */
+	}, {	/* QAM16 */
+		{  561710,  624130,  660840,  680870 },	/* 1/2 */
+		{  748950,  832170,  881120,  907820 },	/* 2/3 */
+		{  842570,  936190,  991260, 1021300 },	/* 3/4 */
+		{  936190, 1040210, 1101400, 1134780 },	/* 5/6 */
+		{  983000, 1092220, 1156470, 1191520 },	/* 7/8 */
+	}, {	/* QAM64 */
+		{  842570,  936190,  991260, 1021300 },	/* 1/2 */
+		{ 1123430, 1248260, 1321680, 1361740 },	/* 2/3 */
+		{ 1263860, 1404290, 1486900, 1531950 },	/* 3/4 */
+		{ 1404290, 1560320, 1652110, 1702170 },	/* 5/6 */
+		{ 1474500, 1638340, 1734710, 1787280 },	/* 7/8 */
+	}
+};
+
+static void mb86a20s_layer_bitrate(struct dvb_frontend *fe, u32 layer,
+				   u32 modulation, u32 fec, u32 interleaving,
+				   u32 segment)
+{
+	struct mb86a20s_state *state = fe->demodulator_priv;
+	u32 rate;
+	int m, f, i;
+
+	/*
+	 * default is always the lowest bit rate, to be sure that it will
+	 * take less than 1 second to count the bits
+	 */
+	switch(modulation) {
+	case DQPSK:
+	case QPSK:
+	default:
+		m = 0;
+		break;
+	case QAM_16:
+		m = 1;
+		break;
+	case QAM_64:
+		m = 2;
+		break;
+	}
+
+	switch(fec) {
+	default:
+	case FEC_1_2:
+	case FEC_AUTO:
+		f = 0;
+		break;
+	case FEC_2_3:
+		f = 1;
+		break;
+	case FEC_3_4:
+		f = 2;
+		break;
+	case FEC_5_6:
+		f = 3;
+		break;
+	case FEC_7_8:
+		f = 4;
+		break;
+	}
+
+	switch(interleaving) {
+	default:
+	case GUARD_INTERVAL_1_4:
+		i = 0;
+		break;
+	case GUARD_INTERVAL_1_8:
+		i = 1;
+		break;
+	case GUARD_INTERVAL_1_16:
+		i = 2;
+		break;
+	case GUARD_INTERVAL_1_32:
+		i = 3;
+		break;
+	}
+
+	/*
+	 * Estimates a rate below the real one, to have more hope that the
+	 * BER calculus will finish before 1 second.
+	 */
+	rate = (isdbt_rate[m][f][i] >> 16) << 15;
+
+	/* Multiplies the rate by the number of segments */
+	rate *= segment;
+
+	dev_dbg(&state->i2c->dev,
+		"%s: layer %c bitrate: %d kbps; counter = %d (0x%06x)\n",
+	       __func__, 'A' + layer, segment * isdbt_rate[m][f][i]/1000,
+		rate, rate);
+
+	state->estimated_rate[i] = rate;
+}
+
+
 static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 {
 	struct mb86a20s_state *state = fe->demodulator_priv;
@@ -519,10 +630,11 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 		rc = mb86a20s_get_segment_count(state, i);
 		if (rc < 0)
 			goto noperlayer_error;
-		if (rc >= 0 && rc < 14)
+		if (rc >= 0 && rc < 14) {
 			c->layer[i].segment_count = rc;
-		else {
+		} else {
 			c->layer[i].segment_count = 0;
+			state->estimated_rate[i] = 0;
 			continue;
 		}
 		c->isdbt_layer_enabled |= 1 << i;
@@ -544,6 +656,10 @@ static int mb86a20s_get_frontend(struct dvb_frontend *fe)
 		dev_dbg(&state->i2c->dev, "%s: interleaving %d.\n",
 			__func__, rc);
 		c->layer[i].interleaving = rc;
+		mb86a20s_layer_bitrate(fe, i, c->layer[i].modulation,
+				       c->layer[i].fec,
+				       c->layer[i].interleaving,
+				       c->layer[i].segment_count);
 	}
 
 	rc = mb86a20s_writereg(state, 0x6d, 0x84);
@@ -731,6 +847,42 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 		"%s: bit count before Viterbi for layer %c: %d.\n",
 		__func__, 'A' + layer, *count);
 
+	/*
+	 * As we get TMCC data from the frontend, we can better estimate the
+	 * BER bit counters, in order to do the BER measure during a longer
+	 * time. Use those data, if available, to update the bit count
+	 * measure.
+	 */
+
+	if (state->estimated_rate[layer]
+	    && state->estimated_rate[layer] != *count) {
+		dev_dbg(&state->i2c->dev,
+			"%s: updating layer %c counter to %d.\n",
+			__func__, 'A' + layer, state->estimated_rate[layer]);
+		rc = mb86a20s_writereg(state, 0x50, 0xa7 + layer * 3);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x51,
+				       state->estimated_rate[layer] >> 16);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x50, 0xa8 + layer * 3);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x51,
+				       state->estimated_rate[layer] >> 8);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x50, 0xa9 + layer * 3);
+		if (rc < 0)
+			return rc;
+		rc = mb86a20s_writereg(state, 0x51,
+				       state->estimated_rate[layer]);
+		if (rc < 0)
+			return rc;
+	}
+
+
 	/* Reset counter to collect new data */
 	rc = mb86a20s_writereg(state, 0x53, 0x07 & ~(1 << layer));
 	if (rc < 0)
@@ -739,6 +891,8 @@ static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
 	if (rc < 0)
 		return rc;
 
+
+
 	return 0;
 }
 
-- 
1.7.11.7

[PATCH RFCv10 14/15] dvb: increase API version

[Mauro Carvalho Chehab]

Due to statistics, we should update the DVB API version.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
 Documentation/DocBook/media/dvb/dvbapi.xml | 2 +-
 include/uapi/linux/dvb/version.h           | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml
index 757488b..0197bcc 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
 
 
 <title>LINUX DVB API</title>
-<subtitle>Version 5.8</subtitle>
+<subtitle>Version 5.10</subtitle>
 <!-- ADD THE CHAPTERS HERE -->
   <chapter id="dvb_introdution">
     &sub-intro;
diff --git a/include/uapi/linux/dvb/version.h b/include/uapi/linux/dvb/version.h
index 827cce7..e53e2ad 100644
--- a/include/uapi/linux/dvb/version.h
+++ b/include/uapi/linux/dvb/version.h
@@ -24,6 +24,6 @@
 #define _DVBVERSION_H_
 
 #define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 9
+#define DVB_API_VERSION_MINOR 10
 
 #endif /*_DVBVERSION_H_*/
-- 
1.7.11.7

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Johannes Stezenbach]

On Tue, Jan 15, 2013 at 12:30:46AM -0200, Mauro Carvalho Chehab wrote:
> Add DVBv5 methods to retrieve QoS statistics.

According to http://en.wikipedia.org/wiki/Qos:
"Quality of service in computer network trafficking refers
to resource reservation control mechanisms"

I think it is misleading to use the term QoS for DVB, what
the patch series seems to be about is receiption or signal quality.


Johannes

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/15/2013 10:20 AM, Johannes Stezenbach wrote:
> On Tue, Jan 15, 2013 at 12:30:46AM -0200, Mauro Carvalho Chehab wrote:
>> Add DVBv5 methods to retrieve QoS statistics.
>
> According to http://en.wikipedia.org/wiki/Qos:
> "Quality of service in computer network trafficking refers
> to resource reservation control mechanisms"
>
> I think it is misleading to use the term QoS for DVB, what
> the patch series seems to be about is receiption or signal quality.

I totally agree that (and I have used name signal statistics).

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/15/2013 04:30 AM, Mauro Carvalho Chehab wrote:

>      v6: Add DocBook documentation.
>      v7: Some fixes as suggested by Antti
>      v8: Documentation fix, compilation fix and name the stats struct,
>          for its reusage inside the core
>      v9: counters need 32 bits. So, change the return data types to
>          s32/u32 types
>      v10: Counters changed to 64 bits for monotonic increment
> 	 Don't create a separate get_stats callback. get_frontend
> 	 is already good enough for it.

Is there way to return BER as rate, or should it be calculated by the 
application (from total and error bit counts)?

You seems to change value to 64 bit already, which is enough. 32bit is 
absolutely too small, it will overflow in seconds (practically around 
10sec when there is radio channel of 32MHz and quite optimal conditions).

It is 64bit returned to userspace, is it? Does 64bit calculations causes 
any complexity of Kernel or app space?

Basically, that API is more complex that I would like to see, but I can 
live with it. I still fear making too complex API causes same problems 
as we has currently... lack of app support.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Tue, Jan 15, 2013 at 8:00 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Add DVBv5 methods to retrieve QoS statistics.
>
> Those methods allow per-layer and global statistics.
>
> Implemented 2 QoS statistics on mb86a20s, one global only
> (signal strengh), and one per layer (BER).
>
> Tested with a modified version of dvbv5-zap, that allows monitoring
> those stats. Test data follows
>
> Tested with 1-segment at layer A, and 12-segment at layer B:
>
> [ 3735.973058] i2c i2c-4: mb86a20s_layer_bitrate: layer A bitrate: 440 kbps; counter = 196608 (0x030000)
> [ 3735.976803] i2c i2c-4: mb86a20s_layer_bitrate: layer B bitrate: 16851 kbps; counter = 8257536 (0x7e0000)
>
> a) Global stats:
>
> Signal strength:
>         QOS_SIGNAL_STRENGTH[0] = 4096
>
> BER (sum of BE count and bit counts for both layers):
>         QOS_BIT_ERROR_COUNT[0] = 1087865
>         QOS_TOTAL_BITS_COUNT[0] = 67043313
>
> b) Per-layer stats:
>
> Layer A BER:
>         QOS_BIT_ERROR_COUNT[1] = 236
>         QOS_TOTAL_BITS_COUNT[1] = 917490
>
> Layer B BER:
>         QOS_BIT_ERROR_COUNT[2] = 1087629
>         QOS_TOTAL_BITS_COUNT[2] = 66125823
>
> TODO:
>         - add more statistics at mb86a20s;
>         - implement support for DTV_QOS_ENUM;
>         - some cleanups at get_frontend logic at dvb core, to avoid
>           it to be called outside the DVB thread loop.
>
> All the above changes can be done a little later during this development
> cycle, so my plan is to merge it upstream at the beginning of the
> next week, to allow others to test.
>


An API should be simple. This is far from simple. This API looks horribly
complex and broken, for anyone to use it in a sane way.

Polling from within dvb-core is not a good idea, as it can cause acquisition
failures. Continuous polling is known to cause issues.

Adding counters to be controlled externally by a user is the most silliest
thing altogether.

All these things put together, makes it the most inconvenient thing to be used.
Eventually, it results in more broken applications than existing.

Not to forget that too much work has to be put into drivers, which aren't going
to make things better, but rather even more worser.


Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 10:55:48 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/15/2013 10:20 AM, Johannes Stezenbach wrote:
> > On Tue, Jan 15, 2013 at 12:30:46AM -0200, Mauro Carvalho Chehab wrote:
> >> Add DVBv5 methods to retrieve QoS statistics.
> >
> > According to http://en.wikipedia.org/wiki/Qos:
> > "Quality of service in computer network trafficking refers
> > to resource reservation control mechanisms"
> >
> > I think it is misleading to use the term QoS for DVB, what
> > the patch series seems to be about is receiption or signal quality.
> 
> I totally agree that (and I have used name signal statistics).

I have no problem on calling it as signal statistics. 

Yet, IMHO, the above definition is not ok. Being worked on a 
telecommunications service provider during a long time, the QoS term 
is used to any measures used to measure the quality level of a service. 
As such, BER measure on a PDH or SDH link is called as a QoS measure.

Ok, in recent years, the mechanism that priorizes voice/video traffic
on an IP network got called QoS mechanisms, as they are there to
improve the QoS measures on an IP link, making them close to the
QoS measures (in particular, latency) obtained on a non-IP media.

Anyway, to avoid confusion, I'll just use "DVB statistics API" on
the next rfc's.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 11:34:37 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/15/2013 04:30 AM, Mauro Carvalho Chehab wrote:
> 
> >      v6: Add DocBook documentation.
> >      v7: Some fixes as suggested by Antti
> >      v8: Documentation fix, compilation fix and name the stats struct,
> >          for its reusage inside the core
> >      v9: counters need 32 bits. So, change the return data types to
> >          s32/u32 types
> >      v10: Counters changed to 64 bits for monotonic increment
> > 	 Don't create a separate get_stats callback. get_frontend
> > 	 is already good enough for it.
> 
> Is there way to return BER as rate, or should it be calculated by the 
> application (from total and error bit counts)?

I don't think it makes sense to let such calculus happen inside Kernel.
It is very easy for userspace to get both numbers at the same ioctl call,
convert from u64 to float and do a float point division in userspace.

In order to handling tose two u64 numbers in kernelspace, the math will
be tricky to avoid overflow. It would also require some scale for BER,
as BER is always a fractional number, generally expressed in E-06 or E-09.

> You seems to change value to 64 bit already, which is enough. 32bit is 
> absolutely too small, it will overflow in seconds (practically around 
> 10sec when there is radio channel of 32MHz and quite optimal conditions).

Yes, 32 bits can cause overflow very quick.

> It is 64bit returned to userspace, is it?

Yes.

> Does 64bit calculations causes any complexity of Kernel or app space?

On the Kernel side, nothing complex was introduced on the frontend I
added it. See the mb86a20s_get_stats function there:
	http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/stats:/drivers/media/dvb-frontends/mb86a20s.c#l934

The logic that fills it is here, at line 953:
	...
	rc = mb86a20s_get_ber_before_vterbi(fe, i, &bit_error, &bit_count);
	if (rc >= 0) {
		c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
		c->bit_error.stat[1 + i].uvalue += bit_error;
		c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
		c->bit_count.stat[1 + i].uvalue += bit_count;
	...

What it was a little more complex were the calculus of a "global" BER measure
for the (up to) 3 layers. I rewrote that code a few times, until I got
satisfied with it. The thing is that, as each layer works like an independent
channel, the BER measure for each layer happens on a different moment.

So, I was in doubt if total BER measure should wait for all layer stats to
be measured or if it should start to appear when the first layer starts to
have statistics. I decided for the second.

On the userspace, I did just a very quick hack at late night yesterday
in order to be able to better see the statistics measures together.
I don't expect any problem to handle those measures there through.
As you can see, the patch that gets all stats is very simple:

	http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/commitdiff/fffeedfd683033c3d97e0b8c781e7486203a0568

What it is missed there is to do the division to convert bit error into BER,
and a logic that would display "dB" or "dBm" if the signal strength/CNR
measures are scaled in dB.

Btw, I'm even in doubt if we should implement the stats ENUM property.
Currently, all unsupported properties are returned with len=0. So, I don't
see any need to have a separate ioctl for that. Perhaps we can just get
rid of it, in order to simplify the API.

Displaying the per-layer stats there can be a little tricky. It probably
only makes sense to display one layer at dvbv5-zap application: the layer
that matches the filtered channel. I need to investigate a little more to
check how to do such match. Maybe the dvbv5-scan application will need to
be able to parse some MPEG descriptor to get such data.

> Basically, that API is more complex that I would like to see, but I can 
> live with it. I still fear making too complex API causes same problems 
> as we has currently... lack of app support.

While coding both drivers and userspace, I didn't fill it to be complex.
At kernelspace, all it was needed were to fill the len for those stats
measures that would be used. Then, to fill the value and the scale when
the measure get available, or to mark them as unavailable, if they
disappear (for example, broadcaster may dynamically change the layers
layout, so one layer measure could disappear at runtime).

at userspace, just one ioctl is enough to get all stats:

	dvb_prop[0].cmd = DTV_QOS_SIGNAL_STRENGTH;
	dvb_prop[1].cmd = DTV_QOS_CNR;
	dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
	dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
	dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
	dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
	props.num = 6;
	props.props = dvb_prop;

	if (ioctl(parms->fd, FE_GET_PROPERTY, &props) == -1)
		perror("FE_GET_PROPERTY");

A simple display mechanism to display all values would be this one:

	for (i = 0; i < 6; i++) {
		for (j = 0; j < dvb_prop[i].u.st.len; j++) {
			if (dvb_prop[i].u.st.stat[j].scale != FE_SCALE_NOT_AVAILABLE)
				printf("%s[%d] = %u\n", dvb_v5_name[dvb_prop[i].cmd], j, (unsigned int)dvb_prop[i].u.st.stat[j].uvalue);
		}
	}

Or, if just the global value is enough:

	for (i = 0; i < 6; i++) {
		if (dvb_prop[i].u.st.stat[0].scale != FE_SCALE_NOT_AVAILABLE)
			printf("%s = %u\n", dvb_v5_name[dvb_prop[i].cmd], (unsigned int)dvb_prop[i].u.st.stat[0].uvalue);
	}


Of course, for BER, we would do, instead:

double BER = ((double)dvb_prop[i].u.st.stat[2].uvalue) / dvb_prop[i].u.st.stat[5].uvalue;

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/15/2013 03:10 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 15 Jan 2013 11:34:37 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 01/15/2013 04:30 AM, Mauro Carvalho Chehab wrote:
>>
>>>       v6: Add DocBook documentation.
>>>       v7: Some fixes as suggested by Antti
>>>       v8: Documentation fix, compilation fix and name the stats struct,
>>>           for its reusage inside the core
>>>       v9: counters need 32 bits. So, change the return data types to
>>>           s32/u32 types
>>>       v10: Counters changed to 64 bits for monotonic increment
>>> 	 Don't create a separate get_stats callback. get_frontend
>>> 	 is already good enough for it.
>>
>> Is there way to return BER as rate, or should it be calculated by the
>> application (from total and error bit counts)?
>
> I don't think it makes sense to let such calculus happen inside Kernel.
> It is very easy for userspace to get both numbers at the same ioctl call,
> convert from u64 to float and do a float point division in userspace.

There may be some devices, having firmware, which calculates BER 
directly instead of returning bit counts. Anyhow, returning bit counts 
is clearly most common and it is always possible to calculate some 
average bit counts from the BER.

Also, BER is calculated before and after the inner coding (pre-BER and 
post-BER). But lets the other (post-BER?) later if there is really need.

I am fine with that.

> In order to handling tose two u64 numbers in kernelspace, the math will
> be tricky to avoid overflow. It would also require some scale for BER,
> as BER is always a fractional number, generally expressed in E-06 or E-09.
>
>> You seems to change value to 64 bit already, which is enough. 32bit is
>> absolutely too small, it will overflow in seconds (practically around
>> 10sec when there is radio channel of 32MHz and quite optimal conditions).
>
> Yes, 32 bits can cause overflow very quick.
>
>> It is 64bit returned to userspace, is it?
>
> Yes.
>
>> Does 64bit calculations causes any complexity of Kernel or app space?
>
> On the Kernel side, nothing complex was introduced on the frontend I
> added it. See the mb86a20s_get_stats function there:
> 	http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/stats:/drivers/media/dvb-frontends/mb86a20s.c#l934
>
> The logic that fills it is here, at line 953:
> 	...
> 	rc = mb86a20s_get_ber_before_vterbi(fe, i, &bit_error, &bit_count);
> 	if (rc >= 0) {
> 		c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
> 		c->bit_error.stat[1 + i].uvalue += bit_error;
> 		c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
> 		c->bit_count.stat[1 + i].uvalue += bit_count;
> 	...
>
> What it was a little more complex were the calculus of a "global" BER measure
> for the (up to) 3 layers. I rewrote that code a few times, until I got
> satisfied with it. The thing is that, as each layer works like an independent
> channel, the BER measure for each layer happens on a different moment.
>
> So, I was in doubt if total BER measure should wait for all layer stats to
> be measured or if it should start to appear when the first layer starts to
> have statistics. I decided for the second.
>
> On the userspace, I did just a very quick hack at late night yesterday
> in order to be able to better see the statistics measures together.
> I don't expect any problem to handle those measures there through.
> As you can see, the patch that gets all stats is very simple:
>
> 	http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/commitdiff/fffeedfd683033c3d97e0b8c781e7486203a0568
>
> What it is missed there is to do the division to convert bit error into BER,
> and a logic that would display "dB" or "dBm" if the signal strength/CNR
> measures are scaled in dB.
>
> Btw, I'm even in doubt if we should implement the stats ENUM property.
> Currently, all unsupported properties are returned with len=0. So, I don't
> see any need to have a separate ioctl for that. Perhaps we can just get
> rid of it, in order to simplify the API.
>
> Displaying the per-layer stats there can be a little tricky. It probably
> only makes sense to display one layer at dvbv5-zap application: the layer
> that matches the filtered channel. I need to investigate a little more to
> check how to do such match. Maybe the dvbv5-scan application will need to
> be able to parse some MPEG descriptor to get such data.
>
>> Basically, that API is more complex that I would like to see, but I can
>> live with it. I still fear making too complex API causes same problems
>> as we has currently... lack of app support.
>
> While coding both drivers and userspace, I didn't fill it to be complex.
> At kernelspace, all it was needed were to fill the len for those stats
> measures that would be used. Then, to fill the value and the scale when
> the measure get available, or to mark them as unavailable, if they
> disappear (for example, broadcaster may dynamically change the layers
> layout, so one layer measure could disappear at runtime).
>
> at userspace, just one ioctl is enough to get all stats:
>
> 	dvb_prop[0].cmd = DTV_QOS_SIGNAL_STRENGTH;
> 	dvb_prop[1].cmd = DTV_QOS_CNR;
> 	dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
> 	dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
> 	dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
> 	dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
> 	props.num = 6;
> 	props.props = dvb_prop;
>
> 	if (ioctl(parms->fd, FE_GET_PROPERTY, &props) == -1)
> 		perror("FE_GET_PROPERTY");
>
> A simple display mechanism to display all values would be this one:
>
> 	for (i = 0; i < 6; i++) {
> 		for (j = 0; j < dvb_prop[i].u.st.len; j++) {
> 			if (dvb_prop[i].u.st.stat[j].scale != FE_SCALE_NOT_AVAILABLE)
> 				printf("%s[%d] = %u\n", dvb_v5_name[dvb_prop[i].cmd], j, (unsigned int)dvb_prop[i].u.st.stat[j].uvalue);
> 		}
> 	}
>
> Or, if just the global value is enough:
>
> 	for (i = 0; i < 6; i++) {
> 		if (dvb_prop[i].u.st.stat[0].scale != FE_SCALE_NOT_AVAILABLE)
> 			printf("%s = %u\n", dvb_v5_name[dvb_prop[i].cmd], (unsigned int)dvb_prop[i].u.st.stat[0].uvalue);
> 	}
>
>
> Of course, for BER, we would do, instead:
>
> double BER = ((double)dvb_prop[i].u.st.stat[2].uvalue) / dvb_prop[i].u.st.stat[5].uvalue;
>

I am a little bit lazy to read all those patches, but I assume it is 
possible:
* return SNR (CNR) as both dB and linear?
* return signal strength as both dBm and linear?

And what happens when when multiple statistics are queried, but fronted 
cannot perform all those?

Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to 
be returned, whilst rest are not possible? As I remember DVBv5 API is 
broken by design and cannot return error code per request.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 16:49:07 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/15/2013 03:10 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 15 Jan 2013 11:34:37 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> On 01/15/2013 04:30 AM, Mauro Carvalho Chehab wrote:
> >>
> >>>       v6: Add DocBook documentation.
> >>>       v7: Some fixes as suggested by Antti
> >>>       v8: Documentation fix, compilation fix and name the stats struct,
> >>>           for its reusage inside the core
> >>>       v9: counters need 32 bits. So, change the return data types to
> >>>           s32/u32 types
> >>>       v10: Counters changed to 64 bits for monotonic increment
> >>> 	 Don't create a separate get_stats callback. get_frontend
> >>> 	 is already good enough for it.
> >>
> >> Is there way to return BER as rate, or should it be calculated by the
> >> application (from total and error bit counts)?
> >
> > I don't think it makes sense to let such calculus happen inside Kernel.
> > It is very easy for userspace to get both numbers at the same ioctl call,
> > convert from u64 to float and do a float point division in userspace.
> 
> There may be some devices, having firmware, which calculates BER 
> directly instead of returning bit counts. Anyhow, returning bit counts 
> is clearly most common and it is always possible to calculate some 
> average bit counts from the BER.

Yeah, converting from BER to bit count should be trivial.

> 
> Also, BER is calculated before and after the inner coding (pre-BER and 
> post-BER). But lets the other (post-BER?) later if there is really need.

Yes.

> I am fine with that.
> 
> > In order to handling tose two u64 numbers in kernelspace, the math will
> > be tricky to avoid overflow. It would also require some scale for BER,
> > as BER is always a fractional number, generally expressed in E-06 or E-09.
> >
> >> You seems to change value to 64 bit already, which is enough. 32bit is
> >> absolutely too small, it will overflow in seconds (practically around
> >> 10sec when there is radio channel of 32MHz and quite optimal conditions).
> >
> > Yes, 32 bits can cause overflow very quick.
> >
> >> It is 64bit returned to userspace, is it?
> >
> > Yes.
> >
> >> Does 64bit calculations causes any complexity of Kernel or app space?
> >
> > On the Kernel side, nothing complex was introduced on the frontend I
> > added it. See the mb86a20s_get_stats function there:
> > 	http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/stats:/drivers/media/dvb-frontends/mb86a20s.c#l934
> >
> > The logic that fills it is here, at line 953:
> > 	...
> > 	rc = mb86a20s_get_ber_before_vterbi(fe, i, &bit_error, &bit_count);
> > 	if (rc >= 0) {
> > 		c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
> > 		c->bit_error.stat[1 + i].uvalue += bit_error;
> > 		c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
> > 		c->bit_count.stat[1 + i].uvalue += bit_count;
> > 	...
> >
> > What it was a little more complex were the calculus of a "global" BER measure
> > for the (up to) 3 layers. I rewrote that code a few times, until I got
> > satisfied with it. The thing is that, as each layer works like an independent
> > channel, the BER measure for each layer happens on a different moment.
> >
> > So, I was in doubt if total BER measure should wait for all layer stats to
> > be measured or if it should start to appear when the first layer starts to
> > have statistics. I decided for the second.
> >
> > On the userspace, I did just a very quick hack at late night yesterday
> > in order to be able to better see the statistics measures together.
> > I don't expect any problem to handle those measures there through.
> > As you can see, the patch that gets all stats is very simple:
> >
> > 	http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/commitdiff/fffeedfd683033c3d97e0b8c781e7486203a0568
> >
> > What it is missed there is to do the division to convert bit error into BER,
> > and a logic that would display "dB" or "dBm" if the signal strength/CNR
> > measures are scaled in dB.
> >
> > Btw, I'm even in doubt if we should implement the stats ENUM property.
> > Currently, all unsupported properties are returned with len=0. So, I don't
> > see any need to have a separate ioctl for that. Perhaps we can just get
> > rid of it, in order to simplify the API.
> >
> > Displaying the per-layer stats there can be a little tricky. It probably
> > only makes sense to display one layer at dvbv5-zap application: the layer
> > that matches the filtered channel. I need to investigate a little more to
> > check how to do such match. Maybe the dvbv5-scan application will need to
> > be able to parse some MPEG descriptor to get such data.
> >
> >> Basically, that API is more complex that I would like to see, but I can
> >> live with it. I still fear making too complex API causes same problems
> >> as we has currently... lack of app support.
> >
> > While coding both drivers and userspace, I didn't fill it to be complex.
> > At kernelspace, all it was needed were to fill the len for those stats
> > measures that would be used. Then, to fill the value and the scale when
> > the measure get available, or to mark them as unavailable, if they
> > disappear (for example, broadcaster may dynamically change the layers
> > layout, so one layer measure could disappear at runtime).
> >
> > at userspace, just one ioctl is enough to get all stats:
> >
> > 	dvb_prop[0].cmd = DTV_QOS_SIGNAL_STRENGTH;
> > 	dvb_prop[1].cmd = DTV_QOS_CNR;
> > 	dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
> > 	dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
> > 	dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
> > 	dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
> > 	props.num = 6;
> > 	props.props = dvb_prop;
> >
> > 	if (ioctl(parms->fd, FE_GET_PROPERTY, &props) == -1)
> > 		perror("FE_GET_PROPERTY");
> >
> > A simple display mechanism to display all values would be this one:
> >
> > 	for (i = 0; i < 6; i++) {
> > 		for (j = 0; j < dvb_prop[i].u.st.len; j++) {
> > 			if (dvb_prop[i].u.st.stat[j].scale != FE_SCALE_NOT_AVAILABLE)
> > 				printf("%s[%d] = %u\n", dvb_v5_name[dvb_prop[i].cmd], j, (unsigned int)dvb_prop[i].u.st.stat[j].uvalue);
> > 		}
> > 	}
> >
> > Or, if just the global value is enough:
> >
> > 	for (i = 0; i < 6; i++) {
> > 		if (dvb_prop[i].u.st.stat[0].scale != FE_SCALE_NOT_AVAILABLE)
> > 			printf("%s = %u\n", dvb_v5_name[dvb_prop[i].cmd], (unsigned int)dvb_prop[i].u.st.stat[0].uvalue);
> > 	}
> >
> >
> > Of course, for BER, we would do, instead:
> >
> > double BER = ((double)dvb_prop[i].u.st.stat[2].uvalue) / dvb_prop[i].u.st.stat[5].uvalue;
> >
> 
> I am a little bit lazy to read all those patches, but I assume it is 
> possible:
> * return SNR (CNR) as both dB and linear?
> * return signal strength as both dBm and linear?

The current API doesn't allow. Driver should report it either as dB or as
linear. That shouldn't be a problem on userspace, as doing a log()/exp()
on userspace is trivial.

> And what happens when when multiple statistics are queried, but fronted 
> cannot perform all those?
> 
> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to 
> be returned, whilst rest are not possible? As I remember DVBv5 API is 
> broken by design and cannot return error code per request.

The one(s) not available will have "FE_SCALE_NOT_AVAILABLE" as scale,
and its value is undefined. 

That actually happens on mb86a20s: signal strength is available all the
time, but BER measures take some time. When I start the application, I
receive a few measures with just signal strength, then layer A or layer B
BER measures (together with global) appear, and finally, the other layer
BER measure pops up.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 16:08:14 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On Tue, Jan 15, 2013 at 8:00 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Add DVBv5 methods to retrieve QoS statistics.
> >
> > Those methods allow per-layer and global statistics.
> >
> > Implemented 2 QoS statistics on mb86a20s, one global only
> > (signal strengh), and one per layer (BER).
> >
> > Tested with a modified version of dvbv5-zap, that allows monitoring
> > those stats. Test data follows
> >
> > Tested with 1-segment at layer A, and 12-segment at layer B:
> >
> > [ 3735.973058] i2c i2c-4: mb86a20s_layer_bitrate: layer A bitrate: 440 kbps; counter = 196608 (0x030000)
> > [ 3735.976803] i2c i2c-4: mb86a20s_layer_bitrate: layer B bitrate: 16851 kbps; counter = 8257536 (0x7e0000)
> >
> > a) Global stats:
> >
> > Signal strength:
> >         QOS_SIGNAL_STRENGTH[0] = 4096
> >
> > BER (sum of BE count and bit counts for both layers):
> >         QOS_BIT_ERROR_COUNT[0] = 1087865
> >         QOS_TOTAL_BITS_COUNT[0] = 67043313
> >
> > b) Per-layer stats:
> >
> > Layer A BER:
> >         QOS_BIT_ERROR_COUNT[1] = 236
> >         QOS_TOTAL_BITS_COUNT[1] = 917490
> >
> > Layer B BER:
> >         QOS_BIT_ERROR_COUNT[2] = 1087629
> >         QOS_TOTAL_BITS_COUNT[2] = 66125823
> >
> > TODO:
> >         - add more statistics at mb86a20s;
> >         - implement support for DTV_QOS_ENUM;
> >         - some cleanups at get_frontend logic at dvb core, to avoid
> >           it to be called outside the DVB thread loop.
> >
> > All the above changes can be done a little later during this development
> > cycle, so my plan is to merge it upstream at the beginning of the
> > next week, to allow others to test.
> >
> 
> 
> An API should be simple. This is far from simple. This API looks horribly
> complex and broken, for anyone to use it in a sane way.

It is not complex. See my answer to Antti with a few code snippets.

> Polling from within dvb-core is not a good idea, as it can cause acquisition
> failures. Continuous polling is known to cause issues.

Polling from Kernel or from userspace has the same results. If a hardware is
known to be broken with polling, the driver needs to handle it. With a
Kernel polling, drivers can have more control, as it should not be hard to
change the dvb-frontend polling time for it to be set by the driver.

It could even be possible to have an interrupt-driven process to update the
statistics, if the hardware supports it.

> Adding counters to be controlled externally by a user is the most silliest
> thing altogether.

Huh? There's nothing that userspace can control. All userspace does with the
API is to read values. Nothing more, nothing less.

> All these things put together, makes it the most inconvenient thing to be used.
> Eventually, it results in more broken applications than existing.
> 
> Not to forget that too much work has to be put into drivers, which aren't going
> to make things better, but rather even more worser.

Not necessarily drivers need to be patched, as the existing callbacks could
be used. Still, I think it makes sense to gradually change the drivers we
care to the new way, in order to provide a better API. Of course, the old 
calls should still work. So, it is not getting anything worser.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/15/2013 04:49 PM, Antti Palosaari wrote:
> I am a little bit lazy to read all those patches, but I assume it is
> possible:
> * return SNR (CNR) as both dB and linear?
> * return signal strength as both dBm and linear?
>
> And what happens when when multiple statistics are queried, but fronted
> cannot perform all those?
>
> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
> be returned, whilst rest are not possible? As I remember DVBv5 API is
> broken by design and cannot return error code per request.

OK, I read that patch still. All these are OK as there is SCALE flag 
used to inform if there is measurement or not available.
No anymore question about these.

Issues what I still would like to raise now are:

1) How about change unit from dB/10 to dB/100 or even dB/1000, just for 
the sure?

2) Counter are reset when DELIVERY SYSTEM is set, practically when 
tuning attempt is done. There is new callback for that, but no API 
command. Functionality is correct for my eyes, is that extra callback 
needed?

3) Post-BER. I don't need it, but is there someone else who thinks there 
should be both pre-BER and post-BER? IMHO, just better to leave it out 
to keep it simple. In practice both pre-BER and post-BER are running 
relatively, lets say if pre-BER shows number 1000 then post-BER shows 
only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much 
interest to return it for userspace. Of course someone would like to 
know how much inner coder is working and fixing error bits and in that 
case both BERs are nice...

4) Returning bit counts as BER and UCB means also driver should start 
polling work in order to keep driver internal counters up to date. 
Returning BER as rate is cheaper in that mean, as driver could make 
decision how often to poll and in which condition (and return values 
from cache). Keeping track of total bit counts means continuous polling!


regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Devin Heitmueller]

On Tue, Jan 15, 2013 at 10:21 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
>> be returned, whilst rest are not possible? As I remember DVBv5 API is
>> broken by design and cannot return error code per request.
>
> The one(s) not available will have "FE_SCALE_NOT_AVAILABLE" as scale,
> and its value is undefined.

We may wish to rethink this approach - it lacks the ability to specify
why the data isn't available.  It would probably be very useful for
userland to know the difference between a statistic not being
available because the hardware doesn't ever provide that data (in
which case a GUI might do something like not show the option), versus
it not being available temporarily due to a lack of signal lock (in
which as a GUI might show the option but indicate that the data is not
currently available).  Likewise I would want to know that data isn't
being shown due to some error condition versus it not being supported
by the hardware or the data being temporarily unavailable due to a
lack of signal lock.

See, I've been thinking about it for two minutes, and already found
three perfectly reasonable error conditions userland would probably
want to differentiate between.  Do we really think it's wise to make
this field the equivalent of a bool?

It might make sense to add something equivalent to errno for a per-stat basis.

Devin

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

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 10:47:50 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> On Tue, Jan 15, 2013 at 10:21 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> >> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
> >> be returned, whilst rest are not possible? As I remember DVBv5 API is
> >> broken by design and cannot return error code per request.
> >
> > The one(s) not available will have "FE_SCALE_NOT_AVAILABLE" as scale,
> > and its value is undefined.
> 
> We may wish to rethink this approach - it lacks the ability to specify
> why the data isn't available.  It would probably be very useful for
> userland to know the difference between a statistic not being
> available because the hardware doesn't ever provide that data (in
> which case a GUI might do something like not show the option),

As already explained:
len = 0 in this case.

> versus
> it not being available temporarily due to a lack of signal lock (in
> which as a GUI might show the option but indicate that the data is not
> currently available).

FE_SCALE_NOT_AVAILABLE

> Likewise I would want to know that data isn't
> being shown due to some error condition versus it not being supported
> by the hardware or the data being temporarily unavailable due to a
> lack of signal lock.

I'm not sure if we have enough bits for a per-layer error error code,
but there is space for a per-stats error code. We can even extend it
to the entire DVBv5 API, as there are some reserved space there.

Yet, IMHO, this is overkill: userspace just needs to know if a given
stats property is not supported by a driver or not available.

> See, I've been thinking about it for two minutes, and already found
> three perfectly reasonable error conditions userland would probably
> want to differentiate between.  Do we really think it's wise to make
> this field the equivalent of a bool?
> 
> It might make sense to add something equivalent to errno for a per-stat basis.

I don't object to add it, but IMHO it is overkill for stats.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 17:26:17 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
> > I am a little bit lazy to read all those patches, but I assume it is
> > possible:
> > * return SNR (CNR) as both dB and linear?
> > * return signal strength as both dBm and linear?
> >
> > And what happens when when multiple statistics are queried, but fronted
> > cannot perform all those?
> >
> > Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
> > be returned, whilst rest are not possible? As I remember DVBv5 API is
> > broken by design and cannot return error code per request.
> 
> OK, I read that patch still. All these are OK as there is SCALE flag 
> used to inform if there is measurement or not available.
> No anymore question about these.
> 
> Issues what I still would like to raise now are:
> 
> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for 
> the sure?

I'm OK with that. I doubt that it would be practical, but we have 64
bits for it, so db/1000 will fit.

> 2) Counter are reset when DELIVERY SYSTEM is set, practically when 
> tuning attempt is done. There is new callback for that, but no API 
> command. Functionality is correct for my eyes, is that extra callback 
> needed?

Not sure. It should be noticed that, at least on ISDB, some sort of 
reset may happen, for example if one layer disappears. The global BER
will (with the current code) reflect the lack of the layer, by not summing
up the data from the removed layer.

Perhaps it makes more sense to, instead, add a way for the driver to flag
when a counter reset happened.

> 3) Post-BER. I don't need it, but is there someone else who thinks there 
> should be both pre-BER and post-BER? IMHO, just better to leave it out 
> to keep it simple. In practice both pre-BER and post-BER are running 
> relatively, lets say if pre-BER shows number 1000 then post-BER shows 
> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much 
> interest to return it for userspace. Of course someone would like to 
> know how much inner coder is working and fixing error bits and in that 
> case both BERs are nice...

I don't see any need for it. In the case of ISDB, I'll likely convert
the post-BER error into per-layer CNR, as it might be useful for one.

I don't have any strong opinion on that though.

> 4) Returning bit counts as BER and UCB means also driver should start 
> polling work in order to keep driver internal counters up to date. 
> Returning BER as rate is cheaper in that mean, as driver could make 
> decision how often to poll and in which condition (and return values 
> from cache). Keeping track of total bit counts means continuous polling!

The way it was specified, the bit count/block count is relative to the
same period where bit error/block error count was taken, and are there
to calculate BER and PER.

Not all frontends allow continuous measurement of BER and PER. In the
case of mb86a20s, BER is currently not continuous. I think that there's
a way to do continuous PER measurement, but I need to double-check
it.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 15 Jan 2013 17:26:17 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
>>> I am a little bit lazy to read all those patches, but I assume it is
>>> possible:
>>> * return SNR (CNR) as both dB and linear?
>>> * return signal strength as both dBm and linear?
>>>
>>> And what happens when when multiple statistics are queried, but fronted
>>> cannot perform all those?
>>>
>>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
>>> be returned, whilst rest are not possible? As I remember DVBv5 API is
>>> broken by design and cannot return error code per request.
>>
>> OK, I read that patch still. All these are OK as there is SCALE flag
>> used to inform if there is measurement or not available.
>> No anymore question about these.
>>
>> Issues what I still would like to raise now are:
>>
>> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
>> the sure?
>
> I'm OK with that. I doubt that it would be practical, but we have 64
> bits for it, so db/1000 will fit.
>
>> 2) Counter are reset when DELIVERY SYSTEM is set, practically when
>> tuning attempt is done. There is new callback for that, but no API
>> command. Functionality is correct for my eyes, is that extra callback
>> needed?
>
> Not sure. It should be noticed that, at least on ISDB, some sort of
> reset may happen, for example if one layer disappears. The global BER
> will (with the current code) reflect the lack of the layer, by not summing
> up the data from the removed layer.
>
> Perhaps it makes more sense to, instead, add a way for the driver to flag
> when a counter reset happened.
>
>> 3) Post-BER. I don't need it, but is there someone else who thinks there
>> should be both pre-BER and post-BER? IMHO, just better to leave it out
>> to keep it simple. In practice both pre-BER and post-BER are running
>> relatively, lets say if pre-BER shows number 1000 then post-BER shows
>> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
>> interest to return it for userspace. Of course someone would like to
>> know how much inner coder is working and fixing error bits and in that
>> case both BERs are nice...
>
> I don't see any need for it. In the case of ISDB, I'll likely convert
> the post-BER error into per-layer CNR, as it might be useful for one.
>
> I don't have any strong opinion on that though.
>
>> 4) Returning bit counts as BER and UCB means also driver should start
>> polling work in order to keep driver internal counters up to date.
>> Returning BER as rate is cheaper in that mean, as driver could make
>> decision how often to poll and in which condition (and return values
>> from cache). Keeping track of total bit counts means continuous polling!
>
> The way it was specified, the bit count/block count is relative to the
> same period where bit error/block error count was taken, and are there
> to calculate BER and PER.

Eh, then this is functionality is against 2) what I asked about 
functionality of the counter reset. You should make decision to increase 
counters continuously and reset only given condition (on channel tune as 
it is done now) OR leave whole counter reset and increase to 
responsibility of the driver.

Do you see conflict here???

My opinion is to remove counter reset callback and leave all to 
responsibility of the driver.

> Not all frontends allow continuous measurement of BER and PER. In the
> case of mb86a20s, BER is currently not continuous. I think that there's
> a way to do continuous PER measurement, but I need to double-check
> it.

Personally I am going to implement that way it returns those bit counts 
from the driver cache. Driver makes decision when to make measurements, 
like just after channel is tuned and after that maybe once per minute or so.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari <crope@iki.fi> wrote:
> On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
>>
>> Em Tue, 15 Jan 2013 17:26:17 +0200
>> Antti Palosaari <crope@iki.fi> escreveu:
>>
>>> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
>>>>
>>>> I am a little bit lazy to read all those patches, but I assume it is
>>>> possible:
>>>> * return SNR (CNR) as both dB and linear?
>>>> * return signal strength as both dBm and linear?
>>>>
>>>> And what happens when when multiple statistics are queried, but fronted
>>>> cannot perform all those?
>>>>
>>>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
>>>> be returned, whilst rest are not possible? As I remember DVBv5 API is
>>>> broken by design and cannot return error code per request.
>>>
>>>
>>> OK, I read that patch still. All these are OK as there is SCALE flag
>>> used to inform if there is measurement or not available.
>>> No anymore question about these.
>>>
>>> Issues what I still would like to raise now are:
>>>
>>> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
>>> the sure?
>>
>>
>> I'm OK with that. I doubt that it would be practical, but we have 64
>> bits for it, so db/1000 will fit.
>>
>>> 2) Counter are reset when DELIVERY SYSTEM is set, practically when
>>> tuning attempt is done. There is new callback for that, but no API
>>> command. Functionality is correct for my eyes, is that extra callback
>>> needed?
>>
>>
>> Not sure. It should be noticed that, at least on ISDB, some sort of
>> reset may happen, for example if one layer disappears. The global BER
>> will (with the current code) reflect the lack of the layer, by not summing
>> up the data from the removed layer.
>>
>> Perhaps it makes more sense to, instead, add a way for the driver to flag
>> when a counter reset happened.
>>
>>> 3) Post-BER. I don't need it, but is there someone else who thinks there
>>> should be both pre-BER and post-BER? IMHO, just better to leave it out
>>> to keep it simple. In practice both pre-BER and post-BER are running
>>> relatively, lets say if pre-BER shows number 1000 then post-BER shows
>>> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
>>> interest to return it for userspace. Of course someone would like to
>>> know how much inner coder is working and fixing error bits and in that
>>> case both BERs are nice...
>>
>>
>> I don't see any need for it. In the case of ISDB, I'll likely convert
>> the post-BER error into per-layer CNR, as it might be useful for one.
>>
>> I don't have any strong opinion on that though.
>>
>>> 4) Returning bit counts as BER and UCB means also driver should start
>>> polling work in order to keep driver internal counters up to date.
>>> Returning BER as rate is cheaper in that mean, as driver could make
>>> decision how often to poll and in which condition (and return values
>>> from cache). Keeping track of total bit counts means continuous polling!
>>
>>
>> The way it was specified, the bit count/block count is relative to the
>> same period where bit error/block error count was taken, and are there
>> to calculate BER and PER.
>
>
> Eh, then this is functionality is against 2) what I asked about
> functionality of the counter reset. You should make decision to increase
> counters continuously and reset only given condition (on channel tune as it
> is done now) OR leave whole counter reset and increase to responsibility of
> the driver.
>
> Do you see conflict here???
>
> My opinion is to remove counter reset callback and leave all to
> responsibility of the driver.


This, Is exactly one of the arguments that I raised. All statistics
measurements
should be the responsibility of the driver. Anything other than that,
such an API
is broken.


>
>> Not all frontends allow continuous measurement of BER and PER. In the
>> case of mb86a20s, BER is currently not continuous. I think that there's
>> a way to do continuous PER measurement, but I need to double-check
>> it.
>
>
> Personally I am going to implement that way it returns those bit counts from
> the driver cache. Driver makes decision when to make measurements, like just
> after channel is tuned and after that maybe once per minute or so.


No Error Rate measurement, ie BER, PER or FER measurement can/will be
continuous on *any* demodulator. First, there should be the minimum number of
frames that should pass through the decision box, then for that number
of frames
to occur, depending upon the delivery system and the implementation type, the
time required for this to be calculated on the demodulator FPGA will vary and
cannot be expected that it will be available at this instance or at
another instance.
All demodulators vary from one to another the way it is implemented. On most
demodulators, while trying to do computations within the decision box
whil trying
to acquire, or in some case while it has not acquired Synchronous Viterbi will
result in acquisition failure, longer time for acquisition, or even sub-optimal
acquisition etc, depending on a variety of factors. In short, only the
algorithms
used in a driver for the demodulator when it is safe to do measurements and no
one else.

This API implementation assumes that someone else or the dvb-core or
whomsoever does this role. Hence this QoS API is broken, not to forget
that even
while making it so complex to use, which should have been something so simple.

The simplest and easiest way to achieve commonality between the various
demodulators is to use the existing API and scale whatever documented
demodulators to that scacle, to best possible way, rather than adding more
ambiguity and breakage.

What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled
to a maxima minima, rather than adding in complexities. This already exists,
all it needs to do is add some more devices to be scaled to that convention.
And more importantly, one is not going to get that real professional
measurements
 from these *home segment* devices. One of the chipset manufacturers once told
me that the PC segment never was interested in any real world performance
oriented devices, it is all about cost and hence it is stuck with such
low devices.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Luca Olivetti]

Al 16/01/2013 5:26, En/na Manu Abraham ha escrit:

> The simplest and easiest way to achieve commonality between the various
> demodulators is to use the existing API and scale whatever documented
> demodulators to that scacle, to best possible way, rather than adding more
> ambiguity and breakage.

Note that an older version of the linux dvb api documentation clearly 
specified the scale to use, i.e. see

http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf

"The bit error rate, as a multiple of 10E-9 , is stored into
*ber. Example: a value of 2500 corresponds to a bit error rate
of 2.5 * 10E-6 or 1 error in 400000 bits."

"The signal-to-noise ratio, as a multiple of 10E-6 dB, is
stored into *snr. Example: a value of 12,300,000 corresponds to a 
signal-to-noise ratio of 12.3 dB."

"The signal strength value, as a multiple of 10E-6 dBm, is
stored into *strength. Example: a value of -12,500,000 corresponds to a 
signalstrength value of -12.5 dBm."

but for some reason later revisions of the api don't include the scale

Bye
-- 
Luca

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Tue, 15 Jan 2013 22:37:40 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 15 Jan 2013 17:26:17 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
> >>> I am a little bit lazy to read all those patches, but I assume it is
> >>> possible:
> >>> * return SNR (CNR) as both dB and linear?
> >>> * return signal strength as both dBm and linear?
> >>>
> >>> And what happens when when multiple statistics are queried, but fronted
> >>> cannot perform all those?
> >>>
> >>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
> >>> be returned, whilst rest are not possible? As I remember DVBv5 API is
> >>> broken by design and cannot return error code per request.
> >>
> >> OK, I read that patch still. All these are OK as there is SCALE flag
> >> used to inform if there is measurement or not available.
> >> No anymore question about these.
> >>
> >> Issues what I still would like to raise now are:
> >>
> >> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
> >> the sure?
> >
> > I'm OK with that. I doubt that it would be practical, but we have 64
> > bits for it, so db/1000 will fit.
> >
> >> 2) Counter are reset when DELIVERY SYSTEM is set, practically when
> >> tuning attempt is done. There is new callback for that, but no API
> >> command. Functionality is correct for my eyes, is that extra callback
> >> needed?
> >
> > Not sure. It should be noticed that, at least on ISDB, some sort of
> > reset may happen, for example if one layer disappears. The global BER
> > will (with the current code) reflect the lack of the layer, by not summing
> > up the data from the removed layer.
> >
> > Perhaps it makes more sense to, instead, add a way for the driver to flag
> > when a counter reset happened.
> >
> >> 3) Post-BER. I don't need it, but is there someone else who thinks there
> >> should be both pre-BER and post-BER? IMHO, just better to leave it out
> >> to keep it simple. In practice both pre-BER and post-BER are running
> >> relatively, lets say if pre-BER shows number 1000 then post-BER shows
> >> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
> >> interest to return it for userspace. Of course someone would like to
> >> know how much inner coder is working and fixing error bits and in that
> >> case both BERs are nice...
> >
> > I don't see any need for it. In the case of ISDB, I'll likely convert
> > the post-BER error into per-layer CNR, as it might be useful for one.
> >
> > I don't have any strong opinion on that though.
> >
> >> 4) Returning bit counts as BER and UCB means also driver should start
> >> polling work in order to keep driver internal counters up to date.
> >> Returning BER as rate is cheaper in that mean, as driver could make
> >> decision how often to poll and in which condition (and return values
> >> from cache). Keeping track of total bit counts means continuous polling!
> >
> > The way it was specified, the bit count/block count is relative to the
> > same period where bit error/block error count was taken, and are there
> > to calculate BER and PER.
> 
> Eh, then this is functionality is against 2) what I asked about 
> functionality of the counter reset. You should make decision to increase 
> counters continuously and reset only given condition (on channel tune as 
> it is done now) OR leave whole counter reset and increase to 
> responsibility of the driver.

Currently, it is monotonically increased after (2).

There is one exception for it on the current implementation: in the case 
of multi-layers, where one layer vanishes - the global measure will
not sum up the count for the vanished layer. Get rid of this behavior
is not easy (and probably not right). I think that, in practice, such
event would take years to happen, as broadcasters won't be changing the
layers layout without a good reason (like adding multi-program streams or
adding HD program on a channel that used to have only SD).

> Do you see conflict here???
> 
> My opinion is to remove counter reset callback and leave all to 
> responsibility of the driver.

IMO, the better is to live the responsibility to the driver. In this case, it
makes sense to specify in the API that the drivers will reset it before
overflow, and add some flag to indicate that a counter got a reset.

> 
> > Not all frontends allow continuous measurement of BER and PER. In the
> > case of mb86a20s, BER is currently not continuous. I think that there's
> > a way to do continuous PER measurement, but I need to double-check
> > it.
> 
> Personally I am going to implement that way it returns those bit counts 
> from the driver cache. Driver makes decision when to make measurements, 
> like just after channel is tuned and after that maybe once per minute or so.

Right now, it is driver's decision on how to make such measures.

I can see two ways of updating the status flags:

1) during DVB frontend polling call to get_frontend (or to other stats/status
   callbacks);

2) on a kernel thread inside the frontend driver, updating the cache.

(1) is serialized. However, if we're willing to allow (2), we'll need to 
have a lock (likely spinlock) to protect the cache data, as otherwise we may 
have race conditions between:
	a) the dvb-frontend ioctl handling and the driver's kthread;
	b) the dvb-frontend kthread calling get_frontend and the driver's
	   kthread.

If we add such lock, drivers can decide to do either (1) or (2). On a quick
look, no frontend drivers currently have any threads. So, let's not add
additinal complexity without a driver requiring it. At the time we have
any driver requiring (2), the corresponding lock patches to protect 
fe->dtv_property_cache concurrent access should be submitted.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 16 Jan 2013 09:56:12 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari <crope@iki.fi> wrote:
> > On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
> >>
> >> Em Tue, 15 Jan 2013 17:26:17 +0200
> >> Antti Palosaari <crope@iki.fi> escreveu:
> >>
> >>> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
> >>>>
> >>>> I am a little bit lazy to read all those patches, but I assume it is
> >>>> possible:
> >>>> * return SNR (CNR) as both dB and linear?
> >>>> * return signal strength as both dBm and linear?
> >>>>
> >>>> And what happens when when multiple statistics are queried, but fronted
> >>>> cannot perform all those?
> >>>>
> >>>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
> >>>> be returned, whilst rest are not possible? As I remember DVBv5 API is
> >>>> broken by design and cannot return error code per request.
> >>>
> >>>
> >>> OK, I read that patch still. All these are OK as there is SCALE flag
> >>> used to inform if there is measurement or not available.
> >>> No anymore question about these.
> >>>
> >>> Issues what I still would like to raise now are:
> >>>
> >>> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
> >>> the sure?
> >>
> >>
> >> I'm OK with that. I doubt that it would be practical, but we have 64
> >> bits for it, so db/1000 will fit.
> >>
> >>> 2) Counter are reset when DELIVERY SYSTEM is set, practically when
> >>> tuning attempt is done. There is new callback for that, but no API
> >>> command. Functionality is correct for my eyes, is that extra callback
> >>> needed?
> >>
> >>
> >> Not sure. It should be noticed that, at least on ISDB, some sort of
> >> reset may happen, for example if one layer disappears. The global BER
> >> will (with the current code) reflect the lack of the layer, by not summing
> >> up the data from the removed layer.
> >>
> >> Perhaps it makes more sense to, instead, add a way for the driver to flag
> >> when a counter reset happened.
> >>
> >>> 3) Post-BER. I don't need it, but is there someone else who thinks there
> >>> should be both pre-BER and post-BER? IMHO, just better to leave it out
> >>> to keep it simple. In practice both pre-BER and post-BER are running
> >>> relatively, lets say if pre-BER shows number 1000 then post-BER shows
> >>> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
> >>> interest to return it for userspace. Of course someone would like to
> >>> know how much inner coder is working and fixing error bits and in that
> >>> case both BERs are nice...
> >>
> >>
> >> I don't see any need for it. In the case of ISDB, I'll likely convert
> >> the post-BER error into per-layer CNR, as it might be useful for one.
> >>
> >> I don't have any strong opinion on that though.
> >>
> >>> 4) Returning bit counts as BER and UCB means also driver should start
> >>> polling work in order to keep driver internal counters up to date.
> >>> Returning BER as rate is cheaper in that mean, as driver could make
> >>> decision how often to poll and in which condition (and return values
> >>> from cache). Keeping track of total bit counts means continuous polling!
> >>
> >>
> >> The way it was specified, the bit count/block count is relative to the
> >> same period where bit error/block error count was taken, and are there
> >> to calculate BER and PER.
> >
> >
> > Eh, then this is functionality is against 2) what I asked about
> > functionality of the counter reset. You should make decision to increase
> > counters continuously and reset only given condition (on channel tune as it
> > is done now) OR leave whole counter reset and increase to responsibility of
> > the driver.
> >
> > Do you see conflict here???
> >
> > My opinion is to remove counter reset callback and leave all to
> > responsibility of the driver.
> 
> 
> This, Is exactly one of the arguments that I raised. All statistics
> measurements
> should be the responsibility of the driver. Anything other than that,
> such an API
> is broken.

All statistics measurements are already driver's responsibility on the 
proposed patches. The question is when to reset the counters.

> >> Not all frontends allow continuous measurement of BER and PER. In the
> >> case of mb86a20s, BER is currently not continuous. I think that there's
> >> a way to do continuous PER measurement, but I need to double-check
> >> it.
> >
> >
> > Personally I am going to implement that way it returns those bit counts from
> > the driver cache. Driver makes decision when to make measurements, like just
> > after channel is tuned and after that maybe once per minute or so.
> 
> 
> No Error Rate measurement, ie BER, PER or FER measurement can/will be
> continuous on *any* demodulator. 

There's one of the above measure on mb86a20s that can be continuous (MER). On
continuous mode, the demod will automatically start the next measure when the
results got available. There's a lock bit that prevents the data to be
overridden during the time the value is being read.

> First, there should be the minimum number of
> frames that should pass through the decision box, then for that number
> of frames
> to occur, depending upon the delivery system and the implementation type, the
> time required for this to be calculated on the demodulator FPGA will vary and
> cannot be expected that it will be available at this instance or at
> another instance.
> All demodulators vary from one to another the way it is implemented. On most
> demodulators, while trying to do computations within the decision box
> whil trying
> to acquire, or in some case while it has not acquired Synchronous Viterbi will
> result in acquisition failure, longer time for acquisition, or even sub-optimal
> acquisition etc, depending on a variety of factors. In short, only the
> algorithms
> used in a driver for the demodulator when it is safe to do measurements and no
> one else.
> 
> This API implementation assumes that someone else or the dvb-core or
> whomsoever does this role. Hence this QoS API is broken, not to forget
> that even
> while making it so complex to use, which should have been something so simple.

No, it seems you misread the code. The API doesn't make such assumption,
nor the implementation does.

If you take a look at the implementation, it just uses the get_frontend()
as a way to check if the already started measure already finished. If so,
it will update the cache and request a new data collect [1].

The simplified logic there is:

static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
					  unsigned layer,
					  u32 *error, u32 *count)
{
...
	/* Check if the BER measures are already available */
	rc = mb86a20s_readreg(state, 0x54);
	if (rc < 0)
		return rc;

	/*
	 * Check if data is available for that layer
	 * bit 0 means layer A, bit 1 means layer B, bit 2 means layer C
	 */
	if (!(rc & (1 << layer))) {
		dev_info(&state->i2c->dev,
			"%s: BER for layer %c is not available yet.\n",
			__func__, 'A' + layer);
		return -EBUSY;
	}
...
	/*
	 * Logic to read the BER registers for that layer and to
	 * start another measure
	 */
}

static int mb86a20s_get_stats(struct dvb_frontend *fe)
{
...
	/* Get per-layer stats */
	for (i = 0; i < 3; i++) {
		rc = mb86a20s_get_ber_before_vterbi(fe, i, &bit_error, &bit_count);
		if (rc >= 0) {
			/* Data is ready, update the cache */
		}
	}
...
}

The dvb-frontend thread is there to just:
	1) serialize the access to the cache;
	2) call the polling code that checks if the hardware already
calculated the measure.

[1] see: http://git.linuxtv.org/mchehab/experimental.git/blob/refs/heads/stats:/drivers/media/dvb-frontends/mb86a20s.c

> The simplest and easiest way to achieve commonality between the various
> demodulators is to use the existing API and scale whatever documented
> demodulators to that scacle, to best possible way, rather than adding more
> ambiguity and breakage.

This were largely discussed. The existing API is broken. Even adding a scale
there right now is impossible, as nobody knows what scale is used on several
old drivers. Also, the existing API doesn't support newer standards like ISDB.

> What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled
> to a maxima minima, rather than adding in complexities. This already exists,
> all it needs to do is add some more devices to be scaled to that convention.
> And more importantly, one is not going to get that real professional
> measurements
>  from these *home segment* devices. One of the chipset manufacturers once told
> me that the PC segment never was interested in any real world performance
> oriented devices, it is all about cost and hence it is stuck with such
> low devices.

The DVB API should be able to fit on both home and professional segment.

Anyway, the existing API will be kept. Userspace may opt to use the legacy
API if they're not interested on a scaled value.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Wed, Jan 16, 2013 at 7:26 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Wed, 16 Jan 2013 09:56:12 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari <crope@iki.fi> wrote:
>> > On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
>> >>
>> >> Em Tue, 15 Jan 2013 17:26:17 +0200
>> >> Antti Palosaari <crope@iki.fi> escreveu:
>> >>
>> >>> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
>> >>>>
>> >>>> I am a little bit lazy to read all those patches, but I assume it is
>> >>>> possible:
>> >>>> * return SNR (CNR) as both dB and linear?
>> >>>> * return signal strength as both dBm and linear?
>> >>>>
>> >>>> And what happens when when multiple statistics are queried, but fronted
>> >>>> cannot perform all those?
>> >>>>
>> >>>> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to
>> >>>> be returned, whilst rest are not possible? As I remember DVBv5 API is
>> >>>> broken by design and cannot return error code per request.
>> >>>
>> >>>
>> >>> OK, I read that patch still. All these are OK as there is SCALE flag
>> >>> used to inform if there is measurement or not available.
>> >>> No anymore question about these.
>> >>>
>> >>> Issues what I still would like to raise now are:
>> >>>
>> >>> 1) How about change unit from dB/10 to dB/100 or even dB/1000, just for
>> >>> the sure?
>> >>
>> >>
>> >> I'm OK with that. I doubt that it would be practical, but we have 64
>> >> bits for it, so db/1000 will fit.
>> >>
>> >>> 2) Counter are reset when DELIVERY SYSTEM is set, practically when
>> >>> tuning attempt is done. There is new callback for that, but no API
>> >>> command. Functionality is correct for my eyes, is that extra callback
>> >>> needed?
>> >>
>> >>
>> >> Not sure. It should be noticed that, at least on ISDB, some sort of
>> >> reset may happen, for example if one layer disappears. The global BER
>> >> will (with the current code) reflect the lack of the layer, by not summing
>> >> up the data from the removed layer.
>> >>
>> >> Perhaps it makes more sense to, instead, add a way for the driver to flag
>> >> when a counter reset happened.
>> >>
>> >>> 3) Post-BER. I don't need it, but is there someone else who thinks there
>> >>> should be both pre-BER and post-BER? IMHO, just better to leave it out
>> >>> to keep it simple. In practice both pre-BER and post-BER are running
>> >>> relatively, lets say if pre-BER shows number 1000 then post-BER shows
>> >>> only 10. Or pre-BER 600, post-BER 6. Due to that, I don't see much
>> >>> interest to return it for userspace. Of course someone would like to
>> >>> know how much inner coder is working and fixing error bits and in that
>> >>> case both BERs are nice...
>> >>
>> >>
>> >> I don't see any need for it. In the case of ISDB, I'll likely convert
>> >> the post-BER error into per-layer CNR, as it might be useful for one.
>> >>
>> >> I don't have any strong opinion on that though.
>> >>
>> >>> 4) Returning bit counts as BER and UCB means also driver should start
>> >>> polling work in order to keep driver internal counters up to date.
>> >>> Returning BER as rate is cheaper in that mean, as driver could make
>> >>> decision how often to poll and in which condition (and return values
>> >>> from cache). Keeping track of total bit counts means continuous polling!
>> >>
>> >>
>> >> The way it was specified, the bit count/block count is relative to the
>> >> same period where bit error/block error count was taken, and are there
>> >> to calculate BER and PER.
>> >
>> >
>> > Eh, then this is functionality is against 2) what I asked about
>> > functionality of the counter reset. You should make decision to increase
>> > counters continuously and reset only given condition (on channel tune as it
>> > is done now) OR leave whole counter reset and increase to responsibility of
>> > the driver.
>> >
>> > Do you see conflict here???
>> >
>> > My opinion is to remove counter reset callback and leave all to
>> > responsibility of the driver.
>>
>>
>> This, Is exactly one of the arguments that I raised. All statistics
>> measurements
>> should be the responsibility of the driver. Anything other than that,
>> such an API
>> is broken.
>
> All statistics measurements are already driver's responsibility on the
> proposed patches. The question is when to reset the counters.




Maybe you should give more thoughts to what you say in comparison
to your patch. It looks like your comments contradict your patch.



>> >> Not all frontends allow continuous measurement of BER and PER. In the
>> >> case of mb86a20s, BER is currently not continuous. I think that there's
>> >> a way to do continuous PER measurement, but I need to double-check
>> >> it.
>> >
>> >
>> > Personally I am going to implement that way it returns those bit counts from
>> > the driver cache. Driver makes decision when to make measurements, like just
>> > after channel is tuned and after that maybe once per minute or so.
>>
>>
>> No Error Rate measurement, ie BER, PER or FER measurement can/will be
>> continuous on *any* demodulator.
>
> There's one of the above measure on mb86a20s that can be continuous (MER). On
> continuous mode, the demod will automatically start the next measure when the
> results got available. There's a lock bit that prevents the data to be
> overridden during the time the value is being read.


Please stop your bluffing of people.
MER or Modulation Error Ratio is the Ratio between the RMS Signal Power to the
RMS Error Power. When you state that *any* Home segment device which
is supposed
to be a cheap device doing demodulation, Error Correction and a
plethora of other things:
is doing real time RMS computations and generating ratios out of it,
It makes me laugh.

Now, that lock bit in that demodulator of yours expresses most likely
what it is doing,
It is most likely taking a snapshot of the parameters, doing
computations and outputting
the values to some shadowed registers.

As others have stated in various threads, please stop giving excuses
to cause breaking
stuff.

>> First, there should be the minimum number of
>> frames that should pass through the decision box, then for that number
>> of frames
>> to occur, depending upon the delivery system and the implementation type, the
>> time required for this to be calculated on the demodulator FPGA will vary and
>> cannot be expected that it will be available at this instance or at
>> another instance.
>> All demodulators vary from one to another the way it is implemented. On most
>> demodulators, while trying to do computations within the decision box
>> whil trying
>> to acquire, or in some case while it has not acquired Synchronous Viterbi will
>> result in acquisition failure, longer time for acquisition, or even sub-optimal
>> acquisition etc, depending on a variety of factors. In short, only the
>> algorithms
>> used in a driver for the demodulator when it is safe to do measurements and no
>> one else.
>>
>> This API implementation assumes that someone else or the dvb-core or
>> whomsoever does this role. Hence this QoS API is broken, not to forget
>> that even
>> while making it so complex to use, which should have been something so simple.
>
> No, it seems you misread the code. The API doesn't make such assumption,
> nor the implementation does.


I didn't misread the code, but with an understanding of what it does.

>
>> The simplest and easiest way to achieve commonality between the various
>> demodulators is to use the existing API and scale whatever documented
>> demodulators to that scacle, to best possible way, rather than adding more
>> ambiguity and breakage.
>
> This were largely discussed. The existing API is broken. Even adding a scale
> there right now is impossible, as nobody knows what scale is used on several
> old drivers. Also, the existing API doesn't support newer standards like ISDB.


The old API is not dependent on any DVB standard, but it is purely a measure.
If you have sufficient documentation, you can scale your demodulator statistics
to fit in that window area. I had done something similarly with a MB86A16
demodulator. IIRC, some effort was done on the STV0900 and STV0903
demodulator support as well to fit into that convention.

All you need to do is scale the output of your demodulator to fit into
that window.
What you are stating are just excuses, that do not exist.

The same issue will exist, even with a new API and newer drivers not complying
to that API. I don't understand, why you fail to accept that fact.


>> What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled
>> to a maxima minima, rather than adding in complexities. This already exists,
>> all it needs to do is add some more devices to be scaled to that convention.
>> And more importantly, one is not going to get that real professional
>> measurements
>>  from these *home segment* devices. One of the chipset manufacturers once told
>> me that the PC segment never was interested in any real world performance
>> oriented devices, it is all about cost and hence it is stuck with such
>> low devices.
>
> The DVB API should be able to fit on both home and professional segment.


I don't see any professional hardware drivers being written for the
Linux DVB API.
Care to prove me wrong ? You have been driving people away with your nonsense
arguments.. See the case with Andreas Oberitter as the latest person .. Because
of your silliness, the Dreambox people seems looking forward to
shipping their own
headers instead.. Simply causing fragmentation of a community...

Simply look back upon yourselves on various mailing lists.. QoS, MIB ..

>
> Anyway, the existing API will be kept. Userspace may opt to use the legacy
> API if they're not interested on a scaled value.


That is simply stating, that whatever other people like it or not, you
will whack
nonsense in.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 16 Jan 2013 20:49:05 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On Wed, Jan 16, 2013 at 7:26 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
> > Em Wed, 16 Jan 2013 09:56:12 +0530
> > Manu Abraham <abraham.manu@gmail.com> escreveu:
> >
> >> On Wed, Jan 16, 2013 at 2:07 AM, Antti Palosaari <crope@iki.fi> wrote:
> >> > On 01/15/2013 07:12 PM, Mauro Carvalho Chehab wrote:
> >> >>
> >> >> Em Tue, 15 Jan 2013 17:26:17 +0200
> >> >> Antti Palosaari <crope@iki.fi> escreveu:
> >> >>
> >> >>> On 01/15/2013 04:49 PM, Antti Palosaari wrote:
> >> >>>>

...

> >> No Error Rate measurement, ie BER, PER or FER measurement can/will be
> >> continuous on *any* demodulator.
> >
> > There's one of the above measure on mb86a20s that can be continuous (MER). On
> > continuous mode, the demod will automatically start the next measure when the
> > results got available. There's a lock bit that prevents the data to be
> > overridden during the time the value is being read.
> 
> 
> Please stop your bluffing of people.
> MER or Modulation Error Ratio is the Ratio between the RMS Signal Power to the
> RMS Error Power. When you state that *any* Home segment device which
> is supposed
> to be a cheap device doing demodulation, Error Correction and a
> plethora of other things:
> is doing real time RMS computations and generating ratios out of it,
> It makes me laugh.

Huh, can't you read my English? I never said *any* Home segment device.

I said, instead, that, on *mb86a20s*, for some measurements, like MER and CNR,
there are two operational modes: automatic and manual. 

On automatic mode, the demod is continuously updating the measurements,
and no data is discarded on such measures.

In manual mode, it measures just a certain amount of time and stops.
The kthread needs to manually start another measure. So, it is actually
taken samples of the measurement.

In manual mode, the measures are discrete in the sense that, if errors 
occur between outside the measurement intervals, those errors won't affect
the measurement report.

In the automatic mode, the measures are continuous in the sense that every
error bit will affect the measurement.

Yet, on both modes, the demod will wait for a given bit count (the
bit count is programmable) to update the corresponding I2C registers.

> 
> Now, that lock bit in that demodulator of yours expresses most likely
> what it is doing,
> It is most likely taking a snapshot of the parameters, doing
> computations and outputting
> the values to some shadowed registers.

Yes. I never said otherwise.

> As others have stated in various threads, please stop giving excuses
> to cause breaking
> stuff.

On my tests with the hardware, I can't see anything broken.

However, if you're seeing something broken, please point to the specific patch
and patch hunk.

> The old API is not dependent on any DVB standard, but it is purely a measure.

It is, as it assumes that there's just one physical channel per transponder.
ISDB doesn't fit on such concept, as it has 3 physical channels, each with
its own CNR, BER, etc.

As shown on the fist email of this series, measured with a real hardware,
the BER before viterbi on a given signal condition was:

Layer A BER:
	QOS_BIT_ERROR_COUNT[1] = 236
	QOS_TOTAL_BITS_COUNT[1] = 917490

Layer B BER:
	QOS_BIT_ERROR_COUNT[2] = 1087629
	QOS_TOTAL_BITS_COUNT[2] = 66125823

Clearly, the statistics for layer A is very different than the ones for
Layer B. With the above stats, layer B (12-segment) is unusable, as BER is just
too high.  However, Layer A (1-segment) is usable.

There are two programs being transmitted on the above ISDB-T channel. The
1-seg one works, as FEC 1/2 will likely fix most (or all) of the 236 errors there;
the 12-seg one doesn't, because of the low S/N ratio of layer B physical channel,
and the BER is just too high for FEC 7/8 to correct.

> If you have sufficient documentation, you can scale your demodulator statistics
> to fit in that window area. I had done something similarly with a MB86A16
> demodulator. IIRC, some effort was done on the STV0900 and STV0903
> demodulator support as well to fit into that convention.
> 
> All you need to do is scale the output of your demodulator to fit into
> that window.

To what scale? dB? linear? 0% to 100%?

As there's no way to tell what's the used scale, if some scale is required,
_all_ demods are required to be converted to that scale, otherwise, userspace
can't rely on the scale.

Are you capable of doing such change on _all demods? If not, please stop 
arguing that the existing API can be fixable.

Besides that, changing the existing stats to whatever scale breaks
userspace compatibility.

BREAKING USERSPACE IS A BIG NO.

> What you are stating are just excuses, that do not exist.
> 
> The same issue will exist, even with a new API and newer drivers not complying
> to that API. I don't understand, why you fail to accept that fact.

Newer drivers that don't implement an API right (being the a new one or an
existing one) need to be fixed before being merged. 

It is as simple as that.

> >> What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled
> >> to a maxima minima, rather than adding in complexities. This already exists,
> >> all it needs to do is add some more devices to be scaled to that convention.
> >> And more importantly, one is not going to get that real professional
> >> measurements
> >>  from these *home segment* devices. One of the chipset manufacturers once told
> >> me that the PC segment never was interested in any real world performance
> >> oriented devices, it is all about cost and hence it is stuck with such
> >> low devices.
> >
> > The DVB API should be able to fit on both home and professional segment.
> 
> 
> I don't see any professional hardware drivers being written for the
> Linux DVB API.

>From the feedbacks we're getting during the media mini-summits, 
there are vendors that seem to be working on it. Anyway, what I'm saying
is that the API should not be bound to any specific market segment.

If drivers will be submitted upstream for professional hardware or not
is a separate issue.

...
> >
> > Anyway, the existing API will be kept. Userspace may opt to use the legacy
> > API if they're not interested on a scaled value.
> 
> 
> That is simply stating, that whatever other people like it or not, you
> will whack
> nonsense in.

No. I'm simply stating that removing the existing API is not an option.

Also, plese stop with fallacy: it is not me saying that the existing API
is broken. I'm just the poor guy that is trying to fix the already known
issue. Several users, userspace developers and kernelspace developers
complain about the existing stats API. Even _you_ submitted a proposal
years ago for a new stats API to try solving those issues.

It is a common sense that the existing API is broken. If my proposal
requires adjustments, please comment on each specific patchset, instead
of filling this thread of destructive and useless complains.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:

>> If you have sufficient documentation, you can scale your demodulator statistics
>> to fit in that window area. I had done something similarly with a MB86A16
>> demodulator. IIRC, some effort was done on the STV0900 and STV0903
>> demodulator support as well to fit into that convention.
>>
>> All you need to do is scale the output of your demodulator to fit into
>> that window.
>
> To what scale? dB? linear? 0% to 100%?


It is in a db scale, scaled to the window, IIRC. In an application, you can
convert that window area, you can convert it into a linear scale as well.


>
> As there's no way to tell what's the used scale, if some scale is required,
> _all_ demods are required to be converted to that scale, otherwise, userspace
> can't rely on the scale.
>
> Are you capable of doing such change on _all demods? If not, please stop
> arguing that the existing API can be fixable.
>
> Besides that, changing the existing stats to whatever scale breaks
> userspace compatibility.
>
> BREAKING USERSPACE IS A BIG NO.
>

Consider this simple situation:
Your new API is using get_frontend and is polling the hardware, Now an
existing application is also doing monitoring of the statistics. So, now all
the decision box calculations are screwed.
Now, WHO BROKE USERSPACE ?

The same situation will happen for any new API that's going to be built.

Scaling the output values of a demodulator, which doesn't behave in
accordance to the specifications is NOT BREAKING USERSPACE.


>> What you are stating are just excuses, that do not exist.
>>
>> The same issue will exist, even with a new API and newer drivers not complying
>> to that API. I don't understand, why you fail to accept that fact.
>
> Newer drivers that don't implement an API right (being the a new one or an
> existing one) need to be fixed before being merged.
>
> It is as simple as that.


Okay, so what happens when a device that doesn't fit into your QoS
API, or that the
outputs of it are broken because of your API ?
I don't think it is that simple.


>> >> What is eventually wanted is a 0-100% scale, a self rotating counter etc scaled
>> >> to a maxima minima, rather than adding in complexities. This already exists,
>> >> all it needs to do is add some more devices to be scaled to that convention.
>> >> And more importantly, one is not going to get that real professional
>> >> measurements
>> >>  from these *home segment* devices. One of the chipset manufacturers once told
>> >> me that the PC segment never was interested in any real world performance
>> >> oriented devices, it is all about cost and hence it is stuck with such
>> >> low devices.
>> >
>> > The DVB API should be able to fit on both home and professional segment.
>>
>>
>> I don't see any professional hardware drivers being written for the
>> Linux DVB API.
>
> From the feedbacks we're getting during the media mini-summits,
> there are vendors that seem to be working on it. Anyway, what I'm saying
> is that the API should not be bound to any specific market segment.
>
> If drivers will be submitted upstream for professional hardware or not
> is a separate issue.


You are the one who had been touting all along on many linux-media threads,
on linux-kernel threads and what not; that API changes should not be made
for hardware that is not submitted upstream. So, I don't buy your argument
at all. Why did you argue with nvidia people that they shouldn't use dma-buf,
unless their driver is upstream. The same should hold good for what you are
talking now as well.



>> >
>> > Anyway, the existing API will be kept. Userspace may opt to use the legacy
>> > API if they're not interested on a scaled value.
>>
>>
>> That is simply stating, that whatever other people like it or not, you
>> will whack
>> nonsense in.
>
> No. I'm simply stating that removing the existing API is not an option.
>
> Also, plese stop with fallacy: it is not me saying that the existing API
> is broken. I'm just the poor guy that is trying to fix the already known
> issue. Several users, userspace developers and kernelspace developers
> complain about the existing stats API. Even _you_ submitted a proposal
> years ago for a new stats API to try solving those issues.


I submitted a proposal to distinguish between the various statistics modes
used by different devices. But eventually it was found that it wasn't possible
to fit *all* devices that do exist into any convention. That was why I didn't
pursue that proposal further.

>From what I learned from that, such information provided should be the
simplest possible thing, if we were to generalize on a large set of devices.
When being generalized with a large set of devices, however clever you are
or whatever technical might you have, you will still have issues with some
devices or the other. The end thoughts gathered from many people was that
such a generalization is futile, unless it is made for a very specific usecase.
A home user targeted API gets too complex and unusable in such an
 approach, making it harder for everyone altogether. As some other
people (I guess Klaus did) said, even an idiot should be able to make out
what it is, rather than trying to figure out what is what.

In any case, a true atomic operation cannot be made, for the same reasons
associated with consumer equipment based, or the so called Home segment
as described earlier. In such a case, it makes no difference if the existing
statistics related calls are made in a serialized way (driver also has to
serialize anyway). Other than that serialization, most demods have
restrictions that some operations it won't do simultaneously. So it doesn't
make any difference in real life. By having such a bloated API, you can just
more jeer that you are the author of that bloatware and nothing more than
that.


>
> It is a common sense that the existing API is broken. If my proposal
> requires adjustments, please comment on each specific patchset, instead
> of filling this thread of destructive and useless complains.


No, the concept of such a generalization is broken, as each new device will
be different and trying to make more generalization is a waste of developer
time and effort. The simplest approach would be to do a coarse approach,
which is not a perfect world, but it will do some good results for all the
people who use Linux-DVB. Still, repeating myself we are not dealing with
high end professional devices. If we have such devices, then it makes sense
to start such a discussion. Anyway professional devices will need a lot of
other API extensions, so your arguments on the need for professional
devices that do not exist are pointless and not agreeable to.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 16 Jan 2013 23:56:48 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> Consider this simple situation:
> Your new API is using get_frontend and is polling the hardware, Now an
> existing application is also doing monitoring of the statistics. So, now all
> the decision box calculations are screwed.

-EREADTHEFUCKINGPATCHES

Patch 04/15:

...
+static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
+						    u16 *strength)
+{
+	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 
+
+	*strength = c->strength.stat[0].uvalue;
+
+	return 0;
 }
...

The returned value there is in the same range as before.

Enough. If you don't read the patches, you're just making everybody
loosing their time with your biased and incorrect comments.

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Simon Farnsworth]

On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
> On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
<snip>
> >
> > It is a common sense that the existing API is broken. If my proposal
> > requires adjustments, please comment on each specific patchset, instead
> > of filling this thread of destructive and useless complains.
> 
> 
> No, the concept of such a generalization is broken, as each new device will
> be different and trying to make more generalization is a waste of developer
> time and effort. The simplest approach would be to do a coarse approach,
> which is not a perfect world, but it will do some good results for all the
> people who use Linux-DVB. Still, repeating myself we are not dealing with
> high end professional devices. If we have such devices, then it makes sense
> to start such a discussion. Anyway professional devices will need a lot of
> other API extensions, so your arguments on the need for professional
> devices that do not exist are pointless and not agreeable to.
> 
Let's step back a bit. As a sophisticated API user, I want to be able to give
my end-users the following information:

 * Signal strength in dBm
 * Signal quality as "poor", "OK" and "good".
 * Ideally, "increase signal strength to improve things" or "attenuate signal
to improve things"

In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
that they will see glitches in the output; a user seeing "OK" knows that
there's no glitching right now, but that the setup is marginal and may
struggle if anything changes, and a user seeing "good" knows that they've got
high quality signal.

VDR wants even simpler - it just wants strength and quality on a 0 to 100
scale, where 100 is perfect, and 0 is nothing present.

In both cases, we want per-layer quality for ISDB-T, for the reasons you've
already outlined.

So, how do you provide such information? Is it enough to simply provide
strength in dBm, and quality as 0 to 100, where anything under 33 indicates
uncorrected errors, and anything under 66 indicates that quality is marginal?
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 12:59 AM, Simon Farnsworth
<simon.farnsworth@onelan.com> wrote:
> On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
>> On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
> <snip>
>> >
>> > It is a common sense that the existing API is broken. If my proposal
>> > requires adjustments, please comment on each specific patchset, instead
>> > of filling this thread of destructive and useless complains.
>>
>>
>> No, the concept of such a generalization is broken, as each new device will
>> be different and trying to make more generalization is a waste of developer
>> time and effort. The simplest approach would be to do a coarse approach,
>> which is not a perfect world, but it will do some good results for all the
>> people who use Linux-DVB. Still, repeating myself we are not dealing with
>> high end professional devices. If we have such devices, then it makes sense
>> to start such a discussion. Anyway professional devices will need a lot of
>> other API extensions, so your arguments on the need for professional
>> devices that do not exist are pointless and not agreeable to.
>>
> Let's step back a bit. As a sophisticated API user, I want to be able to give
> my end-users the following information:
>
>  * Signal strength in dBm
>  * Signal quality as "poor", "OK" and "good".
>  * Ideally, "increase signal strength to improve things" or "attenuate signal
> to improve things"
>
> In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
> and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
> that they will see glitches in the output; a user seeing "OK" knows that
> there's no glitching right now, but that the setup is marginal and may
> struggle if anything changes, and a user seeing "good" knows that they've got
> high quality signal.
>
> VDR wants even simpler - it just wants strength and quality on a 0 to 100
> scale, where 100 is perfect, and 0 is nothing present.
>
> In both cases, we want per-layer quality for ISDB-T, for the reasons you've
> already outlined.
>
> So, how do you provide such information? Is it enough to simply provide
> strength in dBm, and quality as 0 to 100, where anything under 33 indicates
> uncorrected errors, and anything under 66 indicates that quality is marginal?

With DVB v3 the stats are interpreted thus:

http://linuxtv.org/downloads/legacy/old/linux_dvb_api-20020304.pdf

But, I am also not a big fan of that, but nevertheless it would have worked if
the drivers complied to that specification. The important thing that we learn
from history is that with a multitude of devices with different topologies and
methodologies, it is too hard to achieve a rigid structure.

Given the following statistical information available:

status 0x1f --- The demodulator status bits. 0x1f means all bits set,
everything ok.

signal [0x0000...0xffff] --- Signal Strength.
snr [0x0000...0xffff] --- Signal/Noise Ratio.

ber [0...0xffffffff] --- Bit Error Rate. The less the better.
unc [0...0xffffffff] --- Number of Uncorrectable Blocks. Small numbers
are preferable.


With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though
the rate difference could be very little.

For one layer, you could map the details as is, into the existing convention,
while the other 2 could be retrieved querying the details for each of
the layers.
This will keep it simple, to avoid calculating values to try to make a
global value.
Care should be taken, as to not change the current behaviour.
That way, all applications will be happy and still be working as is,
while you will
get detailed information on a per-layer basis.

Now, to achieve a common standard, the values need to be fit into the window,
what most drivers are trying to do. In most cases, it could be
difficult to convert
from one format to another one in it's current form, without causing
real breakage
to existing drivers. That said for each of the drivers, it couldn't be
difficult to
convert to a relative scale say something like a 0-100% scale, without dBuV,
or mV or dB/10, or dB/100. There can be a zillion reason why a demodulator
is using a scale in it's driver. It might not be easy or make sense to
change those
values to a newer scale. But it wouldn't be that hard to scale those
to a relative scale.
In fact many or quite a lot of drivers while providing the information
in some specific
form are also in that relative form.

Does everyone working on the DVB drivers posses a spectrum analyzer to do
calibration to dBwhatever ? At my side, I have had access to one some
time back,
but not anymore.

As Klaus said, any idiot will understand the relative scale clearly,
without much
after thought. This will also help that all the developers need to see are the
maxima / minima, which could be easy.

This is userspace requesting to make things simpler, not to make it even more
worser.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 12:52 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Wed, 16 Jan 2013 23:56:48 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> Consider this simple situation:
>> Your new API is using get_frontend and is polling the hardware, Now an
>> existing application is also doing monitoring of the statistics. So, now all
>> the decision box calculations are screwed.
>
> -EREADTHEFUCKINGPATCHES
>
> Patch 04/15:
>
> ...
> +static int mb86a20s_read_signal_strength_from_cache(struct dvb_frontend *fe,
> +                                                   u16 *strength)
> +{
> +       struct dtv_frontend_properties *c = &fe->dtv_property_cache;
>
> +
> +       *strength = c->strength.stat[0].uvalue;
> +
> +       return 0;
>  }
> ...
>
> The returned value there is in the same range as before.
>
> Enough. If you don't read the patches, you're just making everybody
> loosing their time with your biased and incorrect comments.

-EFUCKEDUPMORON

The behaviour of the ioctls did change completely.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 16 Jan 2013 19:29:28 +0000
Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:

> On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
> > On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
> <snip>
> > >
> > > It is a common sense that the existing API is broken. If my proposal
> > > requires adjustments, please comment on each specific patchset, instead
> > > of filling this thread of destructive and useless complains.
> > 
> > 
> > No, the concept of such a generalization is broken, as each new device will
> > be different and trying to make more generalization is a waste of developer
> > time and effort. The simplest approach would be to do a coarse approach,
> > which is not a perfect world, but it will do some good results for all the
> > people who use Linux-DVB. Still, repeating myself we are not dealing with
> > high end professional devices. If we have such devices, then it makes sense
> > to start such a discussion. Anyway professional devices will need a lot of
> > other API extensions, so your arguments on the need for professional
> > devices that do not exist are pointless and not agreeable to.
> > 
> Let's step back a bit. As a sophisticated API user, I want to be able to give
> my end-users the following information:
> 
>  * Signal strength in dBm
>  * Signal quality as "poor", "OK" and "good".
>  * Ideally, "increase signal strength to improve things" or "attenuate signal
> to improve things"
> 
> In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
> and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
> that they will see glitches in the output; a user seeing "OK" knows that
> there's no glitching right now, but that the setup is marginal and may
> struggle if anything changes, and a user seeing "good" knows that they've got
> high quality signal. 
> 
> VDR wants even simpler - it just wants strength and quality on a 0 to 100
> scale, where 100 is perfect, and 0 is nothing present.
> 
> In both cases, we want per-layer quality for ISDB-T, for the reasons you've
> already outlined.
> 
> So, how do you provide such information? Is it enough to simply provide
> strength in dBm, and quality as 0 to 100, where anything under 33 indicates
> uncorrected errors, and anything under 66 indicates that quality is marginal?

Unfortunately, not all devices can provide strength in dBm. 

On this RFC proposal, the driver will report if the device is providing
it either in dBm or on a 0% to 100% scale.

UNC, BER and S/N ratio (actually, C/N) measures are provided. Again, S/N
can either be in dB or on a 0% to 100% scale.

A high S/N ratio means low UNC/BER counts, so S/N is probably what VDR would
use for a quality indicator.

Assuming that is_isdb is true for ISDB, and that pid_layer is equal
to the ISDB layer for a given program (determined elsewhere in the
code), In order to get the QoS properties, I would code it like the 
following (untested) code:

...
       if (parms->version >= 0x510) {
               struct dtv_property dvb_prop[6];
               struct dtv_properties props;
               int j, layer;

               dvb_prop[0].cmd = DTV_QOS_SIGNAL_STRENGTH;
               dvb_prop[1].cmd = DTV_QOS_CNR;
               dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
               dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
               dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
               dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;

               props.num = 6;
               props.props = dvb_prop;

		if (is_isdb)
			layer = pid_layer;
		else
			layer = 0;

               /* Do a DVBv5.10 stats call */
               if (ioctl(parms->fd, FE_GET_PROPERTY, &props) == 0)
			display_statistics(dvb_prop, layer);
       } else
		/* DVBv3 fallback */
...

Where a display_statistics() that just shows every available measure
would be:

void display_statistics(struct dtv_property dvb_prop[6], unsigned layer)
{
	printf("Signal strength: ");
	if (dvb_prop[0].u.st.len && dvb_prop[0].u.st.stat[0].scale == FE_SCALE_DECIBEL)
		printf("%d dBm\n", (int)dvb_prop[0].u.st.stat[0].svalue);
	else if (dvb_prop[0].u.st.len && dvb_prop[0].u.st.stat[0].scale == FE_SCALE_DECIBEL)
		printf("%03.2f %\n", 100.*dvb_prop[0].u.st.stat[0].uvalue / 65535);
	} else {
		printf("not available\n");
	}

	printf("Carrier to Noise ratio: ");
	if (dvb_prop[1].u.st.len > layer && dvb_prop[1].u.st.stat[layer].scale == FE_SCALE_DECIBEL)
		printf("%d dB\n", (int)dvb_prop[1].u.st.stat[layer].svalue);
	else if (dvb_prop[1].u.st.len > layer&& dvb_prop[1].u.st.stat[layer].scale == FE_SCALE_DECIBEL)
		printf("%03.2f %\n", 100.*dvb_prop[1].u.st.stat[layer].uvalue / 65535);
	} else {
		printf("not available\n");
	}

	if (dvb_prop[2].u.st.len > layer && dvb_prop[2].u.st.stat[layer].scale == FE_SCALE_COUNTER &&
	    dvb_prop[3].u.st.len > layer && dvb_prop[3].u.st.stat[layer].scale == FE_SCALE_COUNTER) {
		float ber = ((float)dvb_prop[2].u.st.stat[layer].uvalue) / dvb_prop[3].u.st.stat[layer].uvalue;
		printf("BER = %e\n", ber);
	}

	if (dvb_prop[4].u.st.len > layer && dvb_prop[4].u.st.stat[layer].scale == FE_SCALE_COUNTER) {
		printf("UCB = %lld\n", dvb_prop[4].u.st.stat[layer].uvalue);
	}

	if (dvb_prop[4].u.st.len > layer && dvb_prop[4].u.st.stat[layer].scale == FE_SCALE_COUNTER &&
	    dvb_prop[5].u.st.len > layer && dvb_prop[5].u.st.stat[layer].scale == FE_SCALE_COUNTER) {
		float per = ((float)dvb_prop[4].u.st.stat[layer].uvalue) / dvb_prop[5].u.st.stat[layer].uvalue;
		printf("PER = %e\n", per);
	}
}

-

Btw, I just finished the implementation of S/N on mb86a20s:
	http://git.linuxtv.org/mchehab/experimental.git/commit/3640dcff0a6028dbf461f7f1e7b4ea0514eab20e

The only stats left on my TODO list on mb86a20s is UCB/PER measurement, as
I probably won't implement BER after Viterbi there.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 03:07:21 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though
> the rate difference could be very little.

Where? There's no way to report per-layer report with DVBv3.

And no, the difference is not very little:

$ dmesg|grep -e mb86a20s_get_main_CNR -e "bit error before" -e "bit count before"

[12785.798746] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 252.
[12785.810743] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12785.856385] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12786.399684] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12786.410678] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 248.
[12786.422693] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12786.425547] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 80209.
[12786.437537] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536.
[12786.919289] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12786.930410] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 213.
[12786.942553] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12786.989127] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12787.387172] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12787.398062] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 234.
[12787.409657] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12787.412529] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 83533.
[12787.424293] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536.
[12788.052702] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12788.063443] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 183.
[12788.075438] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12788.078165] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 91502.
[12788.089946] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536.
[12788.126411] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12788.388646] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12788.399268] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 181.
[12788.410887] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12789.189254] i2c i2c-4: mb86a20s_get_main_CNR: CNR is 24.4 dB (1285)
[12789.200099] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer A: 191.
[12789.211719] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer A: 65535.
[12789.214465] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit error before Viterbi for layer B: 83536.
[12789.226348] i2c i2c-4: mb86a20s_get_ber_before_vterbi: bit count before Viterbi for layer B: 8257536.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 3:41 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Thu, 17 Jan 2013 03:07:21 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> With ISDB-T, with the 3 layers, you have BER/UNC for each of the layers, though
>> the rate difference could be very little.
>
> Where? There's no way to report per-layer report with DVBv3.


To retrieve on a per layer basis, you will need exactly one control for that.
Nothing more. You don't need such an intrusive patch.


>
> And no, the difference is not very little:
>
> $ dmesg|grep -e mb86a20s_get_main_CNR -e "bit error before" -e "bit count before"


Maybe the difference is small or big. Honestly, I have little trust in
code output by you,
after all the antics in recent threads.


Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em Wed, 16 Jan 2013 19:29:28 +0000
> Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:
>
>> On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
>> > On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
>> <snip>
>> > >
>> > > It is a common sense that the existing API is broken. If my proposal
>> > > requires adjustments, please comment on each specific patchset, instead
>> > > of filling this thread of destructive and useless complains.
>> >
>> >
>> > No, the concept of such a generalization is broken, as each new device will
>> > be different and trying to make more generalization is a waste of developer
>> > time and effort. The simplest approach would be to do a coarse approach,
>> > which is not a perfect world, but it will do some good results for all the
>> > people who use Linux-DVB. Still, repeating myself we are not dealing with
>> > high end professional devices. If we have such devices, then it makes sense
>> > to start such a discussion. Anyway professional devices will need a lot of
>> > other API extensions, so your arguments on the need for professional
>> > devices that do not exist are pointless and not agreeable to.
>> >
>> Let's step back a bit. As a sophisticated API user, I want to be able to give
>> my end-users the following information:
>>
>>  * Signal strength in dBm
>>  * Signal quality as "poor", "OK" and "good".
>>  * Ideally, "increase signal strength to improve things" or "attenuate signal
>> to improve things"
>>
>> In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
>> and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
>> that they will see glitches in the output; a user seeing "OK" knows that
>> there's no glitching right now, but that the setup is marginal and may
>> struggle if anything changes, and a user seeing "good" knows that they've got
>> high quality signal.
>>
>> VDR wants even simpler - it just wants strength and quality on a 0 to 100
>> scale, where 100 is perfect, and 0 is nothing present.
>>
>> In both cases, we want per-layer quality for ISDB-T, for the reasons you've
>> already outlined.
>>
>> So, how do you provide such information? Is it enough to simply provide
>> strength in dBm, and quality as 0 to 100, where anything under 33 indicates
>> uncorrected errors, and anything under 66 indicates that quality is marginal?
>
> Unfortunately, not all devices can provide strength in dBm.

MB86A20 is not the only demodulator driver with the Linux DVB.
And not all devices can output in dB scale proposed by you, But any device
output can be scaled in a relative way. So I don't see any reason why
userspace has to deal with cumbersome controls to deal with redundant
statistics, which is nonsense.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 05:40 AM, Manu Abraham wrote:
> On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em Wed, 16 Jan 2013 19:29:28 +0000
>> Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:
>>
>>> On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
>>>> On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
>>> <snip>
>>>>>
>>>>> It is a common sense that the existing API is broken. If my proposal
>>>>> requires adjustments, please comment on each specific patchset, instead
>>>>> of filling this thread of destructive and useless complains.
>>>>
>>>>
>>>> No, the concept of such a generalization is broken, as each new device will
>>>> be different and trying to make more generalization is a waste of developer
>>>> time and effort. The simplest approach would be to do a coarse approach,
>>>> which is not a perfect world, but it will do some good results for all the
>>>> people who use Linux-DVB. Still, repeating myself we are not dealing with
>>>> high end professional devices. If we have such devices, then it makes sense
>>>> to start such a discussion. Anyway professional devices will need a lot of
>>>> other API extensions, so your arguments on the need for professional
>>>> devices that do not exist are pointless and not agreeable to.
>>>>
>>> Let's step back a bit. As a sophisticated API user, I want to be able to give
>>> my end-users the following information:
>>>
>>>   * Signal strength in dBm
>>>   * Signal quality as "poor", "OK" and "good".
>>>   * Ideally, "increase signal strength to improve things" or "attenuate signal
>>> to improve things"
>>>
>>> In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER != 0,
>>> and "good" is UNC == BER == 0. The idea is that a user seeing "poor" knows
>>> that they will see glitches in the output; a user seeing "OK" knows that
>>> there's no glitching right now, but that the setup is marginal and may
>>> struggle if anything changes, and a user seeing "good" knows that they've got
>>> high quality signal.
>>>
>>> VDR wants even simpler - it just wants strength and quality on a 0 to 100
>>> scale, where 100 is perfect, and 0 is nothing present.
>>>
>>> In both cases, we want per-layer quality for ISDB-T, for the reasons you've
>>> already outlined.
>>>
>>> So, how do you provide such information? Is it enough to simply provide
>>> strength in dBm, and quality as 0 to 100, where anything under 33 indicates
>>> uncorrected errors, and anything under 66 indicates that quality is marginal?
>>
>> Unfortunately, not all devices can provide strength in dBm.
>
> MB86A20 is not the only demodulator driver with the Linux DVB.
> And not all devices can output in dB scale proposed by you, But any device
> output can be scaled in a relative way. So I don't see any reason why
> userspace has to deal with cumbersome controls to deal with redundant
> statistics, which is nonsense.

What goes to these units in general, dB conversion is done by the driver 
about always. It is quite hard or even impossible to find out that 
formula unless you has adjustable test signal generator.

Also we could not offer always dBm as signal strength. This comes to 
fact that only recent silicon RF-tuners are able to provide RF strength. 
More traditionally that estimation is done by demod from IF/RF AGC, 
which leads very, very, rough estimation.

So at least for the signal strength it is impossible to require dBm. dB 
for SNR is possible, but it is very hard due to lack of developers 
knowledge and test equipment. SNR could be still forced to look like it 
is in given dB scale. I think it is not big loss even though SNR values 
reported are a little bit wrong.


About half year ago I looked how SNR was measured every demod we has:

http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt

as we can see there is currently only two style used:
1) 0.1 dB (very common in new drivers)
2) unknown (== mostly just raw register values)


regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 11:33:46 +0200
Antti Palosaari <crope@iki.fi> escreveu:
 
> What goes to these units in general, dB conversion is done by the driver 
> about always. It is quite hard or even impossible to find out that 
> formula unless you has adjustable test signal generator.
> 
> Also we could not offer always dBm as signal strength. This comes to 
> fact that only recent silicon RF-tuners are able to provide RF strength. 
> More traditionally that estimation is done by demod from IF/RF AGC, 
> which leads very, very, rough estimation.
>
> So at least for the signal strength it is impossible to require dBm. dB 
> for SNR is possible, but it is very hard due to lack of developers 
> knowledge and test equipment. SNR could be still forced to look like it 
> is in given dB scale. I think it is not big loss even though SNR values 
> reported are a little bit wrong.
> 
> 
> About half year ago I looked how SNR was measured every demod we has:
> 
> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
> 
> as we can see there is currently only two style used:
> 1) 0.1 dB (very common in new drivers)
> 2) unknown (== mostly just raw register values)

It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
they can't converted into any of the supported scales.

Btw, as agreed, on v11:
	- dB scale changed to 0.001 dB (not sure if this will bring much
gain, as I doubt that demods have that much precision);
	- removed QoS nomenclature (I hope I didn't forget it left on
	  some patch);
	- removed DTV_QOS_ENUM;
	- counters reset logic is now driver-specific (currently, resetting
	  it at set_frontend callback on mb8620s);

I'll be posting the patches after finishing the tests.

What's left (probably we need more discussions):

a) a flag to indicate a counter reset (my suggestion). 

Does it make sense? If so, where should it be? At fe_status_t?

b) per-stats/per-dvb-property error indicator (Devin's suggestion).

I don't think it is needed for statistics. Yet, it may be interesting for
the other dvb properties.

So, IMHO, I would do add it like:

struct dtv_property {
        __u32 cmd;
	__s32 error;		/* Linux error code when set/get this specific property */
        __u32 reserved[2];
        union {
                __u32 data;
                struct dtv_fe_stats st;
                struct {
                        __u8 data[32];
                        __u32 len;
                        __u32 reserved1[3];
                        void *reserved2;
               	} buffer;
        } u;
        int result;
} __attribute__ ((packed));

A patch adding this for statistics should be easy, as there's just one
driver currently implementing it. Making the core and drivers handle 
per-property errors can be trickier and will require more work.

But I'm still in doubt if it does make sense for stats. 

Devin?

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Jan 2013 11:33:46 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> What goes to these units in general, dB conversion is done by the driver
>> about always. It is quite hard or even impossible to find out that
>> formula unless you has adjustable test signal generator.
>>
>> Also we could not offer always dBm as signal strength. This comes to
>> fact that only recent silicon RF-tuners are able to provide RF strength.
>> More traditionally that estimation is done by demod from IF/RF AGC,
>> which leads very, very, rough estimation.
>>
>> So at least for the signal strength it is impossible to require dBm. dB
>> for SNR is possible, but it is very hard due to lack of developers
>> knowledge and test equipment. SNR could be still forced to look like it
>> is in given dB scale. I think it is not big loss even though SNR values
>> reported are a little bit wrong.
>>
>>
>> About half year ago I looked how SNR was measured every demod we has:
>>
>> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
>>
>> as we can see there is currently only two style used:
>> 1) 0.1 dB (very common in new drivers)
>> 2) unknown (== mostly just raw register values)
>
> It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
> they can't converted into any of the supported scales.
>
> Btw, as agreed, on v11:
> 	- dB scale changed to 0.001 dB (not sure if this will bring much
> gain, as I doubt that demods have that much precision);
> 	- removed QoS nomenclature (I hope I didn't forget it left on
> 	  some patch);
> 	- removed DTV_QOS_ENUM;
> 	- counters reset logic is now driver-specific (currently, resetting
> 	  it at set_frontend callback on mb8620s);
>
> I'll be posting the patches after finishing the tests.
>
> What's left (probably we need more discussions):
>
> a) a flag to indicate a counter reset (my suggestion).
>
> Does it make sense? If so, where should it be? At fe_status_t?
>
> b) per-stats/per-dvb-property error indicator (Devin's suggestion).
>
> I don't think it is needed for statistics. Yet, it may be interesting for
> the other dvb properties.
>
> So, IMHO, I would do add it like:
>
> struct dtv_property {
>          __u32 cmd;
> 	__s32 error;		/* Linux error code when set/get this specific property */
>          __u32 reserved[2];
>          union {
>                  __u32 data;
>                  struct dtv_fe_stats st;
>                  struct {
>                          __u8 data[32];
>                          __u32 len;
>                          __u32 reserved1[3];
>                          void *reserved2;
>                 	} buffer;
>          } u;
>          int result;
> } __attribute__ ((packed));
>
> A patch adding this for statistics should be easy, as there's just one
> driver currently implementing it. Making the core and drivers handle
> per-property errors can be trickier and will require more work.
>
> But I'm still in doubt if it does make sense for stats.
>
> Devin?
>
> Cheers,
> Mauro
>

There is one issue what I now still think.

dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;

For me this looks like uncorrected errors are reported as a rate too (as 
both error count and total count are reported to app). But that is not 
suitable for reporting uncorrected blocks! It fits fine for BER, but not 
UCB. If UCB counter is running that fast then picture is totally broken. 
Behavior of UCB should remain quite same as it is currently, increases 
slowly over the time. If you start resetting counters as for BER then 
UCB is almost all the time 0. User wants to know UCB errors in frame of 
days rather than minutes.


regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
> On 01/17/2013 05:40 AM, Manu Abraham wrote:
>>
>> On Thu, Jan 17, 2013 at 3:31 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>>
>>> Em Wed, 16 Jan 2013 19:29:28 +0000
>>> Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:
>>>
>>>> On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote:
>>>>>
>>>>> On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab
>>>>
>>>> <snip>
>>>>>>
>>>>>>
>>>>>> It is a common sense that the existing API is broken. If my proposal
>>>>>> requires adjustments, please comment on each specific patchset,
>>>>>> instead
>>>>>> of filling this thread of destructive and useless complains.
>>>>>
>>>>>
>>>>>
>>>>> No, the concept of such a generalization is broken, as each new device
>>>>> will
>>>>> be different and trying to make more generalization is a waste of
>>>>> developer
>>>>> time and effort. The simplest approach would be to do a coarse
>>>>> approach,
>>>>> which is not a perfect world, but it will do some good results for all
>>>>> the
>>>>> people who use Linux-DVB. Still, repeating myself we are not dealing
>>>>> with
>>>>> high end professional devices. If we have such devices, then it makes
>>>>> sense
>>>>> to start such a discussion. Anyway professional devices will need a lot
>>>>> of
>>>>> other API extensions, so your arguments on the need for professional
>>>>> devices that do not exist are pointless and not agreeable to.
>>>>>
>>>> Let's step back a bit. As a sophisticated API user, I want to be able to
>>>> give
>>>> my end-users the following information:
>>>>
>>>>   * Signal strength in dBm
>>>>   * Signal quality as "poor", "OK" and "good".
>>>>   * Ideally, "increase signal strength to improve things" or "attenuate
>>>> signal
>>>> to improve things"
>>>>
>>>> In a DVBv3 world, "poor" equates to UNC != 0, "OK" is UNC == 0, BER !=
>>>> 0,
>>>> and "good" is UNC == BER == 0. The idea is that a user seeing "poor"
>>>> knows
>>>> that they will see glitches in the output; a user seeing "OK" knows that
>>>> there's no glitching right now, but that the setup is marginal and may
>>>> struggle if anything changes, and a user seeing "good" knows that
>>>> they've got
>>>> high quality signal.
>>>>
>>>> VDR wants even simpler - it just wants strength and quality on a 0 to
>>>> 100
>>>> scale, where 100 is perfect, and 0 is nothing present.
>>>>
>>>> In both cases, we want per-layer quality for ISDB-T, for the reasons
>>>> you've
>>>> already outlined.
>>>>
>>>> So, how do you provide such information? Is it enough to simply provide
>>>> strength in dBm, and quality as 0 to 100, where anything under 33
>>>> indicates
>>>> uncorrected errors, and anything under 66 indicates that quality is
>>>> marginal?
>>>
>>>
>>> Unfortunately, not all devices can provide strength in dBm.
>>
>>
>> MB86A20 is not the only demodulator driver with the Linux DVB.
>> And not all devices can output in dB scale proposed by you, But any device
>> output can be scaled in a relative way. So I don't see any reason why
>> userspace has to deal with cumbersome controls to deal with redundant
>> statistics, which is nonsense.
>
>
> What goes to these units in general, dB conversion is done by the driver
> about always. It is quite hard or even impossible to find out that formula
> unless you has adjustable test signal generator.
>
> Also we could not offer always dBm as signal strength. This comes to fact
> that only recent silicon RF-tuners are able to provide RF strength. More
> traditionally that estimation is done by demod from IF/RF AGC, which leads
> very, very, rough estimation.

What I am saying is that, rather than sticking to a dB scale, it would be
better to fit it into a relative scale, ie loose dB altogether and use only the
relative scale. With that approach any device can be fit into that convention.
Even with an unknown device, it makes it pretty easy for anyone to fit
into that
scale. All you need is a few trial runs to get maxima/minima. When there
exists only a single convention that is simple, it makes it more easier for
people to stick to that convention, rather than for people to not support it.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 07:16 PM, Manu Abraham wrote:
> On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
>> On 01/17/2013 05:40 AM, Manu Abraham wrote:
>>> MB86A20 is not the only demodulator driver with the Linux DVB.
>>> And not all devices can output in dB scale proposed by you, But any device
>>> output can be scaled in a relative way. So I don't see any reason why
>>> userspace has to deal with cumbersome controls to deal with redundant
>>> statistics, which is nonsense.
>>
>>
>> What goes to these units in general, dB conversion is done by the driver
>> about always. It is quite hard or even impossible to find out that formula
>> unless you has adjustable test signal generator.
>>
>> Also we could not offer always dBm as signal strength. This comes to fact
>> that only recent silicon RF-tuners are able to provide RF strength. More
>> traditionally that estimation is done by demod from IF/RF AGC, which leads
>> very, very, rough estimation.
>
> What I am saying is that, rather than sticking to a dB scale, it would be
> better to fit it into a relative scale, ie loose dB altogether and use only the
> relative scale. With that approach any device can be fit into that convention.
> Even with an unknown device, it makes it pretty easy for anyone to fit
> into that
> scale. All you need is a few trial runs to get maxima/minima. When there
> exists only a single convention that is simple, it makes it more easier for
> people to stick to that convention, rather than for people to not support it.

That is true. I don't have really clear opinion whether to force all to 
one scale, or return dBm those which could and that dummy scale for the 
others. Maybe I will still vote for both relative and dBm.

Shortly there is two possibilities:
1) support only relative scale
2) support both dBm and relative scale (with dBm priority)

[3) support only dBm is not possible]

regards
Antti

-- 
http://palosaari.fi/

Re: [linux-media] Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Klaus Schmidinger]

On 17.01.2013 18:22, Antti Palosaari wrote:
> On 01/17/2013 07:16 PM, Manu Abraham wrote:
>> On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
>>> On 01/17/2013 05:40 AM, Manu Abraham wrote:
>>>> MB86A20 is not the only demodulator driver with the Linux DVB.
>>>> And not all devices can output in dB scale proposed by you, But any device
>>>> output can be scaled in a relative way. So I don't see any reason why
>>>> userspace has to deal with cumbersome controls to deal with redundant
>>>> statistics, which is nonsense.
>>>
>>>
>>> What goes to these units in general, dB conversion is done by the driver
>>> about always. It is quite hard or even impossible to find out that formula
>>> unless you has adjustable test signal generator.
>>>
>>> Also we could not offer always dBm as signal strength. This comes to fact
>>> that only recent silicon RF-tuners are able to provide RF strength. More
>>> traditionally that estimation is done by demod from IF/RF AGC, which leads
>>> very, very, rough estimation.
>>
>> What I am saying is that, rather than sticking to a dB scale, it would be
>> better to fit it into a relative scale, ie loose dB altogether and use only the
>> relative scale. With that approach any device can be fit into that convention.
>> Even with an unknown device, it makes it pretty easy for anyone to fit
>> into that
>> scale. All you need is a few trial runs to get maxima/minima. When there
>> exists only a single convention that is simple, it makes it more easier for
>> people to stick to that convention, rather than for people to not support it.
>
> That is true. I don't have really clear opinion whether to force all to one scale, or return dBm those which could and that dummy scale for the others. Maybe I will still vote for both relative and dBm.
>
> Shortly there is two possibilities:
> 1) support only relative scale
> 2) support both dBm and relative scale (with dBm priority)
>
> [3) support only dBm is not possible]

4) support relative scale (mandatory!) and dBm (if applicable).

I concur with Antti. Any device's values can be made to fit into
a 0..100 (or whatever) range, so *that* should be the primary (and
mandatory) value. If the device can do so, it can also provide a dB*
value (replace * with anything you like, 'm', 'uV', 'uW', whatever)
and maybe all other sorts of bells and whistles.
So real world applications could simply and savely use the relative
value (which is all they need), and special applications could fiddle
around with dB values (provided the device in use can deliver them).

@Mauro: here's some further reading for you, just in case ;-)

   http://en.wikipedia.org/wiki/KISS_principle
   http://www.inspireux.com/2008/07/14/a-designer-achieves-perfection-when-there-is-nothing-left-to-take-away

Klaus

Re: [linux-media] Re: [linux-media] Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Klaus Schmidinger]

On 17.01.2013 18:37, Klaus Schmidinger wrote:
> On 17.01.2013 18:22, Antti Palosaari wrote:
>> On 01/17/2013 07:16 PM, Manu Abraham wrote:
>>> On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>> On 01/17/2013 05:40 AM, Manu Abraham wrote:
>>>>> MB86A20 is not the only demodulator driver with the Linux DVB.
>>>>> And not all devices can output in dB scale proposed by you, But any device
>>>>> output can be scaled in a relative way. So I don't see any reason why
>>>>> userspace has to deal with cumbersome controls to deal with redundant
>>>>> statistics, which is nonsense.
>>>>
>>>>
>>>> What goes to these units in general, dB conversion is done by the driver
>>>> about always. It is quite hard or even impossible to find out that formula
>>>> unless you has adjustable test signal generator.
>>>>
>>>> Also we could not offer always dBm as signal strength. This comes to fact
>>>> that only recent silicon RF-tuners are able to provide RF strength. More
>>>> traditionally that estimation is done by demod from IF/RF AGC, which leads
>>>> very, very, rough estimation.
>>>
>>> What I am saying is that, rather than sticking to a dB scale, it would be
>>> better to fit it into a relative scale, ie loose dB altogether and use only the
>>> relative scale. With that approach any device can be fit into that convention.
>>> Even with an unknown device, it makes it pretty easy for anyone to fit
>>> into that
>>> scale. All you need is a few trial runs to get maxima/minima. When there
>>> exists only a single convention that is simple, it makes it more easier for
>>> people to stick to that convention, rather than for people to not support it.
>>
>> That is true. I don't have really clear opinion whether to force all to one scale, or return dBm those which could and that dummy scale for the others. Maybe I will still vote for both relative and dBm.
>>
>> Shortly there is two possibilities:
>> 1) support only relative scale
>> 2) support both dBm and relative scale (with dBm priority)
>>
>> [3) support only dBm is not possible]
>
> 4) support relative scale (mandatory!) and dBm (if applicable).
>
> I concur with Antti.

Sorry, that should have been "Manu" - got the wrong quote level...

>  Any device's values can be made to fit into
> a 0..100 (or whatever) range, so *that* should be the primary (and
> mandatory) value. If the device can do so, it can also provide a dB*
> value (replace * with anything you like, 'm', 'uV', 'uW', whatever)
> and maybe all other sorts of bells and whistles.
> So real world applications could simply and savely use the relative
> value (which is all they need), and special applications could fiddle
> around with dB values (provided the device in use can deliver them).
>
> @Mauro: here's some further reading for you, just in case ;-)
>
>    http://en.wikipedia.org/wiki/KISS_principle
>    http://www.inspireux.com/2008/07/14/a-designer-achieves-perfection-when-there-is-nothing-left-to-take-away
>
> Klaus

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 19:15:22 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 17 Jan 2013 11:33:46 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >> What goes to these units in general, dB conversion is done by the driver
> >> about always. It is quite hard or even impossible to find out that
> >> formula unless you has adjustable test signal generator.
> >>
> >> Also we could not offer always dBm as signal strength. This comes to
> >> fact that only recent silicon RF-tuners are able to provide RF strength.
> >> More traditionally that estimation is done by demod from IF/RF AGC,
> >> which leads very, very, rough estimation.
> >>
> >> So at least for the signal strength it is impossible to require dBm. dB
> >> for SNR is possible, but it is very hard due to lack of developers
> >> knowledge and test equipment. SNR could be still forced to look like it
> >> is in given dB scale. I think it is not big loss even though SNR values
> >> reported are a little bit wrong.
> >>
> >>
> >> About half year ago I looked how SNR was measured every demod we has:
> >>
> >> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
> >>
> >> as we can see there is currently only two style used:
> >> 1) 0.1 dB (very common in new drivers)
> >> 2) unknown (== mostly just raw register values)
> >
> > It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
> > they can't converted into any of the supported scales.
> >
> > Btw, as agreed, on v11:
> > 	- dB scale changed to 0.001 dB (not sure if this will bring much
> > gain, as I doubt that demods have that much precision);
> > 	- removed QoS nomenclature (I hope I didn't forget it left on
> > 	  some patch);
> > 	- removed DTV_QOS_ENUM;
> > 	- counters reset logic is now driver-specific (currently, resetting
> > 	  it at set_frontend callback on mb8620s);
> >
> > I'll be posting the patches after finishing the tests.
> >
> > What's left (probably we need more discussions):
> >
> > a) a flag to indicate a counter reset (my suggestion).
> >
> > Does it make sense? If so, where should it be? At fe_status_t?
> >
> > b) per-stats/per-dvb-property error indicator (Devin's suggestion).
> >
> > I don't think it is needed for statistics. Yet, it may be interesting for
> > the other dvb properties.
> >
> > So, IMHO, I would do add it like:
> >
> > struct dtv_property {
> >          __u32 cmd;
> > 	__s32 error;		/* Linux error code when set/get this specific property */
> >          __u32 reserved[2];
> >          union {
> >                  __u32 data;
> >                  struct dtv_fe_stats st;
> >                  struct {
> >                          __u8 data[32];
> >                          __u32 len;
> >                          __u32 reserved1[3];
> >                          void *reserved2;
> >                 	} buffer;
> >          } u;
> >          int result;
> > } __attribute__ ((packed));
> >
> > A patch adding this for statistics should be easy, as there's just one
> > driver currently implementing it. Making the core and drivers handle
> > per-property errors can be trickier and will require more work.
> >
> > But I'm still in doubt if it does make sense for stats.
> >
> > Devin?
> >
> > Cheers,
> > Mauro
> >
> 
> There is one issue what I now still think.
> 
> dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
> dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
> dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
> dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
> 
> For me this looks like uncorrected errors are reported as a rate too (as 
> both error count and total count are reported to app). But that is not 
> suitable for reporting uncorrected blocks! It fits fine for BER, but not 
> UCB. If UCB counter is running that fast then picture is totally broken. 

UCB is just DTV_QOS_ERROR_BLOCK_COUNT. 

PER is DTV_QOS_ERROR_BLOCK_COUNT / DTV_QOS_TOTAL_BLOCKS_COUNT

Not all frontends will of course provide PER.

> Behavior of UCB should remain quite same as it is currently, increases 
> slowly over the time. If you start resetting counters as for BER then 
> UCB is almost all the time 0. User wants to know UCB errors in frame of 
> days rather than minutes.

Hmm... good point.

Let's see when those counters would overflow with u64 (please correct
if I did any wrong calculus on bc).

We have:
	2^64 = 18,446,744,073,709,551,616

Assuming a bit rate of 54 Mbps, we have:
	bits_per_sec = (54*1024*1024*1024)
	bits_per_sec = 57,982,058,496

In this case, the bit error count will overflow in:
	time_to_overflow = 2^64 seconds / bits_per_sec =
			 = 18,446,744,073,709,551,616 / 57,982,058,496
		         = 318,145,725 seconds
So,
	time_to_overflow is more than 3682 days and more than 10 years

DTV_QOS_TOTAL_BLOCKS_COUNT increments slower than DTV_QOS_TOTAL_BITS_COUNT
(204 * 8 times slower).

So, it would take 318,145,725 * 204 * 8 seconds (or 6,009,419 days) to
overflow).

IMHO, except for professional applications that would be continuously
running for more than 10 years , there's no need to be
careful about overflows.

That said, I still think that the counters should be reset when
a new channel is tuned (e. g. when set_frontend is called from
userspace) or when the user requests for a counters reset, as the 
statistics from one channel/transponder are different than the ones
for other channels/transponders.

Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 08:11 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Jan 2013 19:15:22 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote:
>>> Em Thu, 17 Jan 2013 11:33:46 +0200
>>> Antti Palosaari <crope@iki.fi> escreveu:
>>>
>>>> What goes to these units in general, dB conversion is done by the driver
>>>> about always. It is quite hard or even impossible to find out that
>>>> formula unless you has adjustable test signal generator.
>>>>
>>>> Also we could not offer always dBm as signal strength. This comes to
>>>> fact that only recent silicon RF-tuners are able to provide RF strength.
>>>> More traditionally that estimation is done by demod from IF/RF AGC,
>>>> which leads very, very, rough estimation.
>>>>
>>>> So at least for the signal strength it is impossible to require dBm. dB
>>>> for SNR is possible, but it is very hard due to lack of developers
>>>> knowledge and test equipment. SNR could be still forced to look like it
>>>> is in given dB scale. I think it is not big loss even though SNR values
>>>> reported are a little bit wrong.
>>>>
>>>>
>>>> About half year ago I looked how SNR was measured every demod we has:
>>>>
>>>> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
>>>>
>>>> as we can see there is currently only two style used:
>>>> 1) 0.1 dB (very common in new drivers)
>>>> 2) unknown (== mostly just raw register values)
>>>
>>> It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
>>> they can't converted into any of the supported scales.
>>>
>>> Btw, as agreed, on v11:
>>> 	- dB scale changed to 0.001 dB (not sure if this will bring much
>>> gain, as I doubt that demods have that much precision);
>>> 	- removed QoS nomenclature (I hope I didn't forget it left on
>>> 	  some patch);
>>> 	- removed DTV_QOS_ENUM;
>>> 	- counters reset logic is now driver-specific (currently, resetting
>>> 	  it at set_frontend callback on mb8620s);
>>>
>>> I'll be posting the patches after finishing the tests.
>>>
>>> What's left (probably we need more discussions):
>>>
>>> a) a flag to indicate a counter reset (my suggestion).
>>>
>>> Does it make sense? If so, where should it be? At fe_status_t?
>>>
>>> b) per-stats/per-dvb-property error indicator (Devin's suggestion).
>>>
>>> I don't think it is needed for statistics. Yet, it may be interesting for
>>> the other dvb properties.
>>>
>>> So, IMHO, I would do add it like:
>>>
>>> struct dtv_property {
>>>           __u32 cmd;
>>> 	__s32 error;		/* Linux error code when set/get this specific property */
>>>           __u32 reserved[2];
>>>           union {
>>>                   __u32 data;
>>>                   struct dtv_fe_stats st;
>>>                   struct {
>>>                           __u8 data[32];
>>>                           __u32 len;
>>>                           __u32 reserved1[3];
>>>                           void *reserved2;
>>>                  	} buffer;
>>>           } u;
>>>           int result;
>>> } __attribute__ ((packed));
>>>
>>> A patch adding this for statistics should be easy, as there's just one
>>> driver currently implementing it. Making the core and drivers handle
>>> per-property errors can be trickier and will require more work.
>>>
>>> But I'm still in doubt if it does make sense for stats.
>>>
>>> Devin?
>>>
>>> Cheers,
>>> Mauro
>>>
>>
>> There is one issue what I now still think.
>>
>> dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
>> dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
>> dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
>> dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;
>>
>> For me this looks like uncorrected errors are reported as a rate too (as
>> both error count and total count are reported to app). But that is not
>> suitable for reporting uncorrected blocks! It fits fine for BER, but not
>> UCB. If UCB counter is running that fast then picture is totally broken.
>
> UCB is just DTV_QOS_ERROR_BLOCK_COUNT.
>
> PER is DTV_QOS_ERROR_BLOCK_COUNT / DTV_QOS_TOTAL_BLOCKS_COUNT
>
> Not all frontends will of course provide PER.
>
>> Behavior of UCB should remain quite same as it is currently, increases
>> slowly over the time. If you start resetting counters as for BER then
>> UCB is almost all the time 0. User wants to know UCB errors in frame of
>> days rather than minutes.
>
> Hmm... good point.
>
> Let's see when those counters would overflow with u64 (please correct
> if I did any wrong calculus on bc).

It will not overflow, as you maybe remember I calculated few days back 
that u32 will overflow BER counter in 10 seconds in very special case 
where I used 32MHz BW (DVB-C2) and quite optimal (14bit? SNR very big) 
samples from Shannon. If BER will not overflow then no need to care 
about uncorrected blocks as those are much more smaller than BER total bits.

> We have:
> 	2^64 = 18,446,744,073,709,551,616
>
> Assuming a bit rate of 54 Mbps, we have:
> 	bits_per_sec = (54*1024*1024*1024)
> 	bits_per_sec = 57,982,058,496
>
> In this case, the bit error count will overflow in:
> 	time_to_overflow = 2^64 seconds / bits_per_sec =
> 			 = 18,446,744,073,709,551,616 / 57,982,058,496
> 		         = 318,145,725 seconds
> So,
> 	time_to_overflow is more than 3682 days and more than 10 years
>
> DTV_QOS_TOTAL_BLOCKS_COUNT increments slower than DTV_QOS_TOTAL_BITS_COUNT
> (204 * 8 times slower).
>
> So, it would take 318,145,725 * 204 * 8 seconds (or 6,009,419 days) to
> overflow).
>
> IMHO, except for professional applications that would be continuously
> running for more than 10 years , there's no need to be
> careful about overflows.
>
> That said, I still think that the counters should be reset when
> a new channel is tuned (e. g. when set_frontend is called from
> userspace) or when the user requests for a counters reset, as the
> statistics from one channel/transponder are different than the ones
> for other channels/transponders.

Resetting counters when user tunes channel sounds the only correct option.

OK, maybe we will see in near future if that works well or not. I think 
that for calculating of PER it is required to start continuous polling 
to keep up total block counters. Maybe updating UCB counter continously 
needs that too, so it should work.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 19:22:06 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/17/2013 07:16 PM, Manu Abraham wrote:
> > On Thu, Jan 17, 2013 at 3:03 PM, Antti Palosaari <crope@iki.fi> wrote:
> >> On 01/17/2013 05:40 AM, Manu Abraham wrote:
> >>> MB86A20 is not the only demodulator driver with the Linux DVB.
> >>> And not all devices can output in dB scale proposed by you, But any device
> >>> output can be scaled in a relative way. So I don't see any reason why
> >>> userspace has to deal with cumbersome controls to deal with redundant
> >>> statistics, which is nonsense.
> >>
> >>
> >> What goes to these units in general, dB conversion is done by the driver
> >> about always. It is quite hard or even impossible to find out that formula
> >> unless you has adjustable test signal generator.
> >>
> >> Also we could not offer always dBm as signal strength. This comes to fact
> >> that only recent silicon RF-tuners are able to provide RF strength. More
> >> traditionally that estimation is done by demod from IF/RF AGC, which leads
> >> very, very, rough estimation.
> >
> > What I am saying is that, rather than sticking to a dB scale, it would be
> > better to fit it into a relative scale, ie loose dB altogether and use only the
> > relative scale. With that approach any device can be fit into that convention.
> > Even with an unknown device, it makes it pretty easy for anyone to fit
> > into that
> > scale. All you need is a few trial runs to get maxima/minima. When there
> > exists only a single convention that is simple, it makes it more easier for
> > people to stick to that convention, rather than for people to not support it.

As dB scale is never used for BER and UCB, I'm assuming that we're
talking about signal strength and S/N measures.

Get the maxima/minima for signal strength and S/N measures can be hard,
as it would require a signal generator and a noise generator that can
adjust the power levels for the signal and noise.

Also, if one has both, he/she can calibrate the scale to dB/dBm.

> That is true. I don't have really clear opinion whether to force all to 
> one scale, or return dBm those which could and that dummy scale for the 
> others. Maybe I will still vote for both relative and dBm.

>From the statistics you collected, most developers implemented dB scale,
especially with the new drivers. I also remember that most people mentioned
their preference to dB in the past.

> Shortly there is two possibilities:
> 1) support only relative scale

That doesn't solve, as a relative scale could still be logarithm or
linear. 

IMHO, a linear scale that doesn't much sense, as the effect 
of the signal power (or noise power) affects the quality
in a logarithm scale, but I'm pretty sure that some drivers 
report relative scales in a log scale, while others report
it with a linear scale.

> 2) support both dBm and relative scale (with dBm priority)

That seems to be the only choice if we want to improve from the current
status, e. g. explicitly saying what is the scale, when the developer
is able to discover it somehow (datasheets, empirical measurement,
reference drivers, etc).

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:

>
>
> Resetting counters when user tunes channel sounds the only correct option.
>

This might not be correct, especially when we have true Multiple Input Streams.
The tune might be single, but the filter setup would be different. In
which case it
wouldn't correct to do a reset of the counters ona tune. Resetting the counters
should be the responsibility of the driver. As I said in an earlier
post, anything
other than the driver handling any statistical event monitoring, such an API is
broken for sure, without even reading single line of code for that API for which
 it is written for.


> OK, maybe we will see in near future if that works well or not. I think that
> for calculating of PER it is required to start continuous polling to keep up
> total block counters. Maybe updating UCB counter continously needs that too,
> so it should work.


With multi-standard demodulators, some of them PER compute is a by-product
of some internal demodulator algorithmic operation. In some cases, it might
require a loop in the driver. As I said, again; It is very hard/wrong
to do basic
generalizations.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Fri, 18 Jan 2013 00:07:17 +0530
Manu Abraham <abraham.manu@gmail.com> escreveu:

> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
> 
> >
> >
> > Resetting counters when user tunes channel sounds the only correct option.
> >
> 
> This might not be correct, especially when we have true Multiple Input Streams.
> The tune might be single, but the filter setup would be different. In
> which case it
> wouldn't correct to do a reset of the counters ona tune. Resetting the counters
> should be the responsibility of the driver.

I moved the counters reset to the driver's logic on v11. I'm posting the
patches in a few.

> As I said in an earlier
> post, anything
> other than the driver handling any statistical event monitoring, such an API is
> broken for sure, without even reading single line of code for that API for which
>  it is written for.

Yes, driver should have full control on it.

> > OK, maybe we will see in near future if that works well or not. I think that
> > for calculating of PER it is required to start continuous polling to keep up
> > total block counters. Maybe updating UCB counter continously needs that too,
> > so it should work.
> 
> 
> With multi-standard demodulators, some of them PER compute is a by-product
> of some internal demodulator algorithmic operation. In some cases, it might
> require a loop in the driver. As I said, again; It is very hard/wrong
> to do basic
> generalizations.

Agreed.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
> Em Fri, 18 Jan 2013 00:07:17 +0530
> Manu Abraham <abraham.manu@gmail.com> escreveu:
>
>> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
>>
>>>
>>>
>>> Resetting counters when user tunes channel sounds the only correct option.
>>>
>>
>> This might not be correct, especially when we have true Multiple Input Streams.
>> The tune might be single, but the filter setup would be different. In
>> which case it
>> wouldn't correct to do a reset of the counters ona tune. Resetting the counters
>> should be the responsibility of the driver.
>
> I moved the counters reset to the driver's logic on v11. I'm posting the
> patches in a few.
>
>> As I said in an earlier
>> post, anything
>> other than the driver handling any statistical event monitoring, such an API is
>> broken for sure, without even reading single line of code for that API for which
>>   it is written for.
>
> Yes, driver should have full control on it.
>
>>> OK, maybe we will see in near future if that works well or not. I think that
>>> for calculating of PER it is required to start continuous polling to keep up
>>> total block counters. Maybe updating UCB counter continously needs that too,
>>> so it should work.
>>
>>
>> With multi-standard demodulators, some of them PER compute is a by-product
>> of some internal demodulator algorithmic operation. In some cases, it might
>> require a loop in the driver. As I said, again; It is very hard/wrong
>> to do basic
>> generalizations.
>
> Agreed.
>

I think we will have soon kinda consensus everyone could approve! 
Anyhow, I didn't liked that kind of PATCH RFC process. That change was 
too big for PATCH style RFC and it was hard to keep track what going on 
looking those patches. Maybe requirement specification RFCs first and 
when requirements are clear => PATCH RFC for implementation.

What I know understand, requirements are:

signal strength:
==============
Offer both discussed methods.
Simple [0...n] scale and dB...
Driver must support simple scale over dB.

CNR (SNR)
==============
Offer both discussed methods.
Simple [0...n] scale and dB...
Driver must support simple scale over dB.

BER
==============
Offer global BER and per layer BER.
Measure is returned as two numbers, one for error bit count and one for 
total bit count.

uncorrected packets/blocks
==============
Offer global UCB and per layer UCB.
Measure is returned as two numbers, one for uncorrected packet count and 
one for total packet count.

counter reset
==============
counters are reset when channel is tuned



And if we end up returning "simple" values over dB values, then I think 
driver could be simple and implement only dB and dvb-core is responsible 
to convert dB => simple. That should quite be possible as we know which 
dB value is good signal and which is bad signal.


Are these requirements now in line what is spoken?

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 21:11:08 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 18 Jan 2013 00:07:17 +0530
> > Manu Abraham <abraham.manu@gmail.com> escreveu:
> >
> >> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
> >>
> >>>
> >>>
> >>> Resetting counters when user tunes channel sounds the only correct option.
> >>>
> >>
> >> This might not be correct, especially when we have true Multiple Input Streams.
> >> The tune might be single, but the filter setup would be different. In
> >> which case it
> >> wouldn't correct to do a reset of the counters ona tune. Resetting the counters
> >> should be the responsibility of the driver.
> >
> > I moved the counters reset to the driver's logic on v11. I'm posting the
> > patches in a few.
> >
> >> As I said in an earlier
> >> post, anything
> >> other than the driver handling any statistical event monitoring, such an API is
> >> broken for sure, without even reading single line of code for that API for which
> >>   it is written for.
> >
> > Yes, driver should have full control on it.
> >
> >>> OK, maybe we will see in near future if that works well or not. I think that
> >>> for calculating of PER it is required to start continuous polling to keep up
> >>> total block counters. Maybe updating UCB counter continously needs that too,
> >>> so it should work.
> >>
> >>
> >> With multi-standard demodulators, some of them PER compute is a by-product
> >> of some internal demodulator algorithmic operation. In some cases, it might
> >> require a loop in the driver. As I said, again; It is very hard/wrong
> >> to do basic
> >> generalizations.
> >
> > Agreed.
> >
> 
> I think we will have soon kinda consensus everyone could approve! 
> Anyhow, I didn't liked that kind of PATCH RFC process. That change was 
> too big for PATCH style RFC and it was hard to keep track what going on 
> looking those patches. Maybe requirement specification RFCs first and 
> when requirements are clear => PATCH RFC for implementation.

Works for me.

> What I know understand, requirements are:
> 
> signal strength:
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.
> 
> CNR (SNR)
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.

Yes. 

For simple scale, n = 65535 should be, as most drivers that
use the simple scale use 0 to 65535 range. So, this range means
less driver changes.

> 
> BER
> ==============
> Offer global BER and per layer BER.
> Measure is returned as two numbers, one for error bit count and one for 
> total bit count.
> 
> uncorrected packets/blocks
> ==============
> Offer global UCB and per layer UCB.
> Measure is returned as two numbers, one for uncorrected packet count and 
> one for total packet count.
> 
> counter reset
> ==============
> counters are reset when channel is tuned
> 

> And if we end up returning "simple" values over dB values, then I think 
> driver could be simple and implement only dB and dvb-core is responsible 
> to convert dB => simple. That should quite be possible as we know which 
> dB value is good signal and which is bad signal.
> 
> 
> Are these requirements now in line what is spoken?

Yes.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Manu Abraham]

On Fri, Jan 18, 2013 at 12:41 AM, Antti Palosaari <crope@iki.fi> wrote:
> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
>>
>> Em Fri, 18 Jan 2013 00:07:17 +0530
>> Manu Abraham <abraham.manu@gmail.com> escreveu:
>>
>>> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>
>>>>
>>>>
>>>> Resetting counters when user tunes channel sounds the only correct
>>>> option.
>>>>
>>>
>>> This might not be correct, especially when we have true Multiple Input
>>> Streams.
>>> The tune might be single, but the filter setup would be different. In
>>> which case it
>>> wouldn't correct to do a reset of the counters ona tune. Resetting the
>>> counters
>>> should be the responsibility of the driver.
>>
>>
>> I moved the counters reset to the driver's logic on v11. I'm posting the
>> patches in a few.
>>
>>> As I said in an earlier
>>> post, anything
>>> other than the driver handling any statistical event monitoring, such an
>>> API is
>>> broken for sure, without even reading single line of code for that API
>>> for which
>>>   it is written for.
>>
>>
>> Yes, driver should have full control on it.
>>
>>>> OK, maybe we will see in near future if that works well or not. I think
>>>> that
>>>> for calculating of PER it is required to start continuous polling to
>>>> keep up
>>>> total block counters. Maybe updating UCB counter continously needs that
>>>> too,
>>>> so it should work.
>>>
>>>
>>>
>>> With multi-standard demodulators, some of them PER compute is a
>>> by-product
>>> of some internal demodulator algorithmic operation. In some cases, it
>>> might
>>> require a loop in the driver. As I said, again; It is very hard/wrong
>>> to do basic
>>> generalizations.
>>
>>
>> Agreed.
>>
>
> I think we will have soon kinda consensus everyone could approve! Anyhow, I
> didn't liked that kind of PATCH RFC process. That change was too big for
> PATCH style RFC and it was hard to keep track what going on looking those
> patches. Maybe requirement specification RFCs first and when requirements
> are clear => PATCH RFC for implementation.
>
> What I know understand, requirements are:
>
> signal strength:
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.


What happens, if the hardware doesn't support any dB scale ?


>
> CNR (SNR)
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.


Same question here as well.

>
> BER
> ==============
> Offer global BER and per layer BER.
> Measure is returned as two numbers, one for error bit count and one for
> total bit count.
>
> uncorrected packets/blocks
> ==============
> Offer global UCB and per layer UCB.
> Measure is returned as two numbers, one for uncorrected packet count and one
> for total packet count.
>
> counter reset
> ==============
> counters are reset when channel is tuned


Counter reset behaviour is a bit undefined, for the reason stated earlier.
ie, the driver should do the reset, as it sees fit rather than common code.
well, it would be correct to state at start of frame count after
stream is initialized.
Initialization of stream can happen on legacy systems: only after successful
synchronous viterbi is achieved. Tuning to a channel doesn't make any sense.

In some of the non-legacy systems, stream initialization would happen
on a filter
setup change as well. It is not dependent on a  channel switch/tune.


> And if we end up returning "simple" values over dB values, then I think
> driver could be simple and implement only dB and dvb-core is responsible to
> convert dB => simple. That should quite be possible as we know which dB
> value is good signal and which is bad signal.

Again, not all devices can output in dB.

Manu

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/17/2013 11:29 PM, Manu Abraham wrote:
> On Fri, Jan 18, 2013 at 12:41 AM, Antti Palosaari <crope@iki.fi> wrote:
>> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
>>>
>>> Em Fri, 18 Jan 2013 00:07:17 +0530
>>> Manu Abraham <abraham.manu@gmail.com> escreveu:
>>>
>>>> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>>
>>>>>
>>>>>
>>>>> Resetting counters when user tunes channel sounds the only correct
>>>>> option.
>>>>>
>>>>
>>>> This might not be correct, especially when we have true Multiple Input
>>>> Streams.
>>>> The tune might be single, but the filter setup would be different. In
>>>> which case it
>>>> wouldn't correct to do a reset of the counters ona tune. Resetting the
>>>> counters
>>>> should be the responsibility of the driver.
>>>
>>>
>>> I moved the counters reset to the driver's logic on v11. I'm posting the
>>> patches in a few.
>>>
>>>> As I said in an earlier
>>>> post, anything
>>>> other than the driver handling any statistical event monitoring, such an
>>>> API is
>>>> broken for sure, without even reading single line of code for that API
>>>> for which
>>>>    it is written for.
>>>
>>>
>>> Yes, driver should have full control on it.
>>>
>>>>> OK, maybe we will see in near future if that works well or not. I think
>>>>> that
>>>>> for calculating of PER it is required to start continuous polling to
>>>>> keep up
>>>>> total block counters. Maybe updating UCB counter continously needs that
>>>>> too,
>>>>> so it should work.
>>>>
>>>>
>>>>
>>>> With multi-standard demodulators, some of them PER compute is a
>>>> by-product
>>>> of some internal demodulator algorithmic operation. In some cases, it
>>>> might
>>>> require a loop in the driver. As I said, again; It is very hard/wrong
>>>> to do basic
>>>> generalizations.
>>>
>>>
>>> Agreed.
>>>
>>
>> I think we will have soon kinda consensus everyone could approve! Anyhow, I
>> didn't liked that kind of PATCH RFC process. That change was too big for
>> PATCH style RFC and it was hard to keep track what going on looking those
>> patches. Maybe requirement specification RFCs first and when requirements
>> are clear => PATCH RFC for implementation.
>>
>> What I know understand, requirements are:
>>
>> signal strength:
>> ==============
>> Offer both discussed methods.
>> Simple [0...n] scale and dB...
>> Driver must support simple scale over dB.
>
>
> What happens, if the hardware doesn't support any dB scale ?
>
>
>>
>> CNR (SNR)
>> ==============
>> Offer both discussed methods.
>> Simple [0...n] scale and dB...
>> Driver must support simple scale over dB.
>
>
> Same question here as well.
>
>>
>> BER
>> ==============
>> Offer global BER and per layer BER.
>> Measure is returned as two numbers, one for error bit count and one for
>> total bit count.
>>
>> uncorrected packets/blocks
>> ==============
>> Offer global UCB and per layer UCB.
>> Measure is returned as two numbers, one for uncorrected packet count and one
>> for total packet count.
>>
>> counter reset
>> ==============
>> counters are reset when channel is tuned
>
>
> Counter reset behaviour is a bit undefined, for the reason stated earlier.
> ie, the driver should do the reset, as it sees fit rather than common code.
> well, it would be correct to state at start of frame count after
> stream is initialized.
> Initialization of stream can happen on legacy systems: only after successful
> synchronous viterbi is achieved. Tuning to a channel doesn't make any sense.
>
> In some of the non-legacy systems, stream initialization would happen
> on a filter
> setup change as well. It is not dependent on a  channel switch/tune.
>
>
>> And if we end up returning "simple" values over dB values, then I think
>> driver could be simple and implement only dB and dvb-core is responsible to
>> convert dB => simple. That should quite be possible as we know which dB
>> value is good signal and which is bad signal.
>
> Again, not all devices can output in dB.
>
> Manu
>

I was a little bit unclear? There is two supported methods for SS and 
CNR, dB and relative scale to some defined range. If driver supports dB 
then dB is used, and if not then then relative scale is used.

My propose was to ask if we could add some generic calculations for the 
DVB-core, so that implementing only one method for the driver is enough. 
If app is asking relative value and driver does dB, then DVB-core makes 
conversion. For CNR, take CNR dB and modulation, return relative value 
for app. For SS conversion is even simpler.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Fri, 18 Jan 2013 00:22:00 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> My propose was to ask if we could add some generic calculations for the 
> DVB-core, so that implementing only one method for the driver is enough. 
> If app is asking relative value and driver does dB, then DVB-core makes 
> conversion. For CNR, take CNR dB and modulation, return relative value 
> for app. For SS conversion is even simpler.

Doing such conversion in kernelspace is simple, but doing it on
userspace is even simpler, as userspace can easily use float point
for the math.

Besides that, as Simon pointed, each application developer may use
different criteria to classify the reception as "poor", "good" and
"excellent".

So, IMHO, the kernel should report the measures on the best way that it is
possible for that hardware, and let userspace to apply the policies to
convert those measures into an user-friendly[1] information.

Regards,
Mauro

[1] Eventually, developers may be wrong about what users expect. By
putting that "quality" policy on userspace, it is easier to adapt it
to the users expectation for that particular application.

For example, I heard a lot of complaints with regards to Gnome 3 shell
because it removed several features that people were present on Gnome 2.
At the end, people  started to write Gnome3 applets in order to re-add
those removed features on Gnome 3, and/or make it look more like Gnome 2.

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 16 Jan 2013 20:01:53 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Wed, 16 Jan 2013 19:29:28 +0000
> Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:
...
> > So, how do you provide such information? 
...

I just finished to code it on my experimental tree:
	http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/stats

The code there is tested, and it should be displaying all stats at dvbv5-zap
code. While I didn't test yet, backward compatibility with DVBv3 stats is
provided.

What's missing:

a) a routine to calculate and return PER

I didn't write it just because I need to first make UCB/PER measurements to
work with mb86a20s. The userspace code, however, is trivial.

b) display only one layer for the statistics.

It is relatively easy to detect if the displayed program is 1-seg. 
All the code needs is to read the NIT table and check if the Partial TS 
descriptor is present at NIT table and matches the service ID of the
displayed program. If so, only the statistics for the 1-seg layer applied.
This descriptor is mandatory. So, a code for doing it shouldn't be hard
to code, and should work fine if just 2 layers (1-seg and 12-seg) are
present on a given channel (that's the most usual usecase).

However, I couldn't find yet a way to do the same for the 3-seg layer when
present. In thesis, the TS Information Descriptor would be carrying this
data, inside the Transmission Type field, but both ARIB and ABNT specs
I read lacks a table with the possible values for it. The ABNT spec
mentions that a latter document would carry that info, but I couldn't
find it yet. Also, the TS Information Descriptor is optional, although
I never find any broadcaster that don't implement it in Brazil, as, on
ISDB, the Remote Control channel uses this descriptor as well.
This is less critical than the first case, as most broadcasters use
2 layers. However, I've seen already a few broadcasters using 3 layers
(generally, 1-seg, 3-seg and 9-seg) on some cities.

So, for now, if multiple layers are found, the dvbv5-zap program on my
experimental tree will just display data for all existing layers.
I'll address it there later.

-

The following changes since commit 28178e74681db0d0d924b1c2cc69e0d7a9295b16:

  v4l2-compliance: add check whether the timestamp is monotonic. (2013-01-10 13:47:15 +0100)

are available in the git repository at:
  git://linuxtv.org/mchehab/experimental-v4l-utils.git stats

for you to fetch changes up to b20f43e723fa8fd5f1ed74f1566d314490946fa6:

  dvbv5-zap: better display BER (2013-01-19 09:30:18 -0200)

----------------------------------------------------------------
Mauro Carvalho Chehab (9):
      dvbv5-zap: Allow to enable FE debug
      Sync with kernel, with DVB stats
      dvb-fe: add support for DVBv5 stats
      dvbv5-zap: use the new DVBv5 stats API
      dvb-fe: Add a flag to indicate if DVBv5 stats is in use
      dvb-fe: Move the logic that calculates BER measures
      dvb-fe: Improve BER measurements for DVBv5
      dvb-fe: Allow returning BER in a float value
      dvbv5-zap: better display BER

 contrib/freebsd/include/linux/dvb/frontend.h |  77 +++++++++++++++++++++++++++++++++++++++++-
 contrib/freebsd/include/linux/dvb/version.h  |   2 +-
 lib/include/dvb-fe.h                         |  39 ++++++++++++++++------
 lib/include/dvb-frontend.h                   |  77 +++++++++++++++++++++++++++++++++++++++++-
 lib/include/dvb-v5-std.h                     |  12 ++++++-
 lib/libdvbv5/dvb-fe.c                        | 265 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------
 lib/libdvbv5/dvb-file.c                      |  24 ++------------
 lib/libdvbv5/dvb-v5-std.c                    |  19 ++++++++---
 lib/libdvbv5/dvb-v5.c                        |  10 ++++--
 lib/libdvbv5/dvb-v5.h                        |   2 +-
 utils/dvb/Makefile.am                        |   2 +-
 utils/dvb/dvbv5-zap.c                        | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------
 12 files changed, 590 insertions(+), 116 deletions(-)


Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Thu, 17 Jan 2013 21:11:08 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
> > Em Fri, 18 Jan 2013 00:07:17 +0530
> > Manu Abraham <abraham.manu@gmail.com> escreveu:
> >
> >> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
> >>
> >>>
> >>>
> >>> Resetting counters when user tunes channel sounds the only correct option.
> >>>
> >>
> >> This might not be correct, especially when we have true Multiple Input Streams.
> >> The tune might be single, but the filter setup would be different. In
> >> which case it
> >> wouldn't correct to do a reset of the counters ona tune. Resetting the counters
> >> should be the responsibility of the driver.
> >
> > I moved the counters reset to the driver's logic on v11. I'm posting the
> > patches in a few.
> >
> >> As I said in an earlier
> >> post, anything
> >> other than the driver handling any statistical event monitoring, such an API is
> >> broken for sure, without even reading single line of code for that API for which
> >>   it is written for.
> >
> > Yes, driver should have full control on it.
> >
> >>> OK, maybe we will see in near future if that works well or not. I think that
> >>> for calculating of PER it is required to start continuous polling to keep up
> >>> total block counters. Maybe updating UCB counter continously needs that too,
> >>> so it should work.
> >>
> >>
> >> With multi-standard demodulators, some of them PER compute is a by-product
> >> of some internal demodulator algorithmic operation. In some cases, it might
> >> require a loop in the driver. As I said, again; It is very hard/wrong
> >> to do basic
> >> generalizations.
> >
> > Agreed.
> >
> 
> I think we will have soon kinda consensus everyone could approve! 
> Anyhow, I didn't liked that kind of PATCH RFC process. That change was 
> too big for PATCH style RFC and it was hard to keep track what going on 
> looking those patches. Maybe requirement specification RFCs first and 
> when requirements are clear => PATCH RFC for implementation.
> 
> What I know understand, requirements are:
> 
> signal strength:
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.
> 
> CNR (SNR)
> ==============
> Offer both discussed methods.
> Simple [0...n] scale and dB...
> Driver must support simple scale over dB.
> 
> BER
> ==============
> Offer global BER and per layer BER.
> Measure is returned as two numbers, one for error bit count and one for 
> total bit count.
> 
> uncorrected packets/blocks
> ==============
> Offer global UCB and per layer UCB.
> Measure is returned as two numbers, one for uncorrected packet count and 
> one for total packet count.
> 
> counter reset
> ==============
> counters are reset when channel is tuned
> 
> 
> 
> And if we end up returning "simple" values over dB values, then I think 
> driver could be simple and implement only dB and dvb-core is responsible 
> to convert dB => simple. That should quite be possible as we know which 
> dB value is good signal and which is bad signal.
> 
> 
> Are these requirements now in line what is spoken?

Ok, I updated the DocBook to match what I understood from the above and from
our discussions. Please check.

---

Frontend statistics indicators
==============================

The values are returned via dtv_property.stat. If the property is supported, dtv_property.stat.len is bigger than zero.

For most delivery systems, dtv_property.stat.len will be 1 if the stats is supported, and the properties will return a single value for each parameter.

It should be noticed, however, that new OFDM delivery systems like ISDB can use different modulation types for each group of carriers. On such standards, up to 3 groups of statistics can be provided, and dtv_property.stat.len is updated to reflect the "global" metrics, plus one metric per each carrier group (called "layer" on ISDB).

So, in order to be consistent with other delivery systems, the first value at dtv_property.stat.dtv_stats array refers to the global metric. The other elements of the array represent each layer, starting from layer A(index 1), layer B (index 2) and so on.

The number of filled elements are stored at dtv_property.stat.len.

Each element of the dtv_property.stat.dtv_stats array consists on two elements:

    svalue or uvalue: svalue is for signed values of the measure (dB measures) and uvalue is for unsigned values (counters, relative scale)

    scale - Scale for the value. It can be:

        FE_SCALE_NOT_AVAILABLE - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)

        FE_SCALE_DECIBEL - parameter is a signed value, measured in 1/1000 dB

        FE_SCALE_RELATIVE - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.

        FE_SCALE_COUNTER - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.

DTV_STAT_SIGNAL_STRENGTH
========================

Indicates the signal strength level at the analog part of the tuner or of the demod.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_DECIBEL - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.
    FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for power (actually, 0-65535).

DTV_STAT_CNR
============

Indicates the Signal to Noise ratio for the main carrier.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_DECIBEL - Signal/Noise ratio is in 0.0001 dB units.
    FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0-65535).

DTV_STAT_BIT_ERROR_COUNT
========================

Measures the number of bit errors before Viterbi.

This measure is taken during the same interval as DTV_STAT_TOTAL_BITS_COUNT.

In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_TOTAL_BITS_COUNT.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error bits counted before Viterbi.

DTV_STAT_TOTAL_BITS_COUNT
=========================

Measures the amount of bits received before the Viterbi block, during the same period as DTV_STAT_BIT_ERROR_COUNT measurement was taken.

It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of bits counted while measuring DTV_STAT_BIT_ERROR_COUNT.

DTV_STAT_ERROR_BLOCK_COUNT
==========================

Measures the number of block errors.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error blocks counted after Red Salomon.

DTV-STAT_TOTAL_BLOCKS_COUNT
===========================

Measures the total number of blocks received during the same period as DTV_STAT_ERROR_BLOCK_COUNT measurement was taken.

It can be used to calculate the PER indicator, by dividing DTV_STAT_ERROR_BLOCK_COUNT by DTV-STAT-TOTAL-BLOCKS-COUNT.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of blocks counted while measuring DTV_STAT_ERROR_BLOCK_COUNT.

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/22/2013 02:16 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Jan 2013 21:11:08 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> On 01/17/2013 08:50 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 18 Jan 2013 00:07:17 +0530
>>> Manu Abraham <abraham.manu@gmail.com> escreveu:
>>>
>>>> On Thu, Jan 17, 2013 at 11:57 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>>
>>>>>
>>>>>
>>>>> Resetting counters when user tunes channel sounds the only correct option.
>>>>>
>>>>
>>>> This might not be correct, especially when we have true Multiple Input Streams.
>>>> The tune might be single, but the filter setup would be different. In
>>>> which case it
>>>> wouldn't correct to do a reset of the counters ona tune. Resetting the counters
>>>> should be the responsibility of the driver.
>>>
>>> I moved the counters reset to the driver's logic on v11. I'm posting the
>>> patches in a few.
>>>
>>>> As I said in an earlier
>>>> post, anything
>>>> other than the driver handling any statistical event monitoring, such an API is
>>>> broken for sure, without even reading single line of code for that API for which
>>>>    it is written for.
>>>
>>> Yes, driver should have full control on it.
>>>
>>>>> OK, maybe we will see in near future if that works well or not. I think that
>>>>> for calculating of PER it is required to start continuous polling to keep up
>>>>> total block counters. Maybe updating UCB counter continously needs that too,
>>>>> so it should work.
>>>>
>>>>
>>>> With multi-standard demodulators, some of them PER compute is a by-product
>>>> of some internal demodulator algorithmic operation. In some cases, it might
>>>> require a loop in the driver. As I said, again; It is very hard/wrong
>>>> to do basic
>>>> generalizations.
>>>
>>> Agreed.
>>>
>>
>> I think we will have soon kinda consensus everyone could approve!
>> Anyhow, I didn't liked that kind of PATCH RFC process. That change was
>> too big for PATCH style RFC and it was hard to keep track what going on
>> looking those patches. Maybe requirement specification RFCs first and
>> when requirements are clear => PATCH RFC for implementation.
>>
>> What I know understand, requirements are:
>>
>> signal strength:
>> ==============
>> Offer both discussed methods.
>> Simple [0...n] scale and dB...
>> Driver must support simple scale over dB.
>>
>> CNR (SNR)
>> ==============
>> Offer both discussed methods.
>> Simple [0...n] scale and dB...
>> Driver must support simple scale over dB.
>>
>> BER
>> ==============
>> Offer global BER and per layer BER.
>> Measure is returned as two numbers, one for error bit count and one for
>> total bit count.
>>
>> uncorrected packets/blocks
>> ==============
>> Offer global UCB and per layer UCB.
>> Measure is returned as two numbers, one for uncorrected packet count and
>> one for total packet count.
>>
>> counter reset
>> ==============
>> counters are reset when channel is tuned
>>
>>
>>
>> And if we end up returning "simple" values over dB values, then I think
>> driver could be simple and implement only dB and dvb-core is responsible
>> to convert dB => simple. That should quite be possible as we know which
>> dB value is good signal and which is bad signal.
>>
>>
>> Are these requirements now in line what is spoken?
>
> Ok, I updated the DocBook to match what I understood from the above and from
> our discussions. Please check.
>
> ---
>
> Frontend statistics indicators
> ==============================
>
> The values are returned via dtv_property.stat. If the property is supported, dtv_property.stat.len is bigger than zero.
>
> For most delivery systems, dtv_property.stat.len will be 1 if the stats is supported, and the properties will return a single value for each parameter.
>
> It should be noticed, however, that new OFDM delivery systems like ISDB can use different modulation types for each group of carriers. On such standards, up to 3 groups of statistics can be provided, and dtv_property.stat.len is updated to reflect the "global" metrics, plus one metric per each carrier group (called "layer" on ISDB).
>
> So, in order to be consistent with other delivery systems, the first value at dtv_property.stat.dtv_stats array refers to the global metric. The other elements of the array represent each layer, starting from layer A(index 1), layer B (index 2) and so on.
>
> The number of filled elements are stored at dtv_property.stat.len.
>
> Each element of the dtv_property.stat.dtv_stats array consists on two elements:
>
>      svalue or uvalue: svalue is for signed values of the measure (dB measures) and uvalue is for unsigned values (counters, relative scale)
>
>      scale - Scale for the value. It can be:
>
>          FE_SCALE_NOT_AVAILABLE - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)
>
>          FE_SCALE_DECIBEL - parameter is a signed value, measured in 1/1000 dB
>
>          FE_SCALE_RELATIVE - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.
>
>          FE_SCALE_COUNTER - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.

These are OK

>
> DTV_STAT_SIGNAL_STRENGTH
> ========================
>
> Indicates the signal strength level at the analog part of the tuner or of the demod.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_DECIBEL - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.
>      FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for power (actually, 0-65535).

These are OK

>
> DTV_STAT_CNR
> ============
>
> Indicates the Signal to Noise ratio for the main carrier.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_DECIBEL - Signal/Noise ratio is in 0.0001 dB units.
>      FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0-65535).

These are OK

>
> DTV_STAT_BIT_ERROR_COUNT
> ========================
>
> Measures the number of bit errors before Viterbi.

It is not Viterbi, it is inner code (aka inner FEC)! Viterbi is old and 
legacy algorithm and not used for new systems. It was replaced mostly by 
LDPC algorithm (low-density parity-check).

Also, I have changed a little bit of my mind and I think it is better to 
offer post-BER rather than pre-BER (VBER, or Viterbi BER, is same as 
post-BER, BER measured after the Viterbi coding). From the post-BER we 
could make some estimation what is possibility of uncorrected packets 
(after the outer coding). I am not against to offer both pre-BER and 
post-BER.

But the biggest problem is that you speak Viterbi algorithm, as we has 
some others too! Use general terms instead.

>
> This measure is taken during the same interval as DTV_STAT_TOTAL_BITS_COUNT.
>
> In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_TOTAL_BITS_COUNT.
>
> This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_COUNTER - Number of error bits counted before Viterbi.

The rest in that section are OK.

>
> DTV_STAT_TOTAL_BITS_COUNT
> =========================

This sounds wrong in my ears. I am not native English speaker, but for 
me DTV_STAT_TOTAL_BIT_COUNT sounds correct.

>
> Measures the amount of bits received before the Viterbi block, during the same period as DTV_STAT_BIT_ERROR_COUNT measurement was taken.
>
> It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.
>
> This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_COUNTER - Number of bits counted while measuring DTV_STAT_BIT_ERROR_COUNT.

The rest in that section are OK.

>
> DTV_STAT_ERROR_BLOCK_COUNT
> ==========================
>
> Measures the number of block errors.

Block errors after the outer coding. OK, maybe better to leave it out 
and keep that doc less technical. But on the other hand, you mention 
Viterbi (inner coding) on BER measurement, so these two are not 
documented consistent. Also, it is easier to say during review that this 
is wrong if there is clearly documented what all the measurements are 
(even those are something like defacto terms in digital transmission). 
Not so much stupid yes/no discussion and explaining.

>
> This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_COUNTER - Number of error blocks counted after Red Salomon.

It is Reed–Solomon != Red Salomon

Also same for that than Viterbi. There is other algorithms used 
nowadays. Better to use some generic term like outer coding or outer FEC.

Packet or block? I think packet is more generic, whilst block is used 
more in certain cases like Reed-Solomon.


>
> DTV-STAT_TOTAL_BLOCKS_COUNT
> ===========================

DTV-STAT_TOTAL_BLOCK_COUNT ?

>
> Measures the total number of blocks received during the same period as DTV_STAT_ERROR_BLOCK_COUNT measurement was taken.
>
> It can be used to calculate the PER indicator, by dividing DTV_STAT_ERROR_BLOCK_COUNT by DTV-STAT-TOTAL-BLOCKS-COUNT.
>
> Possible scales for this metric are:
>
>      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
>      FE_SCALE_COUNTER - Number of blocks counted while measuring DTV_STAT_ERROR_BLOCK_COUNT.
>
The rest in that section are OK.

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/23/2013 05:08 PM, Antti Palosaari wrote:
> On 01/22/2013 02:16 PM, Mauro Carvalho Chehab wrote:
>> Em Thu, 17 Jan 2013 21:11:08 +0200
>> Antti Palosaari <crope@iki.fi> escreveu:

I forget to mention the most important thing - I didn't saw any 
functionality problems!

regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 23 Jan 2013 17:08:59 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/22/2013 02:16 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 17 Jan 2013 21:11:08 +0200
> > Antti Palosaari <crope@iki.fi> escreveu:
> >
> >
> > DTV_STAT_BIT_ERROR_COUNT
> > ========================
> >
> > Measures the number of bit errors before Viterbi.
> 
> It is not Viterbi, it is inner code (aka inner FEC)! Viterbi is old and 
> legacy algorithm and not used for new systems. It was replaced mostly by 
> LDPC algorithm (low-density parity-check).

Yes, on newer standards. However, the API spec still mentions Viterbi as
one or the frontend possible status.

Anyway, I agree: it is better to use the generic term. However, as calling it
as pre-Viterbi BER is common, I opted to keep the Viterbi nomenclature in
parenthesis.

While here, I'll also fix the status documentation at the DVB API:

 <entry align="char">FE_HAS_VITERBI</entry>
-<entry align="char">The frontend FEC code is stable</entry>
+<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>

> Also, I have changed a little bit of my mind and I think it is better to 
> offer post-BER rather than pre-BER (VBER, or Viterbi BER, is same as 
> post-BER, BER measured after the Viterbi coding). From the post-BER we 
> could make some estimation what is possibility of uncorrected packets 
> (after the outer coding). I am not against to offer both pre-BER and 
> post-BER.

Ok, I'll add both then. I have already coded the pre-BER code for mb86a20s.
I'll later code a post-BER logic there at the driver.

> But the biggest problem is that you speak Viterbi algorithm, as we has 
> some others too! Use general terms instead.
> 
> >
> > This measure is taken during the same interval as DTV_STAT_TOTAL_BITS_COUNT.
> >
> > In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_TOTAL_BITS_COUNT.
> >
> > This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
> >
> > Possible scales for this metric are:
> >
> >      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
> >      FE_SCALE_COUNTER - Number of error bits counted before Viterbi.
> 
> The rest in that section are OK.
> 
> >
> > DTV_STAT_TOTAL_BITS_COUNT
> > =========================
> 
> This sounds wrong in my ears. I am not native English speaker, but for 
> me DTV_STAT_TOTAL_BIT_COUNT sounds correct.
> 
> >
> > Measures the amount of bits received before the Viterbi block, during the same period as DTV_STAT_BIT_ERROR_COUNT measurement was taken.
> >
> > It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.
> >
> > This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
> >
> > Possible scales for this metric are:
> >
> >      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
> >      FE_SCALE_COUNTER - Number of bits counted while measuring DTV_STAT_BIT_ERROR_COUNT.
> 
> The rest in that section are OK.

I think it is not incorrect to say bits count, but the better is to use
singular on all measures.

Ok, This is how those measures are now shown after the fixes:

DTV_STAT_PRE_BIT_ERROR_COUNT
============================

Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).

This measure is taken during the same interval as DTV_STAT_PRE_TOTAL_BIT_COUNT.

In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_PRE_TOTAL_BIT_COUNT.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error bits counted before the inner coding.

DTV_STAT_PRE_TOTAL_BIT_COUNT
============================

Measures the amount of bits received before the inner code block, during the same period as DTV_STAT_PRE_BIT_ERROR_COUNT measurement was taken.

It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of bits counted while measuring DTV_STAT_PRE_BIT_ERROR_COUNT.

DTV_STAT_POST_BIT_ERROR_COUNT
=============================

Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).

This measure is taken during the same interval as DTV_STAT_POST_TOTAL_BIT_COUNT.

In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_POST_TOTAL_BIT_COUNT.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error bits counted after the inner coding.

DTV_STAT_POST_BIT_ERROR_COUNT
=============================

Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).

This measure is taken during the same interval as DTV_STAT_POST_TOTAL_BIT_COUNT.

In order to get the BER (Bit Error Rate) measurement, it should be divided by DTV_STAT_POST_TOTAL_BIT_COUNT.

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error bits counted after the inner coding

> 
> >
> > DTV_STAT_ERROR_BLOCK_COUNT
> > ==========================
> >
> > Measures the number of block errors.
> 
> Block errors after the outer coding. OK, maybe better to leave it out 
> and keep that doc less technical. But on the other hand, you mention 
> Viterbi (inner coding) on BER measurement, so these two are not 
> documented consistent. Also, it is easier to say during review that this 
> is wrong if there is clearly documented what all the measurements are 
> (even those are something like defacto terms in digital transmission). 
> Not so much stupid yes/no discussion and explaining.

IMO, it is better to be more technical, to avoid implementation mistakes.

Changed it to:

DTV_STAT_ERROR_BLOCK_COUNT
==========================

Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).

This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.

Possible scales for this metric are:

    FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
    FE_SCALE_COUNTER - Number of error blocks counted after the outer coding.
> 
> >
> > This measurement is monotonically increased, as the frontend gets more bit count measurements. The frontend may reset it when a channel/transponder is tuned.
> >
> > Possible scales for this metric are:
> >
> >      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
> >      FE_SCALE_COUNTER - Number of error blocks counted after Red Salomon.
> 
> It is Reed–Solomon != Red Salomon

Yes, I know. My brain trapped me on that ;)

> Also same for that than Viterbi. There is other algorithms used 
> nowadays. Better to use some generic term like outer coding or outer FEC.
> 
> Packet or block? I think packet is more generic, whilst block is used 
> more in certain cases like Reed-Solomon.

I think both terms are almost synonymous. Packet reminds more like an
IP-based variable-length sequence, where block sounds more like a 
fixed-length.

As those measures can be used either for UCB (blocks) or PER (packet),
both terms sound correct, IMHO.

I would keep block, as UCB is a more common measurement than PER.

> >
> > DTV-STAT_TOTAL_BLOCKS_COUNT
> > ===========================
> 
> DTV-STAT_TOTAL_BLOCK_COUNT ?

OK.

> 
> >
> > Measures the total number of blocks received during the same period as DTV_STAT_ERROR_BLOCK_COUNT measurement was taken.
> >
> > It can be used to calculate the PER indicator, by dividing DTV_STAT_ERROR_BLOCK_COUNT by DTV-STAT-TOTAL-BLOCKS-COUNT.
> >
> > Possible scales for this metric are:
> >
> >      FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet.
> >      FE_SCALE_COUNTER - Number of blocks counted while measuring DTV_STAT_ERROR_BLOCK_COUNT.
> >
> The rest in that section are OK.

Ok, thanks for your review!

I'll soon post patches 1 and 2 after those changes. The remaining 4 patches
don't likely need any change.

Regards,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 23 Jan 2013 16:18:01 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> I'll soon post patches 1 and 2 after those changes. The remaining 4 patches
> don't likely need any change.

Actually, it sounds better to just do a diff between the two versions.
Each individual patch on v13 is at:
	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/stats_v13

Cheers,
Mauro

v13:
- Add post-Viterbi BER on the API
- Some documentation adjustments as suggested by Antti

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

diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 3f9f451..772314a 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -467,7 +467,7 @@ typedef enum fe_delivery_system {
 		<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
 		<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
 			ISDB-T hierarchical layers can be decoded simultaneously. For that
-			reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
+			reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
 		<para>ISDB-T has 3 hierarchical layers which each can use a part of the
 			available segments. The total number of segments over all layers has
 			to 13 in ISDB-T.</para>
@@ -933,24 +933,24 @@ enum fe_interleaving {
 			<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
 		</itemizedlist>
 	</section>
-	<section id="DTV-STAT-BIT-ERROR-COUNT">
-		<title><constant>DTV_STAT_BIT_ERROR_COUNT</constant></title>
-		<para>Measures the number of bit errors before Viterbi.</para>
-		<para>This measure is taken during the same interval as <constant>DTV_STAT_TOTAL_BITS_COUNT</constant>.</para>
+	<section id="DTV-STAT-PRE-BIT-ERROR-COUNT">
+		<title><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></title>
+		<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
+		<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
 		<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
-		<link linkend="DTV-STAT-TOTAL-BITS-COUNT"><constant>DTV_STAT_TOTAL_BITS_COUNT</constant></link>.</para>
+		<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
 		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
 		      The frontend may reset it when a channel/transponder is tuned.</para>
 		<para>Possible scales for this metric are:</para>
 		<itemizedlist mark='bullet'>
 			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before Viterbi.</listitem>
+			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
 		</itemizedlist>
 	</section>
-	<section id="DTV-STAT-TOTAL-BITS-COUNT">
-		<title><constant>DTV_STAT_TOTAL_BITS_COUNT</constant></title>
-		<para>Measures the amount of bits received before the Viterbi block, during the same period as
-		<link linkend="DTV-STAT-BIT-ERROR-COUNT"><constant>DTV_STAT_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
+	<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
+		<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
+		<para>Measures the amount of bits received before the inner code block, during the same period as
+		<link linkend="DTV-STAT-PRE-BIT-ERROR-COUNT"><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
 		<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
 		      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
 		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
@@ -959,27 +959,56 @@ enum fe_interleaving {
 		<itemizedlist mark='bullet'>
 			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
 			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
-				 <link linkend="DTV-STAT-BIT-ERROR-COUNT"><constant>DTV_STAT_BIT_ERROR_COUNT</constant></link>.</listitem>
+				 <link linkend="DTV-STAT-PRE-BIT-ERROR-COUNT"><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></link>.</listitem>
+		</itemizedlist>
+	</section>
+	<section id="DTV-STAT-POST-BIT-ERROR-COUNT">
+		<title><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></title>
+		<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
+		<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
+		<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
+		<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
+		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+		      The frontend may reset it when a channel/transponder is tuned.</para>
+		<para>Possible scales for this metric are:</para>
+		<itemizedlist mark='bullet'>
+			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
+		</itemizedlist>
+	</section>
+	<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
+		<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
+		<para>Measures the amount of bits received after the inner coding, during the same period as
+		<link linkend="DTV-STAT-POST-BIT-ERROR-COUNT"><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
+		<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
+		      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
+		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
+		      The frontend may reset it when a channel/transponder is tuned.</para>
+		<para>Possible scales for this metric are:</para>
+		<itemizedlist mark='bullet'>
+			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
+			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
+				 <link linkend="DTV-STAT-POST-BIT-ERROR-COUNT"><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></link>.</listitem>
 		</itemizedlist>
 	</section>
 	<section id="DTV-STAT-ERROR-BLOCK-COUNT">
 		<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
-		<para>Measures the number of block errors.</para>
+		<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
 		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
 		      The frontend may reset it when a channel/transponder is tuned.</para>
 		<para>Possible scales for this metric are:</para>
 		<itemizedlist mark='bullet'>
 			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
-			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after Red Salomon.</listitem>
+			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
 		</itemizedlist>
 	</section>
-	<section id="DTV-STAT-TOTAL-BLOCKS-COUNT">
-		<title><constant>DTV-STAT_TOTAL_BLOCKS_COUNT</constant></title>
+	<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
+		<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
 		<para>Measures the total number of blocks received during the same period as
 		<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
 		<para>It can be used to calculate the PER indicator, by dividing
 		<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
-		by <link linkend="DTV-STAT-TOTAL-BLOCKS-COUNT"><constant>DTV-STAT-TOTAL-BLOCKS-COUNT</constant></link>.</para>
+		by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
 		<para>Possible scales for this metric are:</para>
 		<itemizedlist mark='bullet'>
 			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
index 426c252..df39ba3 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -230,7 +230,7 @@ typedef enum fe_status {
 <entry align="char">The frontend has found a DVB signal</entry>
 </row><row>
 <entry align="char">FE_HAS_VITERBI</entry>
-<entry align="char">The frontend FEC code is stable</entry>
+<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
 </row><row>
 <entry align="char">FE_HAS_SYNC</entry>
 <entry align="char">Syncronization bytes was found</entry>
diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index 66be7f7..f8943c2 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1057,10 +1057,12 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
 	/* Statistics API */
 	_DTV_CMD(DTV_STAT_SIGNAL_STRENGTH, 0, 0),
 	_DTV_CMD(DTV_STAT_CNR, 0, 0),
-	_DTV_CMD(DTV_STAT_BIT_ERROR_COUNT, 0, 0),
-	_DTV_CMD(DTV_STAT_TOTAL_BITS_COUNT, 0, 0),
+	_DTV_CMD(DTV_STAT_PRE_BIT_ERROR_COUNT, 0, 0),
+	_DTV_CMD(DTV_STAT_PRE_TOTAL_BIT_COUNT, 0, 0),
+	_DTV_CMD(DTV_STAT_POST_BIT_ERROR_COUNT, 0, 0),
+	_DTV_CMD(DTV_STAT_POST_TOTAL_BIT_COUNT, 0, 0),
 	_DTV_CMD(DTV_STAT_ERROR_BLOCK_COUNT, 0, 0),
-	_DTV_CMD(DTV_STAT_TOTAL_BLOCKS_COUNT, 0, 0),
+	_DTV_CMD(DTV_STAT_TOTAL_BLOCK_COUNT, 0, 0),
 };
 
 static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property *tvp)
@@ -1458,16 +1460,22 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
 	case DTV_STAT_CNR:
 		tvp->u.st = c->cnr;
 		break;
-	case DTV_STAT_BIT_ERROR_COUNT:
-		tvp->u.st = c->bit_error;
+	case DTV_STAT_PRE_BIT_ERROR_COUNT:
+		tvp->u.st = c->pre_bit_error;
 		break;
-	case DTV_STAT_TOTAL_BITS_COUNT:
-		tvp->u.st = c->bit_count;
+	case DTV_STAT_PRE_TOTAL_BIT_COUNT:
+		tvp->u.st = c->pre_bit_count;
+		break;
+	case DTV_STAT_POST_BIT_ERROR_COUNT:
+		tvp->u.st = c->post_bit_error;
+		break;
+	case DTV_STAT_POST_TOTAL_BIT_COUNT:
+		tvp->u.st = c->post_bit_count;
 		break;
 	case DTV_STAT_ERROR_BLOCK_COUNT:
 		tvp->u.st = c->block_error;
 		break;
-	case DTV_STAT_TOTAL_BLOCKS_COUNT:
+	case DTV_STAT_TOTAL_BLOCK_COUNT:
 		tvp->u.st = c->block_count;
 		break;
 	default:
diff --git a/drivers/media/dvb-core/dvb_frontend.h b/drivers/media/dvb-core/dvb_frontend.h
index 47952c5..b34922a 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -397,8 +397,10 @@ struct dtv_frontend_properties {
 	/* statistics data */
 	struct dtv_fe_stats	strength;
 	struct dtv_fe_stats	cnr;
-	struct dtv_fe_stats	bit_error;
-	struct dtv_fe_stats	bit_count;
+	struct dtv_fe_stats	pre_bit_error;
+	struct dtv_fe_stats	pre_bit_count;
+	struct dtv_fe_stats	post_bit_error;
+	struct dtv_fe_stats	post_bit_count;
 	struct dtv_fe_stats	block_error;
 	struct dtv_fe_stats	block_count;
 };
diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index 56a027c..4f3e222 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -721,8 +721,8 @@ static int mb86a20s_reset_counters(struct dvb_frontend *fe)
 	if (state->last_frequency != c->frequency) {
 		memset(&c->strength, 0, sizeof(c->strength));
 		memset(&c->cnr, 0, sizeof(c->cnr));
-		memset(&c->bit_error, 0, sizeof(c->bit_error));
-		memset(&c->bit_count, 0, sizeof(c->bit_count));
+		memset(&c->pre_bit_error, 0, sizeof(c->pre_bit_error));
+		memset(&c->pre_bit_count, 0, sizeof(c->pre_bit_count));
 		memset(&c->block_error, 0, sizeof(c->block_error));
 		memset(&c->block_count, 0, sizeof(c->block_count));
 
@@ -1232,8 +1232,8 @@ static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
 
 	/* Per-layer stats - 3 layers + global */
 	c->cnr.len = 4;
-	c->bit_error.len = 4;
-	c->bit_count.len = 4;
+	c->pre_bit_error.len = 4;
+	c->pre_bit_count.len = 4;
 	c->block_error.len = 4;
 	c->block_count.len = 4;
 
@@ -1244,8 +1244,8 @@ static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
 	/* Put all of them at FE_SCALE_NOT_AVAILABLE */
 	for (i = 0; i < 4; i++) {
 		c->cnr.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
-		c->bit_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
-		c->bit_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->pre_bit_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
+		c->pre_bit_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
 		c->block_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
 		c->block_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
 	}
@@ -1257,7 +1257,7 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	int rc = 0, i;
 	u32 bit_error = 0, bit_count = 0;
-	u32 t_bit_error = 0, t_bit_count = 0;
+	u32 t_pre_bit_error = 0, t_pre_bit_count = 0;
 	int active_layers = 0, ber_layers = 0;
 
 	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
@@ -1278,17 +1278,17 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 							&bit_error,
 							&bit_count);
 			if (rc >= 0) {
-				c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
-				c->bit_error.stat[1 + i].uvalue += bit_error;
-				c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
-				c->bit_count.stat[1 + i].uvalue += bit_count;
+				c->pre_bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
+				c->pre_bit_error.stat[1 + i].uvalue += bit_error;
+				c->pre_bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
+				c->pre_bit_count.stat[1 + i].uvalue += bit_count;
 			} else if (rc != -EBUSY) {
 				/*
 					* If an I/O error happened,
 					* measures are now unavailable
 					*/
-				c->bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
-				c->bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
+				c->pre_bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
+				c->pre_bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
 				dev_err(&state->i2c->dev,
 					"%s: Can't get BER for layer %c (error %d).\n",
 					__func__, 'A' + i, rc);
@@ -1298,8 +1298,8 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 				ber_layers++;
 
 			/* Update total BER */
-			t_bit_error += c->bit_error.stat[1 + i].uvalue;
-			t_bit_count += c->bit_count.stat[1 + i].uvalue;
+			t_pre_bit_error += c->pre_bit_error.stat[1 + i].uvalue;
+			t_pre_bit_count += c->pre_bit_count.stat[1 + i].uvalue;
 		}
 	}
 
@@ -1315,10 +1315,10 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
 		 * Total Bit Error/Count is calculated as the sum of the
 		 * bit errors on all active layers.
 		 */
-		c->bit_error.stat[0].scale = FE_SCALE_COUNTER;
-		c->bit_error.stat[0].uvalue = t_bit_error;
-		c->bit_count.stat[0].scale = FE_SCALE_COUNTER;
-		c->bit_count.stat[0].uvalue = t_bit_count;
+		c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+		c->pre_bit_error.stat[0].uvalue = t_pre_bit_error;
+		c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+		c->pre_bit_count.stat[0].uvalue = t_pre_bit_count;
 	}
 
 	return rc;
@@ -1544,12 +1544,12 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
 	struct mb86a20s_state *state;
 	u8	rev;
 
+	dev_dbg(&i2c->dev, "%s called.\n", __func__);
+
 	/* allocate memory for the internal state */
 	state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
-
-	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
 	if (state == NULL) {
-		dev_err(&state->i2c->dev,
+		dev_err(&i2c->dev,
 			"%s: unable to allocate memory for state\n", __func__);
 		goto error;
 	}
@@ -1567,10 +1567,10 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
 	rev = mb86a20s_readreg(state, 0);
 
 	if (rev == 0x13) {
-		dev_info(&state->i2c->dev,
+		dev_info(&i2c->dev,
 			 "Detected a Fujitsu mb86a20s frontend\n");
 	} else {
-		dev_dbg(&state->i2c->dev,
+		dev_dbg(&i2c->dev,
 			"Frontend revision %d is unknown - aborting.\n",
 		       rev);
 		goto error;
diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h
index 0cd62bd..1913a36 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -368,12 +368,14 @@ struct dvb_frontend_event {
 /* Quality parameters */
 #define DTV_STAT_SIGNAL_STRENGTH	62
 #define DTV_STAT_CNR			63
-#define DTV_STAT_BIT_ERROR_COUNT	64
-#define DTV_STAT_TOTAL_BITS_COUNT	65
-#define DTV_STAT_ERROR_BLOCK_COUNT	66
-#define DTV_STAT_TOTAL_BLOCKS_COUNT	67
-
-#define DTV_MAX_COMMAND		DTV_STAT_TOTAL_BLOCKS_COUNT
+#define DTV_STAT_PRE_BIT_ERROR_COUNT	64
+#define DTV_STAT_PRE_TOTAL_BIT_COUNT	65
+#define DTV_STAT_POST_BIT_ERROR_COUNT	66
+#define DTV_STAT_POST_TOTAL_BIT_COUNT	67
+#define DTV_STAT_ERROR_BLOCK_COUNT	68
+#define DTV_STAT_TOTAL_BLOCK_COUNT	69
+
+#define DTV_MAX_COMMAND		DTV_STAT_TOTAL_BLOCK_COUNT
 
 typedef enum fe_pilot {
 	PILOT_ON,

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari]

On 01/23/2013 08:57 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 23 Jan 2013 16:18:01 -0200
> Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
>
>> I'll soon post patches 1 and 2 after those changes. The remaining 4 patches
>> don't likely need any change.
>
> Actually, it sounds better to just do a diff between the two versions.
> Each individual patch on v13 is at:
> 	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/stats_v13
>
> Cheers,
> Mauro
>
> v13:
> - Add post-Viterbi BER on the API
> - Some documentation adjustments as suggested by Antti
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

For all the DVB-core related statistics API changes in that patch serie:

Reviewed-by: Antti Palosaari <crope@iki.fi>


I have still one comment about naming:
DTV_STAT_PRE_BIT_ERROR_COUNT   => DTV_STAT_PRE_ERROR_BIT_COUNT
DTV_STAT_PRE_TOTAL_BIT_COUNT
DTV_STAT_POST_BIT_ERROR_COUNT  => DTV_STAT_POST_ERROR_BIT_COUNT
DTV_STAT_POST_TOTAL_BIT_COUNT
DTV_STAT_ERROR_BLOCK_COUNT
DTV_STAT_TOTAL_BLOCK_COUNT

I like to change those two. Anyway, if you think current naming is 
better then leave as it is.


>
> diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
> index 3f9f451..772314a 100644
> --- a/Documentation/DocBook/media/dvb/dvbproperty.xml
> +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
> @@ -467,7 +467,7 @@ typedef enum fe_delivery_system {
>   		<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
>   		<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
>   			ISDB-T hierarchical layers can be decoded simultaneously. For that
> -			reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
> +			reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
>   		<para>ISDB-T has 3 hierarchical layers which each can use a part of the
>   			available segments. The total number of segments over all layers has
>   			to 13 in ISDB-T.</para>
> @@ -933,24 +933,24 @@ enum fe_interleaving {
>   			<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
>   		</itemizedlist>
>   	</section>
> -	<section id="DTV-STAT-BIT-ERROR-COUNT">
> -		<title><constant>DTV_STAT_BIT_ERROR_COUNT</constant></title>
> -		<para>Measures the number of bit errors before Viterbi.</para>
> -		<para>This measure is taken during the same interval as <constant>DTV_STAT_TOTAL_BITS_COUNT</constant>.</para>
> +	<section id="DTV-STAT-PRE-BIT-ERROR-COUNT">
> +		<title><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></title>
> +		<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
> +		<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
>   		<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
> -		<link linkend="DTV-STAT-TOTAL-BITS-COUNT"><constant>DTV_STAT_TOTAL_BITS_COUNT</constant></link>.</para>
> +		<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
>   		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
>   		      The frontend may reset it when a channel/transponder is tuned.</para>
>   		<para>Possible scales for this metric are:</para>
>   		<itemizedlist mark='bullet'>
>   			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
> -			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before Viterbi.</listitem>
> +			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
>   		</itemizedlist>
>   	</section>
> -	<section id="DTV-STAT-TOTAL-BITS-COUNT">
> -		<title><constant>DTV_STAT_TOTAL_BITS_COUNT</constant></title>
> -		<para>Measures the amount of bits received before the Viterbi block, during the same period as
> -		<link linkend="DTV-STAT-BIT-ERROR-COUNT"><constant>DTV_STAT_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
> +	<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
> +		<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
> +		<para>Measures the amount of bits received before the inner code block, during the same period as
> +		<link linkend="DTV-STAT-PRE-BIT-ERROR-COUNT"><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
>   		<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
>   		      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
>   		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
> @@ -959,27 +959,56 @@ enum fe_interleaving {
>   		<itemizedlist mark='bullet'>
>   			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
>   			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
> -				 <link linkend="DTV-STAT-BIT-ERROR-COUNT"><constant>DTV_STAT_BIT_ERROR_COUNT</constant></link>.</listitem>
> +				 <link linkend="DTV-STAT-PRE-BIT-ERROR-COUNT"><constant>DTV_STAT_PRE_BIT_ERROR_COUNT</constant></link>.</listitem>
> +		</itemizedlist>
> +	</section>
> +	<section id="DTV-STAT-POST-BIT-ERROR-COUNT">
> +		<title><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></title>
> +		<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
> +		<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
> +		<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
> +		<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
> +		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
> +		      The frontend may reset it when a channel/transponder is tuned.</para>
> +		<para>Possible scales for this metric are:</para>
> +		<itemizedlist mark='bullet'>
> +			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
> +			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
> +		</itemizedlist>
> +	</section>
> +	<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
> +		<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
> +		<para>Measures the amount of bits received after the inner coding, during the same period as
> +		<link linkend="DTV-STAT-POST-BIT-ERROR-COUNT"><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></link> measurement was taken.</para>
> +		<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
> +		      as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
> +		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
> +		      The frontend may reset it when a channel/transponder is tuned.</para>
> +		<para>Possible scales for this metric are:</para>
> +		<itemizedlist mark='bullet'>
> +			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
> +			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
> +				 <link linkend="DTV-STAT-POST-BIT-ERROR-COUNT"><constant>DTV_STAT_POST_BIT_ERROR_COUNT</constant></link>.</listitem>
>   		</itemizedlist>
>   	</section>
>   	<section id="DTV-STAT-ERROR-BLOCK-COUNT">
>   		<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
> -		<para>Measures the number of block errors.</para>
> +		<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
>   		<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
>   		      The frontend may reset it when a channel/transponder is tuned.</para>
>   		<para>Possible scales for this metric are:</para>
>   		<itemizedlist mark='bullet'>
>   			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
> -			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after Red Salomon.</listitem>
> +			<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
>   		</itemizedlist>
>   	</section>
> -	<section id="DTV-STAT-TOTAL-BLOCKS-COUNT">
> -		<title><constant>DTV-STAT_TOTAL_BLOCKS_COUNT</constant></title>
> +	<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
> +		<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
>   		<para>Measures the total number of blocks received during the same period as
>   		<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
>   		<para>It can be used to calculate the PER indicator, by dividing
>   		<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
> -		by <link linkend="DTV-STAT-TOTAL-BLOCKS-COUNT"><constant>DTV-STAT-TOTAL-BLOCKS-COUNT</constant></link>.</para>
> +		by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
>   		<para>Possible scales for this metric are:</para>
>   		<itemizedlist mark='bullet'>
>   			<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
> diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
> index 426c252..df39ba3 100644
> --- a/Documentation/DocBook/media/dvb/frontend.xml
> +++ b/Documentation/DocBook/media/dvb/frontend.xml
> @@ -230,7 +230,7 @@ typedef enum fe_status {
>   <entry align="char">The frontend has found a DVB signal</entry>
>   </row><row>
>   <entry align="char">FE_HAS_VITERBI</entry>
> -<entry align="char">The frontend FEC code is stable</entry>
> +<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
>   </row><row>
>   <entry align="char">FE_HAS_SYNC</entry>
>   <entry align="char">Syncronization bytes was found</entry>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
> index 66be7f7..f8943c2 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1057,10 +1057,12 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
>   	/* Statistics API */
>   	_DTV_CMD(DTV_STAT_SIGNAL_STRENGTH, 0, 0),
>   	_DTV_CMD(DTV_STAT_CNR, 0, 0),
> -	_DTV_CMD(DTV_STAT_BIT_ERROR_COUNT, 0, 0),
> -	_DTV_CMD(DTV_STAT_TOTAL_BITS_COUNT, 0, 0),
> +	_DTV_CMD(DTV_STAT_PRE_BIT_ERROR_COUNT, 0, 0),
> +	_DTV_CMD(DTV_STAT_PRE_TOTAL_BIT_COUNT, 0, 0),
> +	_DTV_CMD(DTV_STAT_POST_BIT_ERROR_COUNT, 0, 0),
> +	_DTV_CMD(DTV_STAT_POST_TOTAL_BIT_COUNT, 0, 0),
>   	_DTV_CMD(DTV_STAT_ERROR_BLOCK_COUNT, 0, 0),
> -	_DTV_CMD(DTV_STAT_TOTAL_BLOCKS_COUNT, 0, 0),
> +	_DTV_CMD(DTV_STAT_TOTAL_BLOCK_COUNT, 0, 0),
>   };
>
>   static void dtv_property_dump(struct dvb_frontend *fe, struct dtv_property *tvp)
> @@ -1458,16 +1460,22 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
>   	case DTV_STAT_CNR:
>   		tvp->u.st = c->cnr;
>   		break;
> -	case DTV_STAT_BIT_ERROR_COUNT:
> -		tvp->u.st = c->bit_error;
> +	case DTV_STAT_PRE_BIT_ERROR_COUNT:
> +		tvp->u.st = c->pre_bit_error;
>   		break;
> -	case DTV_STAT_TOTAL_BITS_COUNT:
> -		tvp->u.st = c->bit_count;
> +	case DTV_STAT_PRE_TOTAL_BIT_COUNT:
> +		tvp->u.st = c->pre_bit_count;
> +		break;
> +	case DTV_STAT_POST_BIT_ERROR_COUNT:
> +		tvp->u.st = c->post_bit_error;
> +		break;
> +	case DTV_STAT_POST_TOTAL_BIT_COUNT:
> +		tvp->u.st = c->post_bit_count;
>   		break;
>   	case DTV_STAT_ERROR_BLOCK_COUNT:
>   		tvp->u.st = c->block_error;
>   		break;
> -	case DTV_STAT_TOTAL_BLOCKS_COUNT:
> +	case DTV_STAT_TOTAL_BLOCK_COUNT:
>   		tvp->u.st = c->block_count;
>   		break;
>   	default:
> diff --git a/drivers/media/dvb-core/dvb_frontend.h b/drivers/media/dvb-core/dvb_frontend.h
> index 47952c5..b34922a 100644
> --- a/drivers/media/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb-core/dvb_frontend.h
> @@ -397,8 +397,10 @@ struct dtv_frontend_properties {
>   	/* statistics data */
>   	struct dtv_fe_stats	strength;
>   	struct dtv_fe_stats	cnr;
> -	struct dtv_fe_stats	bit_error;
> -	struct dtv_fe_stats	bit_count;
> +	struct dtv_fe_stats	pre_bit_error;
> +	struct dtv_fe_stats	pre_bit_count;
> +	struct dtv_fe_stats	post_bit_error;
> +	struct dtv_fe_stats	post_bit_count;
>   	struct dtv_fe_stats	block_error;
>   	struct dtv_fe_stats	block_count;
>   };
> diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
> index 56a027c..4f3e222 100644
> --- a/drivers/media/dvb-frontends/mb86a20s.c
> +++ b/drivers/media/dvb-frontends/mb86a20s.c
> @@ -721,8 +721,8 @@ static int mb86a20s_reset_counters(struct dvb_frontend *fe)
>   	if (state->last_frequency != c->frequency) {
>   		memset(&c->strength, 0, sizeof(c->strength));
>   		memset(&c->cnr, 0, sizeof(c->cnr));
> -		memset(&c->bit_error, 0, sizeof(c->bit_error));
> -		memset(&c->bit_count, 0, sizeof(c->bit_count));
> +		memset(&c->pre_bit_error, 0, sizeof(c->pre_bit_error));
> +		memset(&c->pre_bit_count, 0, sizeof(c->pre_bit_count));
>   		memset(&c->block_error, 0, sizeof(c->block_error));
>   		memset(&c->block_count, 0, sizeof(c->block_count));
>
> @@ -1232,8 +1232,8 @@ static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
>
>   	/* Per-layer stats - 3 layers + global */
>   	c->cnr.len = 4;
> -	c->bit_error.len = 4;
> -	c->bit_count.len = 4;
> +	c->pre_bit_error.len = 4;
> +	c->pre_bit_count.len = 4;
>   	c->block_error.len = 4;
>   	c->block_count.len = 4;
>
> @@ -1244,8 +1244,8 @@ static void mb86a20s_stats_not_ready(struct dvb_frontend *fe)
>   	/* Put all of them at FE_SCALE_NOT_AVAILABLE */
>   	for (i = 0; i < 4; i++) {
>   		c->cnr.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
> -		c->bit_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
> -		c->bit_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
> +		c->pre_bit_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
> +		c->pre_bit_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
>   		c->block_error.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
>   		c->block_count.stat[i].scale = FE_SCALE_NOT_AVAILABLE;
>   	}
> @@ -1257,7 +1257,7 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
>   	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
>   	int rc = 0, i;
>   	u32 bit_error = 0, bit_count = 0;
> -	u32 t_bit_error = 0, t_bit_count = 0;
> +	u32 t_pre_bit_error = 0, t_pre_bit_count = 0;
>   	int active_layers = 0, ber_layers = 0;
>
>   	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
> @@ -1278,17 +1278,17 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
>   							&bit_error,
>   							&bit_count);
>   			if (rc >= 0) {
> -				c->bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
> -				c->bit_error.stat[1 + i].uvalue += bit_error;
> -				c->bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
> -				c->bit_count.stat[1 + i].uvalue += bit_count;
> +				c->pre_bit_error.stat[1 + i].scale = FE_SCALE_COUNTER;
> +				c->pre_bit_error.stat[1 + i].uvalue += bit_error;
> +				c->pre_bit_count.stat[1 + i].scale = FE_SCALE_COUNTER;
> +				c->pre_bit_count.stat[1 + i].uvalue += bit_count;
>   			} else if (rc != -EBUSY) {
>   				/*
>   					* If an I/O error happened,
>   					* measures are now unavailable
>   					*/
> -				c->bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
> -				c->bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
> +				c->pre_bit_error.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
> +				c->pre_bit_count.stat[1 + i].scale = FE_SCALE_NOT_AVAILABLE;
>   				dev_err(&state->i2c->dev,
>   					"%s: Can't get BER for layer %c (error %d).\n",
>   					__func__, 'A' + i, rc);
> @@ -1298,8 +1298,8 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
>   				ber_layers++;
>
>   			/* Update total BER */
> -			t_bit_error += c->bit_error.stat[1 + i].uvalue;
> -			t_bit_count += c->bit_count.stat[1 + i].uvalue;
> +			t_pre_bit_error += c->pre_bit_error.stat[1 + i].uvalue;
> +			t_pre_bit_count += c->pre_bit_count.stat[1 + i].uvalue;
>   		}
>   	}
>
> @@ -1315,10 +1315,10 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
>   		 * Total Bit Error/Count is calculated as the sum of the
>   		 * bit errors on all active layers.
>   		 */
> -		c->bit_error.stat[0].scale = FE_SCALE_COUNTER;
> -		c->bit_error.stat[0].uvalue = t_bit_error;
> -		c->bit_count.stat[0].scale = FE_SCALE_COUNTER;
> -		c->bit_count.stat[0].uvalue = t_bit_count;
> +		c->pre_bit_error.stat[0].scale = FE_SCALE_COUNTER;
> +		c->pre_bit_error.stat[0].uvalue = t_pre_bit_error;
> +		c->pre_bit_count.stat[0].scale = FE_SCALE_COUNTER;
> +		c->pre_bit_count.stat[0].uvalue = t_pre_bit_count;
>   	}
>
>   	return rc;
> @@ -1544,12 +1544,12 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
>   	struct mb86a20s_state *state;
>   	u8	rev;
>
> +	dev_dbg(&i2c->dev, "%s called.\n", __func__);
> +
>   	/* allocate memory for the internal state */
>   	state = kzalloc(sizeof(struct mb86a20s_state), GFP_KERNEL);
> -
> -	dev_dbg(&state->i2c->dev, "%s called.\n", __func__);
>   	if (state == NULL) {
> -		dev_err(&state->i2c->dev,
> +		dev_err(&i2c->dev,
>   			"%s: unable to allocate memory for state\n", __func__);
>   		goto error;
>   	}
> @@ -1567,10 +1567,10 @@ struct dvb_frontend *mb86a20s_attach(const struct mb86a20s_config *config,
>   	rev = mb86a20s_readreg(state, 0);
>
>   	if (rev == 0x13) {
> -		dev_info(&state->i2c->dev,
> +		dev_info(&i2c->dev,
>   			 "Detected a Fujitsu mb86a20s frontend\n");
>   	} else {
> -		dev_dbg(&state->i2c->dev,
> +		dev_dbg(&i2c->dev,
>   			"Frontend revision %d is unknown - aborting.\n",
>   		       rev);
>   		goto error;
> diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h
> index 0cd62bd..1913a36 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -368,12 +368,14 @@ struct dvb_frontend_event {
>   /* Quality parameters */
>   #define DTV_STAT_SIGNAL_STRENGTH	62
>   #define DTV_STAT_CNR			63
> -#define DTV_STAT_BIT_ERROR_COUNT	64
> -#define DTV_STAT_TOTAL_BITS_COUNT	65
> -#define DTV_STAT_ERROR_BLOCK_COUNT	66
> -#define DTV_STAT_TOTAL_BLOCKS_COUNT	67
> -
> -#define DTV_MAX_COMMAND		DTV_STAT_TOTAL_BLOCKS_COUNT
> +#define DTV_STAT_PRE_BIT_ERROR_COUNT	64
> +#define DTV_STAT_PRE_TOTAL_BIT_COUNT	65
> +#define DTV_STAT_POST_BIT_ERROR_COUNT	66
> +#define DTV_STAT_POST_TOTAL_BIT_COUNT	67
> +#define DTV_STAT_ERROR_BLOCK_COUNT	68
> +#define DTV_STAT_TOTAL_BLOCK_COUNT	69
> +
> +#define DTV_MAX_COMMAND		DTV_STAT_TOTAL_BLOCK_COUNT
>
>   typedef enum fe_pilot {
>   	PILOT_ON,
>


-- 
http://palosaari.fi/

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 23 Jan 2013 21:55:00 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 01/23/2013 08:57 PM, Mauro Carvalho Chehab wrote:
> > Em Wed, 23 Jan 2013 16:18:01 -0200
> > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> >
> >> I'll soon post patches 1 and 2 after those changes. The remaining 4 patches
> >> don't likely need any change.
> >
> > Actually, it sounds better to just do a diff between the two versions.
> > Each individual patch on v13 is at:
> > 	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/stats_v13
> >
> > Cheers,
> > Mauro
> >
> > v13:
> > - Add post-Viterbi BER on the API
> > - Some documentation adjustments as suggested by Antti
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> For all the DVB-core related statistics API changes in that patch serie:
> 
> Reviewed-by: Antti Palosaari <crope@iki.fi>

Thanks!
> 
> 
> I have still one comment about naming:
> DTV_STAT_PRE_BIT_ERROR_COUNT   => DTV_STAT_PRE_ERROR_BIT_COUNT
> DTV_STAT_PRE_TOTAL_BIT_COUNT
> DTV_STAT_POST_BIT_ERROR_COUNT  => DTV_STAT_POST_ERROR_BIT_COUNT
> DTV_STAT_POST_TOTAL_BIT_COUNT
> DTV_STAT_ERROR_BLOCK_COUNT
> DTV_STAT_TOTAL_BLOCK_COUNT
> 
> I like to change those two. Anyway, if you think current naming is 
> better then leave as it is.

Works for me.

-- 

Cheers,
Mauro

Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Mauro Carvalho Chehab]

Em Wed, 23 Jan 2013 19:00:11 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Wed, 23 Jan 2013 21:55:00 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
> 
> > On 01/23/2013 08:57 PM, Mauro Carvalho Chehab wrote:
> > > Em Wed, 23 Jan 2013 16:18:01 -0200
> > > Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> > >
> > >> I'll soon post patches 1 and 2 after those changes. The remaining 4 patches
> > >> don't likely need any change.
> > >
> > > Actually, it sounds better to just do a diff between the two versions.
> > > Each individual patch on v13 is at:
> > > 	http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/stats_v13
> > >
> > > Cheers,
> > > Mauro
> > >
> > > v13:
> > > - Add post-Viterbi BER on the API
> > > - Some documentation adjustments as suggested by Antti
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> > 
> > For all the DVB-core related statistics API changes in that patch serie:
> > 
> > Reviewed-by: Antti Palosaari <crope@iki.fi>
> 
> Thanks!
> > 
> > 
> > I have still one comment about naming:
> > DTV_STAT_PRE_BIT_ERROR_COUNT   => DTV_STAT_PRE_ERROR_BIT_COUNT
> > DTV_STAT_PRE_TOTAL_BIT_COUNT
> > DTV_STAT_POST_BIT_ERROR_COUNT  => DTV_STAT_POST_ERROR_BIT_COUNT
> > DTV_STAT_POST_TOTAL_BIT_COUNT
> > DTV_STAT_ERROR_BLOCK_COUNT
> > DTV_STAT_TOTAL_BLOCK_COUNT
> > 
> > I like to change those two. Anyway, if you think current naming is 
> > better then leave as it is.
> 
> Works for me.

Ok, statistics patches merged at the development tree. The next step,
on Kernelspace, is to gradually add DVBv5.10 statistics support on the
existing frontends.

I also merged the dvbv5-tools patches at:
	http://git.linuxtv.org/v4l-utils.git

The new code there is currently being called only for dvbv5-zap, although
it should be easy to make it to work with dvbv5-scan, as the statistics
code is part of the library. 

There's also a "quality" statistics there in the library,
calculated on userspace:
	http://git.linuxtv.org/v4l-utils.git/commitdiff/d7237c75d9e507ebd51666248dca18feeee8d814

This way, its policy can be easily changed/fixed.

When time permits and after having some confidence about the quality calculus,
My plan is to change the code at the userspace tools to only display,
by default, DVB FE status, strength and (per layer) quality, and to add
an extra option to allow displaying all available stats if the user wants to.

I should also add the same stats code later to dvbv5-scan.

It should be noticed that the quality statistics there are very experimental, 
as I was not able to research for the quality criteria that apply to all DVB
standards.

As one may know, there are actually 3 probability density functions (p. d. f.)
commonly used to describe how the signal to noise ratio interferes on a given 
radio signal: Gaussian, Rician and Raileigh fading, being the last ones typically
closer to real life. The DVB specs define channels in function of all those
three distros. There are, of course, other stochastic models that provide 
different values for the quality, in function of the S/N ratio.

For the quality metrics on terrestrial delivery systems, I based the policy
on both ETSI DVB and ABNT ISDB terrestrial specs, in a way that "Good" means
a Quasi Error Free channel with Raileigh fading[1], e. g. there's no line
of sight signal. On such channels, the S/N ratio should be bigger than on
the other two p. d. f. 

Also, for DVB, the "OK" quality is matching the minimum S/N ratio for the
the Rician fading distribution, e. g., if there is a line of sight signal
that it is stronger than the reflected ones, signal="OK" actually means
a good signal. A more precise application would need to "calibrate" the
quality statistics between Rician and Raileigh distributions, either
if there's a direct sight signal or not.

If available, if BER or PER measures are also taken into account for
the quality statistics, e. g., the signal indicator can
change from "good" to "OK" or "poor" if there are too much errors. 
For now, due to the lack of time to do more research, I just did an 
educated guess for the expected value for parameters, but I'm sure 
that there are plenty of space for improvements.

It should be said that, in practice, the signal can behave different than
either Raileigh or Rician fading. So, the measure just give a rough idea
about the signal quality.

Anyway, patches fixing/improving it are very welcome.

-- 

[1] http://en.wikipedia.org/wiki/Rician_fading

Cheers,
Mauro