From patchwork Tue Jan 1 15:00:41 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 16053 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1Tq3LI-0006i0-2i; Tue, 01 Jan 2013 16:01:24 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtp id 1Tq3LH-0003qh-D3; Tue, 01 Jan 2013 16:01:23 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296Ab3AAPBS (ORCPT + 1 other); Tue, 1 Jan 2013 10:01:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41124 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752274Ab3AAPBS (ORCPT ); Tue, 1 Jan 2013 10:01:18 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r01F1DLa030810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Jan 2013 10:01:14 -0500 Received: from localhost.localdomain (vpn1-6-223.gru2.redhat.com [10.97.6.223]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r01F19ol015620; Tue, 1 Jan 2013 10:01:11 -0500 Date: Tue, 1 Jan 2013 13:00:41 -0200 From: Mauro Carvalho Chehab To: Devin Heitmueller Cc: Linux Media Mailing List , Klaus Schmidinger Subject: Re: [PATCH RFCv3] dvb: Add DVBv5 properties for quality parameters Message-ID: <20130101130041.52dee65f@redhat.com> In-Reply-To: References: <1356739006-22111-1-git-send-email-mchehab@redhat.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.1.144821 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, MIME_LOWER_CASE 0.05, MSGID_ADDED_BY_MTA 0.05, FROM_NAME_PHRASE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' Em Sat, 29 Dec 2012 11:36:16 -0500 Devin Heitmueller escreveu: > On Fri, Dec 28, 2012 at 6:56 PM, Mauro Carvalho Chehab > wrote: > > The DVBv3 quality parameters are limited on several ways: > > - Doesn't provide any way to indicate the used measure; > > - Userspace need to guess how to calculate the measure; > > - Only a limited set of stats are supported; > > - Doesn't provide QoS measure for the OFDM TPS/TMCC > > carriers, used to detect the network parameters for > > DVB-T/ISDB-T; > > - 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; > > This RFC adds the header definitions meant to solve that issues. > > After discussed, I'll write a patch for the DocBook and add support > > for it on some demods. Support for dvbv5-zap and dvbv5-scan tools > > will also have support for those features. > > Hi Mauro, <...> > You have a units field which is "decibels", but in what unit? 1 dB / > unit? 0.1 db / unit? 1/255 db / unit? This particular issue is why > the current snr field varies across even demods where we have the > datasheets. Many demods reported in 0.1 dB increments, while others > reported in 1/255 dB increments. There was min/max values there to allow userspace to calculate the scale, but it seems simpler to just define a 0.1dB step. <...> > This needs to be defined *in the spec*, Sure. After we agree on the API we'll be using, I'll write the spec bits and add the logic on a driver. I did that in the past, but as the discussions were long and no consensus was reached. So, I opted to just write the changes at the frontend.h for the discussons. <...> Ok, I decided to post a version 4, removing the things that I won't be using (that got inherited by a previous proposal from another developer sent to the ML a few years ago). This version defines 4 types of statistics: signal, SNR, BER, error count at the TMCC/TPS carrier. There are just 2 possible ranges: dB (actually 0.1 dB); percentage, from 0 to 100%. There's a third "range" type that means that a given parameter is not available. I didn't add any bits to indicate why, as the reason may not be relevant to userspace. It might make sense to have different types, one for temporary unavailability and another one for permanent unavailability. There's also one parameter to enumerate what QoS parameters are supported by the driver. Regards, Mauro - [RFCv4] dvb: Add DVBv5 properties for quality parameters The DVBv3 quality parameters are limited on several ways: - Doesn't provide any way to indicate the used measure; - Userspace need to guess how to calculate the measure; - Only a limited set of stats are supported; - Doesn't provide QoS measure for the OFDM TPS/TMCC carriers, used to detect the network parameters for DVB-T/ISDB-T; - 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; This RFC adds the header definitions meant to solve that issues. After discussed, I'll write a patch for the DocBook and add support for it on some demods. Support for dvbv5-zap and dvbv5-scan tools will also have support for those features. Signed-off-by: Mauro Carvalho Chehab --- include/uapi/linux/dvb/frontend.h | 78 ++++++++++++++++++++++++++++++++++++++- include/uapi/linux/dvb/frontend.h | 60 +++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) v3: Just update http://patchwork.linuxtv.org/patch/9578/ to current tip v4: API simplified and addressed some issues pointed by Devin > > Devin > --- patchwork.orig/include/uapi/linux/dvb/frontend.h +++ patchwork/include/uapi/linux/dvb/frontend.h @@ -365,7 +365,14 @@ struct dvb_frontend_event { #define DTV_INTERLEAVING 60 #define DTV_LNA 61 -#define DTV_MAX_COMMAND DTV_LNA +/* Quality parameters */ +#define DTV_ENUM_QUALITY 62 /* Enumerates supported QoS parameters */ +#define DTV_FE_SIGNAL 63 /* Signal strength at the demod */ +#define DTV_QUALITY_SNR 64 /* Signal/Noise ratio */ +#define DTV_ERROR_BER 65 /* Bit error rate since signal lock */ +#define DTV_ERROR_COUNT 66 /* Monotonic error count since signal lock at TMCC or TPS carrier */ + +#define DTV_MAX_COMMAND DTV_ERROR_COUNT typedef enum fe_pilot { PILOT_ON, @@ -452,12 +459,63 @@ 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%). + */ +enum fecap_scale_params { + FE_SCALE_NOT_AVAILABLE, + FE_SCALE_DECIBEL, + FE_SCALE_RELATIVE +}; + +/** + * struct dtv_status - 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. + * In other words, for ISDB, those values should be filled like: + * stat.status[0] = global statistics; + * stat.scale[0] = FE_SCALE_NOT_AVAILABLE (if not available); + * stat.status[1] = layer A statistics; + * stat.status[2] = layer B statistics; + * stat.status[3] = layer C statistics. + * and stat.len should be filled with the latest filled status + 1. + */ +struct dtv_status { + __u16 value; + __u16 scale; +} __attribute__ ((packed)); + struct dtv_property { __u32 cmd; __u32 reserved[3]; union { __u32 data; struct { + __u8 len; + struct dtv_status status[4]; + } stat; + struct { __u8 data[32]; __u32 len; __u32 reserved1[3];