Re: [PATCH] dvb_frontend: fix typos in comments and one function
Hi Steven, > This and your other two patches are in > http://www.kernellabs.com/hg/~stoth/saa7164-dev > > They look good to me. What is the proper process to see the patches accepted and integrated ? I want to be aligned with the way of working before sending other corrections or improvements. Thanks. -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb_frontend: fix typos in comments and one function
Hello Steven, > I've had an open TDA10048 bug on my list for quite a while, I think > you've already made reference to this in an earlier email. Essentially > I'm told my a number of Australian users that the 10048 isn't > broad-locking when tuned +- 167Khz away from the carrier, which it > should definitely do. If you're in the mood for patching the 10048 and > want to find and flip the broad-locking bit then I'd be certainly > thrilled to test this. :) Well, this is an interesting subject and there is a lot to say. Sorry in advance if you already know what I will explain: - the channel distribution is usually well known in DVB-T. For example, from 474MHz to 858MHz in UHF/8MHz. This channel distribution depends on each country. - due to the existing analogue channels, some FIXED frequency offsets have been introduced here and there to move the DVB-T channel away from the analogue channels depending on how critical it can be. These frequency offsets are commonly +/-166KHz everywhere, except in France (+/-N*166KHz with N=1,2,3) and in Australia (+/-125KHz) as far as I know. - hence the DVB-T channel can be shifted in IF by +/-125KHz, +/-166KHz, +/-333KHz, +/-500KHz. The channel decoder will or will not recover such an offset depending on the strategy. If it can lock, the IF signal will be partially filtered out by the IF filter and this impacts the performance. The best approach is to detect the potential frequency offset and re-program the tuner to the new frequency. Now about the TDA10048: - it naturally recovers the small offsets during the lock (error returned in FREQERR_R at 0x28 & 0x29): in 8MHz: +/-93KHz in 7MHz: +/-82KHz in 6MHz: +/-70KHz - the AUTOOFFSET bit allows to detect the fixed frequency offset whose value is returned in OFFSET_F (in 0x14) when there is no lock. If an offset is detected, it is applied to the tuner, then AUTOOFFSET is set to 0 and the acquisition is checked again. This is the normal and preferred way. The non-recommended option is to force the lock when a fixed offset is detected without reprogramming the tuner. This is possible only with certain firmware versions (>=0x34), in forcing 1 in register 0x19[0], the fixed offset will still be available in OFFSET_F after the lock. For earlier firmware versions, the 0x19[0] bit has no effect. Ideally, for the channel demodulator driver, the API should provide an interface to set the frequency offset recovery (AUTO, NONE...) and to get the detected frequency offset if any. -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Philips/NXP channel decoders
Hello Steven, > I can test your TDA10048 patches and add sign-off for merge. Looking > at the list it appears that you have a few nice cleanups. I'll draw > all of these together this weekend and run some tests. Thanks a lot. By the way, I found the read_ber function not fully defined. I guess this subject has already been addressed on this list but cannot pinpoint where in the archives. Did I miss something ? First, *ber is an unsigned integer type, then the bit-error-rate (<=1) has obviously to be made higher than 1. I have decided to multiply the actual ber into 1e8 for two reasons: - 1e-8 offers a good precision and is compatible with what can give the TDA10046/TDA10048 for the VBER - the theoretical max value (1 -> 1e8) fits into the u32 type Naturally, this factor of 1e8 should be defined to be homogeneous for all channel decoders as the read_ber function is exposed. Second, the returned BER is the channel bit-error-rate which is the BER estimation before the Viterbi decoder (for DVB-T). Why this choice ? Thanks in advance for clarifying. -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb_frontend: fix typos in comments and one function
Hello,
Trivial patch for typos.
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..e12a0f9 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -460,7 +460,7 @@ static void dvb_frontend_swzigzag(struct dvb_frontend
*fe)
if ((fepriv->state & FESTATE_SEARCHING_FAST) || (fepriv->state &
FESTATE_RETUNE)) {
fepriv->delay = fepriv->min_delay;
- /* peform a tune */
+ /* perform a tune */
retval = dvb_frontend_swzigzag_autotune(fe,
fepriv->check_wrapped);
if (retval < 0) {
@@ -783,7 +783,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return 0;
}
-static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
+static void dvb_frontend_get_frequency_limits(struct dvb_frontend *fe,
u32 *freq_min, u32 *freq_max)
{
*freq_min = max(fe->ops.info.frequency_min,
fe->ops.tuner_ops.info.frequency_min);
@@ -807,7 +807,7 @@ static int dvb_frontend_check_parameters(struct
dvb_frontend *fe,
u32 freq_max;
/* range check: frequency */
- dvb_frontend_get_frequeny_limits(fe, &freq_min, &freq_max);
+ dvb_frontend_get_frequency_limits(fe, &freq_min, &freq_max);
if ((freq_min && parms->frequency < freq_min) ||
(freq_max && parms->frequency > freq_max)) {
printk(KERN_WARNING "DVB: adapter %i frontend %i frequency %u
out of
range (%u..%u)\n",
@@ -1620,7 +1620,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
- dvb_frontend_get_frequeny_limits(fe, &info->frequency_min,
&info->frequency_max);
+ dvb_frontend_get_frequency_limits(fe, &info->frequency_min,
&info->frequency_max);
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
* do it, it is done for it. */
@@ -1719,7 +1719,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
*inode, struct file *file,
* (stv0299 for instance) take longer than 8msec to
* respond to a set_voltage command. Those switches
* need custom routines to switch properly. For all
-* other frontends, the following shoule work ok.
+* other frontends, the following should work ok.
* Dish network legacy switches (as used by Dish500)
* are controlled by sending 9-bit command words
* spaced 8msec apart.
--
1.6.3.3
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tda10048: clear the uncorrected packet registers when saturated
Hello, Use the register CLUNC to reset the CPTU registers (LSB & MSB) when they saturate at 0x. Fixes as well a few register typos. Signed-off-by: Guillaume Audirac --- drivers/media/dvb/frontends/tda10048.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/frontends/tda10048.c b/drivers/media/dvb/frontends/tda10048.c index 9a0ba30..93f6a75 100644 --- a/drivers/media/dvb/frontends/tda10048.c +++ b/drivers/media/dvb/frontends/tda10048.c @@ -50,8 +50,8 @@ #define TDA10048_CONF_C4_1 0x1E #define TDA10048_CONF_C4_2 0x1F #define TDA10048_CODE_IN_RAM 0x20 -#define TDA10048_CHANNEL_INFO_1_R 0x22 -#define TDA10048_CHANNEL_INFO_2_R 0x23 +#define TDA10048_CHANNEL_INFO1_R 0x22 +#define TDA10048_CHANNEL_INFO2_R 0x23 #define TDA10048_CHANNEL_INFO1 0x24 #define TDA10048_CHANNEL_INFO2 0x25 #define TDA10048_TIME_ERROR_R 0x26 @@ -64,8 +64,8 @@ #define TDA10048_IT_STAT 0x32 #define TDA10048_DSP_AD_LSB0x3C #define TDA10048_DSP_AD_MSB0x3D -#define TDA10048_DSP_REF_LSB 0x3E -#define TDA10048_DSP_REF_MSB 0x3F +#define TDA10048_DSP_REG_LSB 0x3E +#define TDA10048_DSP_REG_MSB 0x3F #define TDA10048_CONF_TRISTATE10x44 #define TDA10048_CONF_TRISTATE20x45 #define TDA10048_CONF_POLARITY 0x46 @@ -1033,6 +1033,9 @@ static int tda10048_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks) *ucblocks = tda10048_readreg(state, TDA10048_UNCOR_CPT_MSB) << 8 | tda10048_readreg(state, TDA10048_UNCOR_CPT_LSB); + /* clear the uncorrected TS packets counter when saturated */ + if (*ucblocks == 0x) + tda10048_writereg(state, TDA10048_UNCOR_CTRL, 0x80); return 0; } -- 1.6.3.3 -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tda10048: fix bitmask for the transmission mode
Hello,
Add a missing bit for reading the transmission mode (2K/8K) in
tda10048_get_tps
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/frontends/tda10048.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 9006107..9a0ba30 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -689,7 +689,7 @@ static int tda10048_get_tps(struct tda10048_state *state,
p->guard_interval = GUARD_INTERVAL_1_4;
break;
}
- switch (val & 0x02) {
+ switch (val & 0x03) {
case 0:
p->transmission_mode = TRANSMISSION_MODE_2K;
break;
--
1.6.3.3
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tda10048: fix the uncomplete function tda10048_read_ber
Hello Steven, > Thanks Guillaume, I have a pile of other patches I'm ready to present > for merge so I'll pull this into one of my dev trees and present this > for merge also of course, I'll test it first! :) > > Thanks again for working on this. You're welcome. I am just starting reviewing the driver. I have already noticed a few errors in it. I will keep on sending obvious patches. I can quickly summarise some of the missing important features: - missing lock algorithm which should use the SCAN_CPT register to make it efficient - missing frequency offset detection (thanks to AUTOOFFSET=1 and OFFSET_F) -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tda10048: fix the uncomplete function tda10048_read_ber
Hello,
Completes the bit-error-rate read function with the CBER register (before
Viterbi decoder). The returned value is 1e8*actual_ber to be positive.
Also includes some typo mistakes.
Signed-off-by: Guillaume Audirac
---
drivers/media/dvb/frontends/tda10048.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 4e2a7c8..9006107 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "dvb_frontend.h"
#include "dvb_math.h"
@@ -112,7 +113,7 @@
#define TDA10048_FREE_REG_10xB2
#define TDA10048_FREE_REG_20xB3
#define TDA10048_CONF_C3_1 0xC0
-#define TDA10048_CYBER_CTRL0xC2
+#define TDA10048_CVBER_CTRL0xC2
#define TDA10048_CBER_NMAX_LSB 0xC4
#define TDA10048_CBER_NMAX_MSB 0xC5
#define TDA10048_CBER_LSB 0xC6
@@ -120,7 +121,7 @@
#define TDA10048_VBER_LSB 0xC8
#define TDA10048_VBER_MID 0xC9
#define TDA10048_VBER_MSB 0xCA
-#define TDA10048_CYBER_LUT 0xCC
+#define TDA10048_CVBER_LUT 0xCC
#define TDA10048_UNCOR_CTRL0xCD
#define TDA10048_UNCOR_CPT_LSB 0xCE
#define TDA10048_UNCOR_CPT_MSB 0xCF
@@ -183,7 +184,7 @@ static struct init_tab {
{ TDA10048_AGC_IF_MAX, 0xff },
{ TDA10048_AGC_THRESHOLD_MSB, 0x00 },
{ TDA10048_AGC_THRESHOLD_LSB, 0x70 },
- { TDA10048_CYBER_CTRL, 0x38 },
+ { TDA10048_CVBER_CTRL, 0x38 },
{ TDA10048_AGC_GAINS, 0x12 },
{ TDA10048_CONF_XO, 0x00 },
{ TDA10048_CONF_TS1, 0x07 },
@@ -765,6 +766,8 @@ static int tda10048_set_frontend(struct dvb_frontend *fe,
/* Enable demod TPS auto detection and begin acquisition */
tda10048_writereg(state, TDA10048_AUTO, 0x57);
+ /* trigger cber and vber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x3B);
return 0;
}
@@ -830,12 +833,27 @@ static int tda10048_read_status(struct dvb_frontend
*fe, fe_status_t *status)
static int tda10048_read_ber(struct dvb_frontend *fe, u32 *ber)
{
struct tda10048_state *state = fe->demodulator_priv;
+ static u32 cber_current;
+ u32 cber_nmax;
+ u64 cber_tmp;
dprintk(1, "%s()\n", __func__);
- /* TODO: A reset may be required here */
- *ber = tda10048_readreg(state, TDA10048_CBER_MSB) << 8 |
- tda10048_readreg(state, TDA10048_CBER_LSB);
+ /* update cber on interrupt */
+ if (tda10048_readreg(state, TDA10048_SOFT_IT_C3) & 0x01) {
+ cber_tmp = tda10048_readreg(state, TDA10048_CBER_MSB) << 8 |
+ tda10048_readreg(state, TDA10048_CBER_LSB);
+ cber_nmax = tda10048_readreg(state, TDA10048_CBER_NMAX_MSB) <<
8 |
+ tda10048_readreg(state, TDA10048_CBER_NMAX_LSB);
+ cber_tmp *= 1;
+ cber_tmp *= 2;
+ cber_tmp = div_u64(cber_tmp, (cber_nmax * 32) + 1);
+ cber_current = (u32)cber_tmp;
+ /* retrigger cber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x39);
+ }
+ /* actual cber is (*ber)/1e8 */
+ *ber = cber_current;
return 0;
}
--
1.6.3.3
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Philips/NXP channel decoders
Hello, I am new on this list and I would like to help with my support. I know rather well the Philips/NXP channel demodulators/decoders (TDA10023/24, TDA10046/A, TDA10048) as I've had to support them for a while. I am starting first in diving into the tda10048 driver (DVB-T) to become familiar with the API. In case you know some existing issues, please report them to me, I would be glad to investigate and help. Last but not least, I don't have any hardware yet, is it blocking to eventually send patches ? Thanks. Regards. -- Guillaume -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
