* [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 0:25 [PATCH RFCv9 0/4] DVB QoS statistics API Mauro Carvalho Chehab
@ 2013-01-08 0:25 ` Mauro Carvalho Chehab
2013-01-08 11:45 ` Simon Farnsworth
2013-01-08 12:33 ` Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 2/4] dvb: the core logic to handle the DVBv5 QoS properties Mauro Carvalho Chehab
` (2 subsequent siblings)
3 siblings, 2 replies; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 0:25 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List
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
---
Documentation/DocBook/media/dvb/dvbproperty.xml | 97 ++++++++++++++++++++++++-
include/uapi/linux/dvb/frontend.h | 84 ++++++++++++++++++++-
2 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 957e3ac..9168808 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -7,16 +7,29 @@ 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 {
+ __u16 value;
+ __u8 scale;
+} __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;
union {
__u32 data;
struct {
- __u8 data[32];
+ union {
+ __u8 data[32];
+ __u16 data[16];
+ }
__u32 len;
__u32 reserved1[3];
void *reserved2;
@@ -850,6 +863,78 @@ 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>
+ </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 +956,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 +981,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 +1035,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 +1049,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 +1077,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 +1097,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 +1119,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 +1135,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 +1155,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 +1171,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..39e3321 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,84 @@ 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,
+ 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 {
+ __u32 uvalue; /* for counters and relative scales */
+ __s32 svalue; /* for 0.1 dB measures */
+ };
+} __attribute__ ((packed));
+
+
+#define MAX_QOS_STATS 4
+
+struct dtv_fe_stats {
+ __u8 len;
+ __u8 scale;
+ 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
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 0:25 ` [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service Mauro Carvalho Chehab
@ 2013-01-08 11:45 ` Simon Farnsworth
2013-01-08 18:00 ` Frank Schäfer
2013-01-08 12:33 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 15+ messages in thread
From: Simon Farnsworth @ 2013-01-08 11:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Media Mailing List
On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote:
<snip>
> + <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>
<snip>
> + <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>
> + </section>
Signal strength is traditionally an absolute field strength; there's no way in
this API for me to provide my reference point, so two different front ends
could represent the same signal strength as "0 dB" (where the reference point
is one microwatt), "-30 dB" (where the reference point is one milliwatt), or
"17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance).
Could you choose a reference point for signal strength, and specify that if
you're using FE_SCALE_DECIBEL, you're referenced against that point?
My preference would be to reference against 1 microwatt, as (on the DVB-T and
ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got
perfect signal, negative number if your signal is weak, and positive numbers
if your signal is strong. However, referenced against 1 milliwatt also works
well for me, as the conversion is trivial.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 11:45 ` Simon Farnsworth
@ 2013-01-08 18:00 ` Frank Schäfer
2013-01-08 23:18 ` Simon Farnsworth
0 siblings, 1 reply; 15+ messages in thread
From: Frank Schäfer @ 2013-01-08 18:00 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Simon Farnsworth, Linux Media Mailing List
Am 08.01.2013 12:45, schrieb Simon Farnsworth:
> On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote:
> <snip>
>> + <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>
> <snip>
>> + <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>
>> + </section>
> Signal strength is traditionally an absolute field strength; there's no way in
> this API for me to provide my reference point, so two different front ends
> could represent the same signal strength as "0 dB" (where the reference point
> is one microwatt), "-30 dB" (where the reference point is one milliwatt), or
> "17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance).
>
> Could you choose a reference point for signal strength, and specify that if
> you're using FE_SCALE_DECIBEL, you're referenced against that point?
>
> My preference would be to reference against 1 microwatt, as (on the DVB-T and
> ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got
> perfect signal, negative number if your signal is weak, and positive numbers
> if your signal is strong. However, referenced against 1 milliwatt also works
> well for me, as the conversion is trivial.
Yeah, that's one of the most popular mistakes in the technical world.
Decibel is a relative unit. X dB says nothing about the absolute value
without a reference value.
Hence these reference values must be specified in the document.
Otherwise the reported signal strengths are meaningless / not comparable.
It might be worth to take a look at what the wireles network people have
done.
IIRC, they had the same discussion about signal strength reporting a
(longer) while ago.
Just my two cents.
Regards,
Frank
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 18:00 ` Frank Schäfer
@ 2013-01-08 23:18 ` Simon Farnsworth
2013-01-08 23:28 ` Devin Heitmueller
0 siblings, 1 reply; 15+ messages in thread
From: Simon Farnsworth @ 2013-01-08 23:18 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Mauro Carvalho Chehab, Linux Media Mailing List
On Tuesday 8 January 2013 19:00:11 Frank Schäfer wrote:
> Am 08.01.2013 12:45, schrieb Simon Farnsworth:
> > On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote:
> > <snip>
> >> + <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>
> > <snip>
> >> + <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>
> >> + </section>
> > Signal strength is traditionally an absolute field strength; there's no way in
> > this API for me to provide my reference point, so two different front ends
> > could represent the same signal strength as "0 dB" (where the reference point
> > is one microwatt), "-30 dB" (where the reference point is one milliwatt), or
> > "17 dB" (using a reference point of 1 millivolt on a 50 ohm impedance).
> >
> > Could you choose a reference point for signal strength, and specify that if
> > you're using FE_SCALE_DECIBEL, you're referenced against that point?
> >
> > My preference would be to reference against 1 microwatt, as (on the DVB-T and
> > ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got
> > perfect signal, negative number if your signal is weak, and positive numbers
> > if your signal is strong. However, referenced against 1 milliwatt also works
> > well for me, as the conversion is trivial.
>
> Yeah, that's one of the most popular mistakes in the technical world.
> Decibel is a relative unit. X dB says nothing about the absolute value
> without a reference value.
> Hence these reference values must be specified in the document.
> Otherwise the reported signal strengths are meaningless / not comparable.
>
> It might be worth to take a look at what the wireles network people have
> done.
> IIRC, they had the same discussion about signal strength reporting a
> (longer) while ago.
>
The wireless folk use dBm (reference point 1 milliwatt), as that's the
reference point used in the 802.11 standard.
Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
point (so suitable for carrier to noise etc, or for when the reference point
is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
1mW, so that frontends report in dBm?
Note that if the frontend internally uses a different reference point, the
conversion is always going to be adding or subtracting a constant.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 23:18 ` Simon Farnsworth
@ 2013-01-08 23:28 ` Devin Heitmueller
2013-01-09 11:02 ` Simon Farnsworth
0 siblings, 1 reply; 15+ messages in thread
From: Devin Heitmueller @ 2013-01-08 23:28 UTC (permalink / raw)
To: Simon Farnsworth
Cc: Frank Schäfer, Mauro Carvalho Chehab,
Linux Media Mailing List
On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
<simon.farnsworth@onelan.com> wrote:
> The wireless folk use dBm (reference point 1 milliwatt), as that's the
> reference point used in the 802.11 standard.
>
> Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
> point (so suitable for carrier to noise etc, or for when the reference point
> is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
> 1mW, so that frontends report in dBm?
>
> Note that if the frontend internally uses a different reference point, the
> conversion is always going to be adding or subtracting a constant.
Hi Simon,
Probably the biggest issue you're going to have is that very few of
the consumer-grade demodulators actually report data in that format.
And only a small subset of those actually provide the documentation in
their datasheet.
The goal behind the "strength" indicator is to provide a field even an
idiot can understand. While I appreciate the desire to be able to
access the data in it's an "advanced" format, in reality the number of
demodulator drivers that would actually be able to report such is very
small -- and the approach prevents a "lowest common denominator",
which is what 99% of the users *actually* care about.
For that matter, even the SNR field being reported in dB isn't going
to allow you to reliably compare across different demodulator chips.
If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't
*really* mean demod Y performs better - just that it's reporting a
better number. However it *does* allow you to compare the demod
against itself either across multiple frequencies or under different
signal conditions - which is what typical users really care about.
And while I realize in your case, Simon, that your requirements may be
different from typical consumer-grade applications, I worry that
adding yet more complexity to the solution will just result in getting
*NOTHING*, as we have for all these years every time the issue of
signal statistics has been raised.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 23:28 ` Devin Heitmueller
@ 2013-01-09 11:02 ` Simon Farnsworth
2013-01-09 15:24 ` Mauro Carvalho Chehab
2013-01-13 13:30 ` [linux-media] " Klaus Schmidinger
0 siblings, 2 replies; 15+ messages in thread
From: Simon Farnsworth @ 2013-01-09 11:02 UTC (permalink / raw)
To: Devin Heitmueller
Cc: Frank Schäfer, Mauro Carvalho Chehab,
Linux Media Mailing List
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote:
> On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
> <simon.farnsworth@onelan.com> wrote:
> > The wireless folk use dBm (reference point 1 milliwatt), as that's the
> > reference point used in the 802.11 standard.
> >
> > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
> > point (so suitable for carrier to noise etc, or for when the reference point
> > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
> > 1mW, so that frontends report in dBm?
> >
> > Note that if the frontend internally uses a different reference point, the
> > conversion is always going to be adding or subtracting a constant.
>
> Hi Simon,
>
> Probably the biggest issue you're going to have is that very few of
> the consumer-grade demodulators actually report data in that format.
> And only a small subset of those actually provide the documentation in
> their datasheet.
>
<snip>
My specific concern is that we already see people complaining that their cable
system or aerial installer's meter comes up with one number, and our
documentation has completely different numbers. When we dig, this usually
turns out to be because our documentation is in dBm, while their installer is
using dBmV or dBµW, and no-one at the customer site knows the differences.
If consumer demods don't report in a dB scale at all, we should drop dB as a
unit; if they do report in a true dB scale, but the reference point is
normally not documented, we need some way to distinguish demods where the
reference point is unknown, and demods where someone has taken the time to
find the reference point (which can be done with a signal generator).
This is sounding more and more like an argument for adding
FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to
tell the user that the signal strength reading from the application should
match up to the signal strength reading on your installer's kit. Said
applications could even choose to do the conversions for you, giving you all
four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW).
> For that matter, even the SNR field being reported in dB isn't going
> to allow you to reliably compare across different demodulator chips.
> If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't
> really mean demod Y performs better - just that it's reporting a
> better number. However it does allow you to compare the demod
> against itself either across multiple frequencies or under different
> signal conditions - which is what typical users really care about.
I'm not expecting people to compare across demods - I only care about the
case where a user has got in a professional installer to help with their
setup. The problem I want to avoid is a Linux application saying "-48 dB
signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal
strength, 20 dB CNR", when we have enough information for the Linux
application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the
professional to remember that not all dB use the same reference point, and
from there into accepting that Linux is reporting a similar signal strength
and CNR to his kit.
This also has implications for things like VDR - if the scale is
FE_SCALE_DECIBEL but the measurement is absolute, the application probably
doesn't want to report the measurement as a dB measure, but as an arbitrary
scale; again, you don't want the application saying "50 dB", when the
professional installer tells you that you have "0 dBuV".
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-09 11:02 ` Simon Farnsworth
@ 2013-01-09 15:24 ` Mauro Carvalho Chehab
2013-01-10 10:19 ` Simon Farnsworth
2013-01-13 13:30 ` [linux-media] " Klaus Schmidinger
1 sibling, 1 reply; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-09 15:24 UTC (permalink / raw)
To: Simon Farnsworth
Cc: Devin Heitmueller, Frank Schäfer, Linux Media Mailing List
Em Wed, 09 Jan 2013 11:02:23 +0000
Simon Farnsworth <simon.farnsworth@onelan.com> escreveu:
> On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote:
> > On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
> > <simon.farnsworth@onelan.com> wrote:
> > > The wireless folk use dBm (reference point 1 milliwatt), as that's the
> > > reference point used in the 802.11 standard.
> > >
> > > Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
> > > point (so suitable for carrier to noise etc, or for when the reference point
> > > is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
> > > 1mW, so that frontends report in dBm?
> > >
> > > Note that if the frontend internally uses a different reference point, the
> > > conversion is always going to be adding or subtracting a constant.
> >
> > Hi Simon,
> >
> > Probably the biggest issue you're going to have is that very few of
> > the consumer-grade demodulators actually report data in that format.
> > And only a small subset of those actually provide the documentation in
> > their datasheet.
> >
> <snip>
> My specific concern is that we already see people complaining that their cable
> system or aerial installer's meter comes up with one number, and our
> documentation has completely different numbers. When we dig, this usually
> turns out to be because our documentation is in dBm, while their installer is
> using dBmV or dBµW, and no-one at the customer site knows the differences.
>
> If consumer demods don't report in a dB scale at all, we should drop dB as a
> unit; if they do report in a true dB scale, but the reference point is
> normally not documented, we need some way to distinguish demods where the
> reference point is unknown, and demods where someone has taken the time to
> find the reference point (which can be done with a signal generator).
>
> This is sounding more and more like an argument for adding
> FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to
> tell the user that the signal strength reading from the application should
> match up to the signal strength reading on your installer's kit. Said
> applications could even choose to do the conversions for you, giving you all
> four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW).
>
> > For that matter, even the SNR field being reported in dB isn't going
> > to allow you to reliably compare across different demodulator chips.
> > If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't
> > really mean demod Y performs better - just that it's reporting a
> > better number. However it does allow you to compare the demod
> > against itself either across multiple frequencies or under different
> > signal conditions - which is what typical users really care about.
>
> I'm not expecting people to compare across demods - I only care about the
> case where a user has got in a professional installer to help with their
> setup. The problem I want to avoid is a Linux application saying "-48 dB
> signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal
> strength, 20 dB CNR", when we have enough information for the Linux
> application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the
> professional to remember that not all dB use the same reference point, and
> from there into accepting that Linux is reporting a similar signal strength
> and CNR to his kit.
>
> This also has implications for things like VDR - if the scale is
> FE_SCALE_DECIBEL but the measurement is absolute, the application probably
> doesn't want to report the measurement as a dB measure, but as an arbitrary
> scale; again, you don't want the application saying "50 dB", when the
> professional installer tells you that you have "0 dBuV".
Yes, it makes sense to document that the signal strength should be reported
on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify
it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as
different Countries use different impedances on DTV cabling (typically,
50Ω or 75Ω).
So, either dBm or dBµW works for me. As you said, applications can convert
between those mesures as they wish, by simply adding some constant when
displaying the power measure.
As the wifi subsytem use dBm, I vote for using dBm for the signal measure
at the subsystem (actually, 0.1 dBm).
Comments?
Regards,
Mauro
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-09 15:24 ` Mauro Carvalho Chehab
@ 2013-01-10 10:19 ` Simon Farnsworth
0 siblings, 0 replies; 15+ messages in thread
From: Simon Farnsworth @ 2013-01-10 10:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Devin Heitmueller, Frank Schäfer, Linux Media Mailing List
On Wednesday 9 January 2013 13:24:25 Mauro Carvalho Chehab wrote:
<snip>
> Yes, it makes sense to document that the signal strength should be reported
> on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify
> it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as
> different Countries use different impedances on DTV cabling (typically,
> 50Ω or 75Ω).
>
> So, either dBm or dBµW works for me. As you said, applications can convert
> between those mesures as they wish, by simply adding some constant when
> displaying the power measure.
>
> As the wifi subsytem use dBm, I vote for using dBm for the signal measure
> at the subsystem (actually, 0.1 dBm).
>
0.1 dBm suits me. I just want something that I can present to the end user in
a format that will match their aerial installer's kit.
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [linux-media] Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-09 11:02 ` Simon Farnsworth
2013-01-09 15:24 ` Mauro Carvalho Chehab
@ 2013-01-13 13:30 ` Klaus Schmidinger
1 sibling, 0 replies; 15+ messages in thread
From: Klaus Schmidinger @ 2013-01-13 13:30 UTC (permalink / raw)
To: linux-media
On 09.01.2013 12:02, Simon Farnsworth wrote:
> On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote:
>> On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth
>> <simon.farnsworth@onelan.com> wrote:
>>> The wireless folk use dBm (reference point 1 milliwatt), as that's the
>>> reference point used in the 802.11 standard.
>>>
>>> Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference
>>> point (so suitable for carrier to noise etc, or for when the reference point
>>> is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is
>>> 1mW, so that frontends report in dBm?
>>>
>>> Note that if the frontend internally uses a different reference point, the
>>> conversion is always going to be adding or subtracting a constant.
>>
>> Hi Simon,
>>
>> Probably the biggest issue you're going to have is that very few of
>> the consumer-grade demodulators actually report data in that format.
>> And only a small subset of those actually provide the documentation in
>> their datasheet.
>>
> <snip>
> My specific concern is that we already see people complaining that their cable
> system or aerial installer's meter comes up with one number, and our
> documentation has completely different numbers. When we dig, this usually
> turns out to be because our documentation is in dBm, while their installer is
> using dBmV or dBµW, and no-one at the customer site knows the differences.
>
> If consumer demods don't report in a dB scale at all, we should drop dB as a
> unit; if they do report in a true dB scale, but the reference point is
> normally not documented, we need some way to distinguish demods where the
> reference point is unknown, and demods where someone has taken the time to
> find the reference point (which can be done with a signal generator).
>
> This is sounding more and more like an argument for adding
> FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to
> tell the user that the signal strength reading from the application should
> match up to the signal strength reading on your installer's kit. Said
> applications could even choose to do the conversions for you, giving you all
> four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW).
>
>> For that matter, even the SNR field being reported in dB isn't going
>> to allow you to reliably compare across different demodulator chips.
>> If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't
>> really mean demod Y performs better - just that it's reporting a
>> better number. However it does allow you to compare the demod
>> against itself either across multiple frequencies or under different
>> signal conditions - which is what typical users really care about.
>
> I'm not expecting people to compare across demods - I only care about the
> case where a user has got in a professional installer to help with their
> setup. The problem I want to avoid is a Linux application saying "-48 dB
> signal strength, 15 dB CNR", and the installer's kit saying "60 dBuV signal
> strength, 20 dB CNR", when we have enough information for the Linux
> application to say "-48 dBm (60 dBuV at 75Ω), 15 dB CNR", cueing the
> professional to remember that not all dB use the same reference point, and
> from there into accepting that Linux is reporting a similar signal strength
> and CNR to his kit.
>
> This also has implications for things like VDR - if the scale is
> FE_SCALE_DECIBEL but the measurement is absolute, the application probably
> doesn't want to report the measurement as a dB measure, but as an arbitrary
> scale; again, you don't want the application saying "50 dB", when the
> professional installer tells you that you have "0 dBuV".
Actually VDR doesn't care about "dB", "dBuV", "dBuW" or whatever. All it wants
to do is to display the signal strength and quality in a way that, as Devin stated
so very appropriately, even an idiot can understand ;-)
VDR displays a bar that goes from 0 ("no signal at all") to full extent ("perfect
signal"). So for VDR any value range that can be linearly converted to a range
between 0% and 100% would do just fine. The only important thing is that it is
the *same* for all frontends! Ideally I would expect values in the range 0x0000
thru 0xFFFF.
Klaus
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
2013-01-08 0:25 ` [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service Mauro Carvalho Chehab
2013-01-08 11:45 ` Simon Farnsworth
@ 2013-01-08 12:33 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 12:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List
Em Mon, 7 Jan 2013 22:25:47 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> 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>
>
...
> +struct dtv_stats {
> + __u8 scale; /* enum fecap_scale_params type */
> + union {
> + __u32 uvalue; /* for counters and relative scales */
> + __s32 svalue; /* for 0.1 dB measures */
32 bits for total bit count is not enough, as it can be truncated too
early (~1 seg on ISDB-T, ~0.5 seg on DVB-C). I think we need to use
64 bits here, and put at the API that the drivers should monotonically
increment.
As struct buffer inside struct dtv_property has 48 bytes, we can do such
change here without breaking userspace, as struct dtv_stats will have
37 bytes.
--
Cheers,
Mauro
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH RFCv9 2/4] dvb: the core logic to handle the DVBv5 QoS properties
2013-01-08 0:25 [PATCH RFCv9 0/4] DVB QoS statistics API Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service Mauro Carvalho Chehab
@ 2013-01-08 0:25 ` Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 3/4] mb86a20s: provide signal strength via DVBv5 stats API Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 4/4] mb86a20s: add BER measure Mauro Carvalho Chehab
3 siblings, 0 replies; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 0:25 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List
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 | 56 +++++++++++++++++++++++++++++++++++
drivers/media/dvb-core/dvb_frontend.h | 12 ++++++++
2 files changed, 68 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index dd35fa9..66e066b 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -260,6 +260,9 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
return ret;
}
+ if (fe->ops.get_qos_stats)
+ fe->ops.get_qos_stats(fe);
+
mutex_lock(&events->mtx);
*event = events->events[events->eventr];
events->eventr = (events->eventr + 1) % MAX_EVENT;
@@ -1053,6 +1056,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 +1455,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 +1677,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 +1756,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 +2358,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..7bb49f1 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -315,6 +315,10 @@ 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 (*get_qos_stats)(struct dvb_frontend *fe);
+ int (*reset_qos_counters)(struct dvb_frontend *fe);
};
#ifdef __DVB_CORE__
@@ -393,6 +397,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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH RFCv9 3/4] mb86a20s: provide signal strength via DVBv5 stats API
2013-01-08 0:25 [PATCH RFCv9 0/4] DVB QoS statistics API Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 2/4] dvb: the core logic to handle the DVBv5 QoS properties Mauro Carvalho Chehab
@ 2013-01-08 0:25 ` Mauro Carvalho Chehab
2013-01-08 0:25 ` [PATCH RFCv9 4/4] mb86a20s: add BER measure Mauro Carvalho Chehab
3 siblings, 0 replies; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 0:25 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Implement DVBv5 API status handler functions.
The counter reset code there is complete for all stats provided
by this frontend.
The get_stats callback currently handles only the existing stat
(signal strength), although the code is already prepared for the
per-layer stats.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
drivers/media/dvb-frontends/mb86a20s.c | 166 +++++++++++++++++++++++++++++----
1 file changed, 148 insertions(+), 18 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index fade566..c2cc207 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -119,8 +119,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 },
@@ -176,6 +176,18 @@ static struct regdata mb86a20s_reset_reception[] = {
{ 0x08, 0x00 },
};
+static struct regdata mb86a20s_clear_stats[] = {
+ { 0x53, 0x00 }, /* VBER Counter reset */
+ { 0x53, 0x07 },
+
+ { 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)
{
@@ -223,7 +235,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;
@@ -278,29 +290,34 @@ 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, u16 *strength)
{
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;
@@ -310,12 +327,22 @@ static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
}
} while (1);
- dprintk("signal strength = %d\n", *strength);
+ return 0;
+}
+
+static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
+{
+ int rc;
+
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 0);
+
+ rc = __mb86a20s_read_signal_strength(fe, strength);
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- return 0;
+ return rc;
}
static int mb86a20s_read_status(struct dvb_frontend *fe, fe_status_t *status)
@@ -615,6 +642,106 @@ static int mb86a20s_tune(struct dvb_frontend *fe,
return rc;
}
+static int mb86a20s_reset_counters(struct dvb_frontend *fe)
+{
+
+ struct mb86a20s_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+ int rc, val;
+
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 0);
+
+ /* Set the QoS clear status for most stats */
+ 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);
+
+ /* Update the length of each status counter */
+
+ /* Only global stats */
+ c->strength.len = 1;
+
+ /* Per-layer stats */
+ c->cnr.len = 4;
+ c->bit_error.len = 4;
+ c->bit_count.len = 4;
+ c->block_error.len = 4;
+ c->block_count.len = 4;
+
+ return rc;
+}
+
+static int mb86a20s_get_stats(struct dvb_frontend *fe)
+{
+ int rc, i;
+ __u16 strength;
+
+ struct mb86a20s_state *state = fe->demodulator_priv;
+ struct dtv_frontend_properties *c = &fe->dtv_property_cache;
+
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 0);
+
+ /* Update signal relative level */
+ rc = __mb86a20s_read_signal_strength(fe, &strength);
+ c->strength.len = 1;
+ if (rc < 0) {
+ c->strength.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ } else {
+ c->strength.stat[0].scale = FE_SCALE_RELATIVE;
+ c->strength.stat[0].uvalue = strength;
+ }
+
+ /* Get per-layer stats */
+ for (i = 0; i < 3; i++) {
+ rc = mb86a20s_get_segment_count(state, i);
+ if (rc > 0 && rc < 14) {
+ /* Layer is active and has rc segments */
+
+ /* FIXME: add a per-layer stats logic */
+ }
+ }
+
+ if (fe->ops.i2c_gate_ctrl)
+ fe->ops.i2c_gate_ctrl(fe, 1);
+
+ return rc;
+}
+
static void mb86a20s_release(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe->demodulator_priv;
@@ -694,6 +821,9 @@ static struct dvb_frontend_ops mb86a20s_ops = {
.read_status = mb86a20s_read_status,
.read_signal_strength = mb86a20s_read_signal_strength,
.tune = mb86a20s_tune,
+
+ .reset_qos_counters = mb86a20s_reset_counters,
+ .get_qos_stats = mb86a20s_get_stats,
};
MODULE_DESCRIPTION("DVB Frontend module for Fujitsu mb86A20s hardware");
--
1.7.11.7
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH RFCv9 4/4] mb86a20s: add BER measure
2013-01-08 0:25 [PATCH RFCv9 0/4] DVB QoS statistics API Mauro Carvalho Chehab
` (2 preceding siblings ...)
2013-01-08 0:25 ` [PATCH RFCv9 3/4] mb86a20s: provide signal strength via DVBv5 stats API Mauro Carvalho Chehab
@ 2013-01-08 0:25 ` Mauro Carvalho Chehab
2013-01-08 0:37 ` [PATCH RFCv9] " Mauro Carvalho Chehab
3 siblings, 1 reply; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 0:25 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Add per-layer BER measure. In order to provide some data for
applications not prepared for layers support, calculate BER for
the worse-case scenario, e. g. sums the BER values for all layers
and provide it as a "global BER" value.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
drivers/media/dvb-frontends/mb86a20s.c | 99 ++++++++++++++++++++++++++++++++--
1 file changed, 94 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index c2cc207..7ecee12 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -94,7 +94,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 },
@@ -705,13 +705,76 @@ err:
return rc;
}
-static int mb86a20s_get_stats(struct dvb_frontend *fe)
+static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
+ unsigned layer,
+ u32 *error, u32 *count)
{
- int rc, i;
- __u16 strength;
+ struct mb86a20s_state *state = fe->demodulator_priv;
+ u8 byte[3];
+ int rc;
+
+ if (layer >= 3)
+ return -EINVAL;
+
+ /* Check if it is 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);
+ if (rc < 0)
+ return rc;
+ byte[0] = rc;
+ rc = mb86a20s_readreg(state, 0x56 + layer);
+ if (rc < 0)
+ return rc;
+ byte[1] = rc;
+ rc = mb86a20s_readreg(state, 0x57 + layer);
+ 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);
+ 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);
+ 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);
+ 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 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, i;
+ u16 strength;
+ u32 bit_error = 0, bit_count = 0;
+ u32 t_bit_error = 0, t_bit_count = 0;
+ bool has_total_ber = true;
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
@@ -732,10 +795,36 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
if (rc > 0 && rc < 14) {
/* Layer is active and has rc segments */
- /* FIXME: add a per-layer stats logic */
+ /* 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;
+ }
+ if (c->bit_error.stat[1 + i].scale != FE_SCALE_COUNTER)
+ has_total_ber = false;
+ else {
+ t_bit_error += c->bit_error.stat[1 + i].uvalue;
+ t_bit_count += c->bit_count.stat[1 + i].uvalue;
+ }
+
}
}
+ if (has_total_ber) {
+ /*
+ * 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;
+ }
+
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
--
1.7.11.7
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH RFCv9] mb86a20s: add BER measure
2013-01-08 0:25 ` [PATCH RFCv9 4/4] mb86a20s: add BER measure Mauro Carvalho Chehab
@ 2013-01-08 0:37 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 15+ messages in thread
From: Mauro Carvalho Chehab @ 2013-01-08 0:37 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List
Add per-layer BER measure. In order to provide some data for
applications not prepared for layers support, calculate BER for
the worse-case scenario, e. g. sums the BER values for all layers
and provide it as a "global BER" value.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
v2: by mistake, I sent the wrong version that weren't properly incrementing
the per-layer registers
drivers/media/dvb-frontends/mb86a20s.c | 104 +++++++++++++++++++++++++++++++--
1 file changed, 99 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c b/drivers/media/dvb-frontends/mb86a20s.c
index c2cc207..8a10111 100644
--- a/drivers/media/dvb-frontends/mb86a20s.c
+++ b/drivers/media/dvb-frontends/mb86a20s.c
@@ -94,7 +94,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 },
@@ -705,13 +705,76 @@ err:
return rc;
}
-static int mb86a20s_get_stats(struct dvb_frontend *fe)
+static int mb86a20s_get_ber_before_vterbi(struct dvb_frontend *fe,
+ unsigned layer,
+ u32 *error, u32 *count)
{
- int rc, i;
- __u16 strength;
+ struct mb86a20s_state *state = fe->demodulator_priv;
+ u8 byte[3];
+ int rc;
+
+ if (layer >= 3)
+ return -EINVAL;
+
+ /* Check if it is 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 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, i;
+ u16 strength;
+ u32 bit_error = 0, bit_count = 0;
+ u32 t_bit_error = 0, t_bit_count = 0;
+ bool has_total_ber = true;
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
@@ -732,10 +795,41 @@ static int mb86a20s_get_stats(struct dvb_frontend *fe)
if (rc > 0 && rc < 14) {
/* Layer is active and has rc segments */
- /* FIXME: add a per-layer stats logic */
+ /* 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;
+ }
+ if (c->bit_error.stat[1 + i].scale != FE_SCALE_COUNTER)
+ has_total_ber = false;
+ else {
+ t_bit_error += c->bit_error.stat[1 + i].uvalue;
+ t_bit_count += c->bit_count.stat[1 + i].uvalue;
+ }
+
}
}
+ /*
+ * FIXME: Some logic is likely need to ask the frontend to measure
+ * BER again
+ */
+
+ if (has_total_ber) {
+ /*
+ * 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;
+ }
+
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
--
1.7.11.7
^ permalink raw reply related [flat|nested] 15+ messages in thread