[RFCv1] add DTMB support for DVB API

[RFCv1] add DTMB support for DVB API

[Antti Palosaari]

Rename DMB-TH to DTMB.

Add few new values for existing parameters.

Add two new parameters, interleaving and carrier.
DTMB supports interleavers: 240 and 720.
DTMB supports carriers: 1 and 3780.

Signed-off-by: Antti Palosaari <crope@iki.fi>
---
  drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++++++++++++++++++-
  drivers/media/dvb/dvb-core/dvb_frontend.h |    3 +++
  include/linux/dvb/frontend.h              |   13 +++++++++++--
  include/linux/dvb/version.h               |    2 +-
  4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 821b225..ec2cbae 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 
1] = {
  	_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
  	_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
  	_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
+	_DTV_CMD(DTV_CARRIER, 1, 0),
+	_DTV_CMD(DTV_INTERLEAVING, 1, 0),

  	_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
  	_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
@@ -974,6 +976,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 
1] = {
  	_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
  	_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
  	_DTV_CMD(DTV_HIERARCHY, 0, 0),
+	_DTV_CMD(DTV_CARRIER, 0, 0),
+	_DTV_CMD(DTV_INTERLEAVING, 0, 0),

  	_DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
  };
@@ -1162,7 +1166,8 @@ static void dtv_property_adv_params_sync(struct 
dvb_frontend *fe)

  	/* Fake out a generic DVB-T request so we pass validation in the ioctl */
  	if ((c->delivery_system == SYS_ISDBT) ||
-	    (c->delivery_system == SYS_DVBT2)) {
+	    (c->delivery_system == SYS_DVBT2) ||
+	    (c->delivery_system == SYS_DTMB)) {
  		p->u.ofdm.constellation = QAM_AUTO;
  		p->u.ofdm.code_rate_HP = FEC_AUTO;
  		p->u.ofdm.code_rate_LP = FEC_AUTO;
@@ -1378,6 +1383,12 @@ static int dtv_property_process_get(struct 
dvb_frontend *fe,
  	case DTV_DVBT2_PLP_ID:
  		tvp->u.data = c->dvbt2_plp_id;
  		break;
+	case DTV_CARRIER:
+		tvp->u.data = c->carrier;
+		break;
+	case DTV_INTERLEAVING:
+		tvp->u.data = c->interleaving;
+		break;
  	default:
  		return -EINVAL;
  	}
@@ -1544,6 +1555,12 @@ static int dtv_property_process_set(struct 
dvb_frontend *fe,
  	case DTV_DVBT2_PLP_ID:
  		c->dvbt2_plp_id = tvp->u.data;
  		break;
+	case DTV_CARRIER:
+		c->carrier = tvp->u.data;
+		break;
+	case DTV_INTERLEAVING:
+		c->interleaving = tvp->u.data;
+		break;
  	default:
  		return -EINVAL;
  	}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h 
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 67bbfa7..4979ffc 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -343,6 +343,9 @@ struct dtv_frontend_properties {

  	fe_delivery_system_t	delivery_system;

+	u32			interleaving;
+	u32			carrier;
+
  	/* ISDB-T specifics */
  	u8			isdbt_partial_reception;
  	u8			isdbt_sb_mode;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index cb114f5..2fa3bc5 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -152,6 +152,7 @@ typedef enum fe_code_rate {
  	FEC_AUTO,
  	FEC_3_5,
  	FEC_9_10,
+	FEC_2_5,
  } fe_code_rate_t;


@@ -169,8 +170,11 @@ typedef enum fe_modulation {
  	APSK_16,
  	APSK_32,
  	DQPSK,
+	QAM_4_NR,
  } fe_modulation_t;

+#define QAM_4 QPSK
+
  typedef enum fe_transmit_mode {
  	TRANSMISSION_MODE_2K,
  	TRANSMISSION_MODE_8K,
@@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
  	GUARD_INTERVAL_1_128,
  	GUARD_INTERVAL_19_128,
  	GUARD_INTERVAL_19_256,
+	GUARD_INTERVAL_PN420,
+	GUARD_INTERVAL_PN595,
+	GUARD_INTERVAL_PN945,
  } fe_guard_interval_t;


@@ -317,8 +324,10 @@ struct dvb_frontend_event {
  #define DTV_DVBT2_PLP_ID	43

  #define DTV_ENUM_DELSYS		44
+#define DTV_INTERLEAVING	45
+#define DTV_CARRIER		46

-#define DTV_MAX_COMMAND				DTV_ENUM_DELSYS
+#define DTV_MAX_COMMAND				DTV_CARRIER

  typedef enum fe_pilot {
  	PILOT_ON,
@@ -349,7 +358,7 @@ typedef enum fe_delivery_system {
  	SYS_ISDBC,
  	SYS_ATSC,
  	SYS_ATSCMH,
-	SYS_DMBTH,
+	SYS_DTMB,
  	SYS_CMMB,
  	SYS_DAB,
  	SYS_DVBT2,
diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
index 0559e2b..43d9e8d 100644
--- a/include/linux/dvb/version.h
+++ b/include/linux/dvb/version.h
@@ -24,6 +24,6 @@
  #define _DVBVERSION_H_

  #define DVB_API_VERSION 5
-#define DVB_API_VERSION_MINOR 5
+#define DVB_API_VERSION_MINOR 6

  #endif /*_DVBVERSION_H_*/
-- 
1.7.4.4

Re: [RFCv1] add DTMB support for DVB API

[Mauro Carvalho Chehab]

On 22-12-2011 19:30, Antti Palosaari wrote:
> Rename DMB-TH to DTMB.

Patrick seems to believe that CTTB is a better name. In any case,
whatever name we pick, I think that the DocBook specs (and
maybe a comment at the header file) should point all the known
ways to call this standard. So, I'm fine with any choice.

> Add few new values for existing parameters.
> 
> Add two new parameters, interleaving and carrier.
> DTMB supports interleavers: 240 and 720.
> DTMB supports carriers: 1 and 3780.

The API change looks sane to my eyes. I have just a couple
comments below.

> 
> Signed-off-by: Antti Palosaari <crope@iki.fi>
> ---
>  drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++++++++++++++++++-
>  drivers/media/dvb/dvb-core/dvb_frontend.h |    3 +++
>  include/linux/dvb/frontend.h              |   13 +++++++++++--
>  include/linux/dvb/version.h               |    2 +-
>  4 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 821b225..ec2cbae 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
>      _DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
>      _DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
>      _DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
> +    _DTV_CMD(DTV_CARRIER, 1, 0),
> +    _DTV_CMD(DTV_INTERLEAVING, 1, 0),
> 
>      _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
>      _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
> @@ -974,6 +976,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
>      _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
>      _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
>      _DTV_CMD(DTV_HIERARCHY, 0, 0),
> +    _DTV_CMD(DTV_CARRIER, 0, 0),
> +    _DTV_CMD(DTV_INTERLEAVING, 0, 0),
> 
>      _DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
>  };
> @@ -1162,7 +1166,8 @@ static void dtv_property_adv_params_sync(struct dvb_frontend *fe)
> 
>      /* Fake out a generic DVB-T request so we pass validation in the ioctl */
>      if ((c->delivery_system == SYS_ISDBT) ||
> -        (c->delivery_system == SYS_DVBT2)) {
> +        (c->delivery_system == SYS_DVBT2) ||
> +        (c->delivery_system == SYS_DTMB)) {
>          p->u.ofdm.constellation = QAM_AUTO;
>          p->u.ofdm.code_rate_HP = FEC_AUTO;
>          p->u.ofdm.code_rate_LP = FEC_AUTO;
> @@ -1378,6 +1383,12 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
>      case DTV_DVBT2_PLP_ID:
>          tvp->u.data = c->dvbt2_plp_id;
>          break;
> +    case DTV_CARRIER:
> +        tvp->u.data = c->carrier;
> +        break;
> +    case DTV_INTERLEAVING:
> +        tvp->u.data = c->interleaving;
> +        break;
>      default:
>          return -EINVAL;
>      }
> @@ -1544,6 +1555,12 @@ static int dtv_property_process_set(struct dvb_frontend *fe,
>      case DTV_DVBT2_PLP_ID:
>          c->dvbt2_plp_id = tvp->u.data;
>          break;
> +    case DTV_CARRIER:
> +        c->carrier = tvp->u.data;
> +        break;
> +    case DTV_INTERLEAVING:
> +        c->interleaving = tvp->u.data;
> +        break;
>      default:
>          return -EINVAL;
>      }
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h b/drivers/media/dvb/dvb-core/dvb_frontend.h
> index 67bbfa7..4979ffc 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
> @@ -343,6 +343,9 @@ struct dtv_frontend_properties {
> 
>      fe_delivery_system_t    delivery_system;
> 
> +    u32            interleaving;
> +    u32            carrier;
> +
>      /* ISDB-T specifics */
>      u8            isdbt_partial_reception;
>      u8            isdbt_sb_mode;
> diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
> index cb114f5..2fa3bc5 100644
> --- a/include/linux/dvb/frontend.h
> +++ b/include/linux/dvb/frontend.h
> @@ -152,6 +152,7 @@ typedef enum fe_code_rate {
>      FEC_AUTO,
>      FEC_3_5,
>      FEC_9_10,
> +    FEC_2_5,
>  } fe_code_rate_t;
> 
> 
> @@ -169,8 +170,11 @@ typedef enum fe_modulation {
>      APSK_16,
>      APSK_32,
>      DQPSK,
> +    QAM_4_NR,

While the NR is generally associated with the modulation,
this is a channel code, and not part of the modulation itself
(btw, the DVBv3 API calls it as "constellation").

Ok, it is easier to add it here, but maybe it would be safer
to add a separate field for channel coding that would be used
to enable or disable the Nordstrom-Robinson code.

This is currently used only with QAM-4, but nothing prevents this
parity code to be added to other types of modulation.

>  } fe_modulation_t;
> 
> +#define QAM_4 QPSK

IMHO, this is overkill, but I'm ok with that.

> +
>  typedef enum fe_transmit_mode {
>      TRANSMISSION_MODE_2K,
>      TRANSMISSION_MODE_8K,
> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>      GUARD_INTERVAL_1_128,
>      GUARD_INTERVAL_19_128,
>      GUARD_INTERVAL_19_256,
> +    GUARD_INTERVAL_PN420,
> +    GUARD_INTERVAL_PN595,
> +    GUARD_INTERVAL_PN945,
>  } fe_guard_interval_t;
> 
> 
> @@ -317,8 +324,10 @@ struct dvb_frontend_event {
>  #define DTV_DVBT2_PLP_ID    43
> 
>  #define DTV_ENUM_DELSYS        44
> +#define DTV_INTERLEAVING    45
> +#define DTV_CARRIER        46
> 
> -#define DTV_MAX_COMMAND                DTV_ENUM_DELSYS
> +#define DTV_MAX_COMMAND                DTV_CARRIER
> 
>  typedef enum fe_pilot {
>      PILOT_ON,
> @@ -349,7 +358,7 @@ typedef enum fe_delivery_system {
>      SYS_ISDBC,
>      SYS_ATSC,
>      SYS_ATSCMH,
> -    SYS_DMBTH,
> +    SYS_DTMB,
>      SYS_CMMB,
>      SYS_DAB,
>      SYS_DVBT2,
> diff --git a/include/linux/dvb/version.h b/include/linux/dvb/version.h
> index 0559e2b..43d9e8d 100644
> --- a/include/linux/dvb/version.h
> +++ b/include/linux/dvb/version.h
> @@ -24,6 +24,6 @@
>  #define _DVBVERSION_H_
> 
>  #define DVB_API_VERSION 5
> -#define DVB_API_VERSION_MINOR 5
> +#define DVB_API_VERSION_MINOR 6
> 
>  #endif /*_DVBVERSION_H_*/

Re: [RFCv1] add DTMB support for DVB API

[Antti Palosaari]

On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
> On 22-12-2011 19:30, Antti Palosaari wrote:
>> Rename DMB-TH to DTMB.
>
> Patrick seems to believe that CTTB is a better name. In any case,
> whatever name we pick, I think that the DocBook specs (and
> maybe a comment at the header file) should point all the known
> ways to call this standard. So, I'm fine with any choice.

I am not going to change it for CTTB unless there is no some document 
given says it is more correct than DTMB. I have looked very many papers 
over there and DTMB is absolutely more common as far as I gave seen.

>> Add few new values for existing parameters.
>>
>> Add two new parameters, interleaving and carrier.
>> DTMB supports interleavers: 240 and 720.
>> DTMB supports carriers: 1 and 3780.
>
> The API change looks sane to my eyes. I have just a couple
> comments below.

I think I will add carrier modes to enum fe_transmit_mode... I will send 
new propose soon.

>> @@ -169,8 +170,11 @@ typedef enum fe_modulation {
>>       APSK_16,
>>       APSK_32,
>>       DQPSK,
>> +    QAM_4_NR,
>
> While the NR is generally associated with the modulation,
> this is a channel code, and not part of the modulation itself
> (btw, the DVBv3 API calls it as "constellation").
>
> Ok, it is easier to add it here, but maybe it would be safer
> to add a separate field for channel coding that would be used
> to enable or disable the Nordstrom-Robinson code.
>
> This is currently used only with QAM-4, but nothing prevents this
> parity code to be added to other types of modulation.
>
>>   } fe_modulation_t;
>>
>> +#define QAM_4 QPSK
>
> IMHO, this is overkill, but I'm ok with that.

Anyone else have comment about that?

regards
Antti
-- 
http://palosaari.fi/

Re: [RFCv1] add DTMB support for DVB API

[Andreas Oberritter]

On 23.12.2011 22:54, Antti Palosaari wrote:
> On 12/23/2011 12:55 PM, Mauro Carvalho Chehab wrote:
>> On 22-12-2011 19:30, Antti Palosaari wrote:
>>> Rename DMB-TH to DTMB.
>>
>> Patrick seems to believe that CTTB is a better name. In any case,
>> whatever name we pick, I think that the DocBook specs (and
>> maybe a comment at the header file) should point all the known
>> ways to call this standard. So, I'm fine with any choice.
> 
> I am not going to change it for CTTB unless there is no some document
> given says it is more correct than DTMB. I have looked very many papers
> over there and DTMB is absolutely more common as far as I gave seen.
> 
>>> Add few new values for existing parameters.
>>>
>>> Add two new parameters, interleaving and carrier.
>>> DTMB supports interleavers: 240 and 720.
>>> DTMB supports carriers: 1 and 3780.
>>
>> The API change looks sane to my eyes. I have just a couple
>> comments below.
> 
> I think I will add carrier modes to enum fe_transmit_mode... I will send
> new propose soon.
> 
>>> @@ -169,8 +170,11 @@ typedef enum fe_modulation {
>>>       APSK_16,
>>>       APSK_32,
>>>       DQPSK,
>>> +    QAM_4_NR,
>>
>> While the NR is generally associated with the modulation,
>> this is a channel code, and not part of the modulation itself
>> (btw, the DVBv3 API calls it as "constellation").
>>
>> Ok, it is easier to add it here, but maybe it would be safer
>> to add a separate field for channel coding that would be used
>> to enable or disable the Nordstrom-Robinson code.
>>
>> This is currently used only with QAM-4, but nothing prevents this
>> parity code to be added to other types of modulation.
>>
>>>   } fe_modulation_t;
>>>
>>> +#define QAM_4 QPSK
>>
>> IMHO, this is overkill, but I'm ok with that.
> 
> Anyone else have comment about that?

I don't think we should create such defines unless needed for backwards
compatibility, which is not the case.

Regards,
Andreas

[RFC] remove dtv_property_dump et al

[Andreas Oberritter]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On 22.12.2011 22:30, Antti Palosaari wrote:
> Rename DMB-TH to DTMB.
> 
> Add few new values for existing parameters.
> 
> Add two new parameters, interleaving and carrier.
> DTMB supports interleavers: 240 and 720.
> DTMB supports carriers: 1 and 3780.
> 
> Signed-off-by: Antti Palosaari <crope@iki.fi>
> ---
>  drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++++++++++++++++++-
>  drivers/media/dvb/dvb-core/dvb_frontend.h |    3 +++
>  include/linux/dvb/frontend.h              |   13 +++++++++++--
>  include/linux/dvb/version.h               |    2 +-
>  4 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 821b225..ec2cbae 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
> 1] = {
>      _DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
>      _DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
>      _DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
> +    _DTV_CMD(DTV_CARRIER, 1, 0),
> +    _DTV_CMD(DTV_INTERLEAVING, 1, 0),
> 
>      _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
>      _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
> @@ -974,6 +976,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
> 1] = {
>      _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
>      _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
>      _DTV_CMD(DTV_HIERARCHY, 0, 0),
> +    _DTV_CMD(DTV_CARRIER, 0, 0),
> +    _DTV_CMD(DTV_INTERLEAVING, 0, 0),
> 
>      _DTV_CMD(DTV_ENUM_DELSYS, 0, 0),
>  };

Adding this twice is wrong.

Almost every time new commands were added in the recent past, either the
command was not added to this table at all or the command was added more
than once. How about removing this array instead? It's only purpose is
to output ioctl parameters, which can be done with strace as well.

Actually, I have two patches queued doing that (see attachments). They
are based on 3.0.

Regards,
Andreas

[-- Attachment #2: 0001-RFC-DVB-remove-dtv_property_dump.patch --]
[-- Type: text/x-patch, Size: 6059 bytes --]

>From 0f9294ce272a853bb0f4513bbd07048938c78db2 Mon Sep 17 00:00:00 2001
From: Andreas Oberritter <obi@linuxtv.org>
Date: Tue, 13 Sep 2011 11:48:14 +0000
Subject: [PATCH 1/2] [RFC] DVB: remove dtv_property_dump()

- dtv_property_dump is the only user of struct dtv_cmds_h,
  which mistakenly got exported to userspace.

- It is used to print ioctl parameters, if debugging is enabled.
  The array used to print parameters contains both unused ("set")
  and invalid entries, i.e. DTV_CODE_RATE_HP and others are
  defined twice.

- When a new DTV command gets added, it's a common mistake to
  forget to add it to this array.

- It's possible to use strace instead or to write a simple
  LD_PRELOADable library.

Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |  116 -----------------------------
 include/linux/dvb/frontend.h              |   11 ---
 2 files changed, 0 insertions(+), 127 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 521b695..8274a6d 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -895,119 +895,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
 	return 0;
 }
 
-#define _DTV_CMD(n, s, b) \
-[n] = { \
-	.name = #n, \
-	.cmd  = n, \
-	.set  = s,\
-	.buffer = b \
-}
-
-static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
-	_DTV_CMD(DTV_TUNE, 1, 0),
-	_DTV_CMD(DTV_CLEAR, 1, 0),
-
-	/* Set */
-	_DTV_CMD(DTV_FREQUENCY, 1, 0),
-	_DTV_CMD(DTV_BANDWIDTH_HZ, 1, 0),
-	_DTV_CMD(DTV_MODULATION, 1, 0),
-	_DTV_CMD(DTV_INVERSION, 1, 0),
-	_DTV_CMD(DTV_DISEQC_MASTER, 1, 1),
-	_DTV_CMD(DTV_SYMBOL_RATE, 1, 0),
-	_DTV_CMD(DTV_INNER_FEC, 1, 0),
-	_DTV_CMD(DTV_VOLTAGE, 1, 0),
-	_DTV_CMD(DTV_TONE, 1, 0),
-	_DTV_CMD(DTV_PILOT, 1, 0),
-	_DTV_CMD(DTV_ROLLOFF, 1, 0),
-	_DTV_CMD(DTV_DELIVERY_SYSTEM, 1, 0),
-	_DTV_CMD(DTV_HIERARCHY, 1, 0),
-	_DTV_CMD(DTV_CODE_RATE_HP, 1, 0),
-	_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
-	_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
-	_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
-
-	_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYER_ENABLED, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0),
-
-	_DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 0, 0),
-	_DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 0, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 0, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 0, 0),
-	_DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYER_ENABLED, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_FEC, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_FEC, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_FEC, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 0, 0),
-	_DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 0, 0),
-
-	_DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
-	_DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
-
-	/* Get */
-	_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
-	_DTV_CMD(DTV_API_VERSION, 0, 0),
-	_DTV_CMD(DTV_CODE_RATE_HP, 0, 0),
-	_DTV_CMD(DTV_CODE_RATE_LP, 0, 0),
-	_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
-	_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
-	_DTV_CMD(DTV_HIERARCHY, 0, 0),
-};
-
-static void dtv_property_dump(struct dtv_property *tvp)
-{
-	int i;
-
-	if (tvp->cmd <= 0 || tvp->cmd > DTV_MAX_COMMAND) {
-		printk(KERN_WARNING "%s: tvp.cmd = 0x%08x undefined\n",
-			__func__, tvp->cmd);
-		return;
-	}
-
-	dprintk("%s() tvp.cmd    = 0x%08x (%s)\n"
-		,__func__
-		,tvp->cmd
-		,dtv_cmds[ tvp->cmd ].name);
-
-	if(dtv_cmds[ tvp->cmd ].buffer) {
-
-		dprintk("%s() tvp.u.buffer.len = 0x%02x\n"
-			,__func__
-			,tvp->u.buffer.len);
-
-		for(i = 0; i < tvp->u.buffer.len; i++)
-			dprintk("%s() tvp.u.buffer.data[0x%02x] = 0x%02x\n"
-				,__func__
-				,i
-				,tvp->u.buffer.data[i]);
-
-	} else
-		dprintk("%s() tvp.u.data = 0x%08x\n", __func__, tvp->u.data);
-}
-
 static int is_legacy_delivery_system(fe_delivery_system_t s)
 {
 	if((s == SYS_UNDEFINED) || (s == SYS_DVBC_ANNEX_AC) ||
@@ -1353,8 +1240,6 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
 			return r;
 	}
 
-	dtv_property_dump(tvp);
-
 	return 0;
 }
 
@@ -1365,7 +1250,6 @@ static int dtv_property_process_set(struct dvb_frontend *fe,
 	int r = 0;
 	struct dtv_frontend_properties *c = &fe->dtv_property_cache;
 	struct dvb_frontend_private *fepriv = fe->frontend_priv;
-	dtv_property_dump(tvp);
 
 	/* Allow the frontend to validate incoming properties */
 	if (fe->ops.set_property) {
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 1b1094c..81f813d 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -352,17 +352,6 @@ typedef enum fe_delivery_system {
 	SYS_TURBO,
 } fe_delivery_system_t;
 
-struct dtv_cmds_h {
-	char	*name;		/* A display name for debugging purposes */
-
-	__u32	cmd;		/* A unique ID */
-
-	/* Flags */
-	__u32	set:1;		/* Either a set or get property */
-	__u32	buffer:1;	/* Does this property use the buffer? */
-	__u32	reserved:30;	/* Align */
-};
-
 struct dtv_property {
 	__u32 cmd;
 	__u32 reserved[3];
-- 
1.7.2.5


[-- Attachment #3: 0002-RFC-DVB-remove-unused-DTV_MAX_COMMAND-from-frontend..patch --]
[-- Type: text/x-patch, Size: 806 bytes --]

>From bd707ac783dae5ea958f8480fce84bb89c28535f Mon Sep 17 00:00:00 2001
From: Andreas Oberritter <obi@linuxtv.org>
Date: Tue, 13 Sep 2011 14:13:24 +0000
Subject: [PATCH 2/2] [RFC] DVB: remove unused DTV_MAX_COMMAND from frontend.h

- This value was exported to userspace but serves no purpose.

Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
---
 include/linux/dvb/frontend.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 81f813d..37a4d38 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -316,8 +316,6 @@ struct dvb_frontend_event {
 
 #define DTV_DVBT2_PLP_ID	43
 
-#define DTV_MAX_COMMAND				DTV_DVBT2_PLP_ID
-
 typedef enum fe_pilot {
 	PILOT_ON,
 	PILOT_OFF,
-- 
1.7.2.5

Re: [RFCv1] add DTMB support for DVB API

[Andreas Oberritter]

On 22.12.2011 22:30, Antti Palosaari wrote:
> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>      GUARD_INTERVAL_1_128,
>      GUARD_INTERVAL_19_128,
>      GUARD_INTERVAL_19_256,
> +    GUARD_INTERVAL_PN420,
> +    GUARD_INTERVAL_PN595,
> +    GUARD_INTERVAL_PN945,
>  } fe_guard_interval_t;

What does PN mean in this context?

Regards,
Andreas

Re: [RFCv1] add DTMB support for DVB API

[Patrick Boettcher]

On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
> On 22.12.2011 22:30, Antti Palosaari wrote:
> > @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
> > 
> >      GUARD_INTERVAL_1_128,
> >      GUARD_INTERVAL_19_128,
> >      GUARD_INTERVAL_19_256,
> > 
> > +    GUARD_INTERVAL_PN420,
> > +    GUARD_INTERVAL_PN595,
> > +    GUARD_INTERVAL_PN945,
> > 
> >  } fe_guard_interval_t;
> 
> What does PN mean in this context?

While I (right now) cannot remember what the PN abbreviation stands for, the 
numbers are the guard time in micro-seconds. At least if I remember 
correctly.

I can confirm that Tuesday next week if no one else corrects me before.

--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/

Re: [RFCv1] add DTMB support for DVB API

[Antti Palosaari]

On 12/23/2011 07:27 PM, Patrick Boettcher wrote:
> On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
>> On 22.12.2011 22:30, Antti Palosaari wrote:
>>> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>>>
>>>       GUARD_INTERVAL_1_128,
>>>       GUARD_INTERVAL_19_128,
>>>       GUARD_INTERVAL_19_256,
>>>
>>> +    GUARD_INTERVAL_PN420,
>>> +    GUARD_INTERVAL_PN595,
>>> +    GUARD_INTERVAL_PN945,
>>>
>>>   } fe_guard_interval_t;
>>
>> What does PN mean in this context?
>
> While I (right now) cannot remember what the PN abbreviation stands for, the
> numbers are the guard time in micro-seconds. At least if I remember
> correctly.
>
> I can confirm that Tuesday next week if no one else corrects me before.

I see you have sent that reply more than one day ago, but likely due to 
problems of your mail server it was delivered late. So I have already 
answered that.

Antti

-- 
http://palosaari.fi/

Re: [RFCv1] add DTMB support for DVB API

[Patrick Boettcher]

On Friday 23 December 2011 18:27:12 Patrick Boettcher wrote:
> On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
> > On 22.12.2011 22:30, Antti Palosaari wrote:
> > > @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
> > > 
> > >      GUARD_INTERVAL_1_128,
> > >      GUARD_INTERVAL_19_128,
> > >      GUARD_INTERVAL_19_256,
> > > 
> > > +    GUARD_INTERVAL_PN420,
> > > +    GUARD_INTERVAL_PN595,
> > > +    GUARD_INTERVAL_PN945,
> > > 
> > >  } fe_guard_interval_t;
> > 
> > What does PN mean in this context?
> 
> While I (right now) cannot remember what the PN abbreviation stands
> for, the numbers are the guard time in micro-seconds. At least if I
> remember correctly.

Totally wrong.

The number indicated by the PN-value is in samples. Not in micro-
seconds.

To compare the PN value with the guard-time known from DVB-T we could do 
like that: in DVB-T's 8K mode we have 8192 samples which make one 
symbol. If the guard time is 1/32 we have 8192/32 samples which 
represent the protect the symbols from inter-symbol-interference: 256 in 
this case. 

In DTMB one symbol consists of 3780 samples + the PN-value. Using the 
classical representation we could say: PN420 is 1/9, PN595 is about 1/6 
and PN945 is 1/4.

HTH,

--
Patrick Boettcher

Kernel Labs Inc.
http://www.kernellabs.com/

Re: [RFCv1] add DTMB support for DVB API

[Mauro Carvalho Chehab]

On 27-12-2011 14:26, Patrick Boettcher wrote:
> On Friday 23 December 2011 18:27:12 Patrick Boettcher wrote:
>> On Friday, December 23, 2011 02:38:59 PM Andreas Oberritter wrote:
>>> On 22.12.2011 22:30, Antti Palosaari wrote:
>>>> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>>>>
>>>>      GUARD_INTERVAL_1_128,
>>>>      GUARD_INTERVAL_19_128,
>>>>      GUARD_INTERVAL_19_256,
>>>>
>>>> +    GUARD_INTERVAL_PN420,
>>>> +    GUARD_INTERVAL_PN595,
>>>> +    GUARD_INTERVAL_PN945,
>>>>
>>>>  } fe_guard_interval_t;
>>>
>>> What does PN mean in this context?
>>
>> While I (right now) cannot remember what the PN abbreviation stands
>> for, the numbers are the guard time in micro-seconds. At least if I
>> remember correctly.
> 
> Totally wrong.
> 
> The number indicated by the PN-value is in samples. Not in micro-
> seconds.
> 
> To compare the PN value with the guard-time known from DVB-T we could do 
> like that: in DVB-T's 8K mode we have 8192 samples which make one 
> symbol. If the guard time is 1/32 we have 8192/32 samples which 
> represent the protect the symbols from inter-symbol-interference: 256 in 
> this case. 
> 
> In DTMB one symbol consists of 3780 samples + the PN-value. Using the 
> classical representation we could say: PN420 is 1/9, PN595 is about 1/6 
> and PN945 is 1/4.

PN595 is then 595/3780 = 119/756 = 17/108

While we might code it then as:

      GUARD_INTERVAL_1_9,		/* PN 420 */
      GUARD_INTERVAL_17_108,		/* PN 595 */
      GUARD_INTERVAL_1_4,		/* PN 945 */

in order to preserve the traditional way, maybe it should be coded, instead, as:

    GUARD_INTERVAL_420_SAMPLES,		/* PN 420 */
    GUARD_INTERVAL_595_SAMPLES,		/* PN 595 */
    GUARD_INTERVAL_945_SAMPLES,		/* PN 945 */

I would avoid "PN", as this meaning is not as clear as "samples" or as
a fraction. Also, the traditional guard interval won't be obvious for the
ones that know the DTMB spec.
> 
> HTH,
> 
> --
> Patrick Boettcher
> 
> Kernel Labs Inc.
> http://www.kernellabs.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv1] add DTMB support for DVB API

[Antti Palosaari]

On 12/23/2011 03:38 PM, Andreas Oberritter wrote:
> On 22.12.2011 22:30, Antti Palosaari wrote:
>> @@ -201,6 +205,9 @@ typedef enum fe_guard_interval {
>>       GUARD_INTERVAL_1_128,
>>       GUARD_INTERVAL_19_128,
>>       GUARD_INTERVAL_19_256,
>> +    GUARD_INTERVAL_PN420,
>> +    GUARD_INTERVAL_PN595,
>> +    GUARD_INTERVAL_PN945,
>>   } fe_guard_interval_t;
>
> What does PN mean in this context?

It stays for pseudo noise.

Generally those are rather same as PN420 = GI 1/4, PN595 = GI 1/6, PN945 
= GI 1/9. But as a old DVB-T GI, cyclic prefix, is rather likely some 
static data without any real payload meaning, the PN GI is enchanted 
inserting some data that have meaning. Also PN GI is boosted, like 
doubled TX power in order to easy sync.

Here is the one good research paper which compares DVB-T and DTMB [1]
And this Wikipedia page is rather helful too [2]


As I have read much more docs today I have now some changes I want to do:

CARRIER
=======
typedef enum fe_transmit_mode {
	TRANSMISSION_MODE_C=1,
	TRANSMISSION_MODE_C=3780,
} fe_transmit_mode_t;

(If not "=" mark is not possible then use C1, C3780)

Instead of adding new carrier param, just use exiting one since it seems 
to be just suitable. Extend DTMB modes C=1 and C=3780.



GUARD INTERVAL (PN-mode)
========================
typedef enum fe_guard_interval {
	GUARD_INTERVAL_PN420,
	GUARD_INTERVAL_PN595,
	GUARD_INTERVAL_PN945,
} fe_guard_interval_t;



CODE RATE
=========
typedef enum fe_code_rate {
	FEC_04,
	FEC_06,
	FEC_08,
} fe_code_rate_t;

I have strong feeling old FECs, 1 over 2, are 100% suitable only for the 
Reed-Solomon coding. For BCH + LDPC coding those are not so suitable as 
code rate is not exact and thus with LDPC 0.4/0.6/0.8 is used. I have 
mentioned that earlier too, but after I read that [1] I think it is just 
like that. It is not big issue but still I would like to use those 
instead old.

Otherwise FEC_2_5 for code rate 0.4 should be defined.



MODULATION (constellation)
==========================
typedef enum fe_modulation {
	QAM_4_NR,
} fe_modulation_t;

I feel QAM4-NR fits here too, since it is mentioned every document just 
one more supported modulation like QAM32, QAM16, QAM4...


INTERLEAVING
============
typedef enum fe_interleaving {
	INTERLEAVING_240,
	INTERLEAVING_720,
} fe_interleaving_t;

I think better to add enum for all possible interleavers we can have. I 
suspect there will be very limited amount of interleave settings 
supported by each DTV modulation, thus enum is good choice.



That's all. I will wait comments maybe tomorrow night and make new 
propose or RFC. I hope comments. And all those comments given are taken 
accepted unless I replied something back. And please look research paper 
[1], it is very good. Happy Xmas!


[1] Analysis and Performance Comparison of DVB-T and DTMB Systems for 
Terrestrial Digital TV
http://hal.archives-ouvertes.fr/docs/00/32/58/24/PDF/MLIU_ICCS2008.pdf

[2] OFDM system comparison table
http://en.wikipedia.org/wiki/OFDM#OFDM_system_comparison_table

regards
Antti
-- 
http://palosaari.fi/

Re: [RFCv1] add DTMB support for DVB API

[Patrick Boettcher]

Hi Antti,

On Thursday, December 22, 2011 10:30:25 PM Antti Palosaari wrote:
> Rename DMB-TH to DTMB.
> 
> Add few new values for existing parameters.
> 
> Add two new parameters, interleaving and carrier.
> DTMB supports interleavers: 240 and 720.
> DTMB supports carriers: 1 and 3780.
> 
> Signed-off-by: Antti Palosaari <crope@iki.fi>
> ---
>   drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++++++++++++++++++-
>   drivers/media/dvb/dvb-core/dvb_frontend.h |    3 +++
>   include/linux/dvb/frontend.h              |   13 +++++++++++--
>   include/linux/dvb/version.h               |    2 +-
>   4 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 821b225..ec2cbae 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
> 1] = {
>   	_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
>   	_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
>   	_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
> +	_DTV_CMD(DTV_CARRIER, 1, 0),

What would you think if instead of adding DTV_CARRIER (which indicates 
whether we are using single carrier or multi carrier, if I understand it 
correctly) we add a TRANSMISSION_MODE_SC.

Then TRANSMISSION_MODE_4K is the multi-carrier mode and TRANSMISSION_MODE_SC 
is the single-carrier mode. We save a new DTV-command.

I'm not making a secret of it, this is how we handled this inside DiBcom and 
it would simplify the integration of our drivers for this standard. This is 
planned to be done during the first half of 2012.

Comments?

--
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/

Re: [RFCv1] add DTMB support for DVB API

[Antti Palosaari]

On 12/23/2011 07:30 PM, Patrick Boettcher wrote:
> Hi Antti,
>
> On Thursday, December 22, 2011 10:30:25 PM Antti Palosaari wrote:
>> Rename DMB-TH to DTMB.
>>
>> Add few new values for existing parameters.
>>
>> Add two new parameters, interleaving and carrier.
>> DTMB supports interleavers: 240 and 720.
>> DTMB supports carriers: 1 and 3780.
>>
>> Signed-off-by: Antti Palosaari<crope@iki.fi>
>> ---
>>    drivers/media/dvb/dvb-core/dvb_frontend.c |   19 ++++++++++++++++++-
>>    drivers/media/dvb/dvb-core/dvb_frontend.h |    3 +++
>>    include/linux/dvb/frontend.h              |   13 +++++++++++--
>>    include/linux/dvb/version.h               |    2 +-
>>    4 files changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index 821b225..ec2cbae 100644
>> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> @@ -924,6 +924,8 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND +
>> 1] = {
>>    	_DTV_CMD(DTV_CODE_RATE_LP, 1, 0),
>>    	_DTV_CMD(DTV_GUARD_INTERVAL, 1, 0),
>>    	_DTV_CMD(DTV_TRANSMISSION_MODE, 1, 0),
>> +	_DTV_CMD(DTV_CARRIER, 1, 0),
>
> What would you think if instead of adding DTV_CARRIER (which indicates
> whether we are using single carrier or multi carrier, if I understand it
> correctly) we add a TRANSMISSION_MODE_SC.
>
> Then TRANSMISSION_MODE_4K is the multi-carrier mode and TRANSMISSION_MODE_SC
> is the single-carrier mode. We save a new DTV-command.
>
> I'm not making a secret of it, this is how we handled this inside DiBcom and
> it would simplify the integration of our drivers for this standard. This is
> planned to be done during the first half of 2012.
>
> Comments?

I already did that :)

I proposed it yesterday. But as you seems to have problem with your send 
mail server that reply arrives more than one day late you have sent. 
Anyhow, nice to see you have ended up same decision.

I named those TRANSMISSION_MODE_C=1 and TRANSMISSION_MODE_C=3780 as 
those were names used by specification.

The only totally new parameter is interleaver which I didn't find 
existing one have same meaning.

But look my yesterday mails and reply, I will wait your review under I 
post new RFC patch. Also I would like to hear Andreas comments.

thanks
Antti



-- 
http://palosaari.fi/