Skip to contentSkip to conversation

correct implementation of FE_READ_UNCORRECTED_BLOCKS

DISCUSSION Aleksandr V. Piskunov 2 participants 4 messages Aug 2, 2009 Media (V4L/DVB)

lore
Share & tools
lore

Aleksandr V. Piskunov

author
#0 lore raw

DVB API documentation says:
"This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime.... Note that the counter will wrap to zero after its maximum count has been reached.

author
#1 lore raw

Oops, sent it way too fast. Anyway.

DVB API documentation says:
"This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime.... Note that the counter will wrap to zero after its maximum count has been reached."

Does it mean that correct implementation of frontend driver should keep its own counter of UNC blocks and increment it every time hardware reports such block?

Quoted 1 line

From what I see, a lot of current frontend drivers simply dump a value

from some hardware register. For example zl10353 I got here reports some N unc blocks and then gets back to reporting zero.

#2 lore raw
Quoted 10 lines · Aleksandr V. Piskunov

Oops, sent it way too fast. Anyway.

DVB API documentation says:
"This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime.... Note that the counter will wrap to zero after its maximum count has been reached."

Does it mean that correct implementation of frontend driver should keep its own counter of UNC blocks and increment it every time hardware reports such block?

No, but a frontend driver may wish to keep a software counter that is wider than the hardware register counter, in case the hardware register rolls over too frequently.

Quoted 3 lines
Quoted 1 line

From what I see, a lot of current frontend drivers simply dump a value

from some hardware register. For example zl10353 I got here reports some N unc blocks and then gets back to reporting zero.

To support the use case of multiple user apps trying to collect UNC block statistics, the driver should not zero out the UNC block counter when read. If the hardware zeros it automatically, then one probably should maintain a software counter in the driver.

Regards,
Andy

author
#3 lore raw
Quoted 17 lines · Andy Walls
Quoted 10 lines · Aleksandr V. Piskunov

Oops, sent it way too fast. Anyway.

DVB API documentation says:
"This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime.... Note that the counter will wrap to zero after its maximum count has been reached."

Does it mean that correct implementation of frontend driver should keep its own counter of UNC blocks and increment it every time hardware reports such block?

No, but a frontend driver may wish to keep a software counter that is wider than the hardware register counter, in case the hardware register rolls over too frequently.

Quoted 9 lines
Quoted 3 lines
Quoted 1 line

From what I see, a lot of current frontend drivers simply dump a value

from some hardware register. For example zl10353 I got here reports some N unc blocks and then gets back to reporting zero.

To support the use case of multiple user apps trying to collect UNC block statistics, the driver should not zero out the UNC block counter when read. If the hardware zeros it automatically, then one probably should maintain a software counter in the driver.

Here is a patch that makes zl10353 a bit more DVB API compliant:
FE_READ_UNCORRECTED_BLOCKS - keep a counter of UNC blocks FE_GET_FRONTEND - return last set frequency instead of zero

Signed-off-by Aleksandr V. Piskunov <[email protected]>
linux/drivers/media/dvb/frontends/zl10353.c 2009-08-02 16:03:00.305465369 +0300 renamed from linux/drivers/media/dvb/frontends/zl10353.c.orig 2009-08-02 15:38:28.133464216 +0300 +11 -3
@@ -39,6 +39,8 @@ struct zl10353_state {
        struct zl10353_config config;
 
        enum fe_bandwidth bandwidth;
+       u32 ucblocks;
+       u32 frequency;
 };
 
 static int debug;

@@ -204,6 +206,8 @@ static int zl10353_set_parameters(struct
        u16 tps = 0;
        struct dvb_ofdm_parameters *op = &param->u.ofdm;
 
+       state->frequency = param->frequency;
+
        zl10353_single_write(fe, RESET, 0x80);
        udelay(200);
        zl10353_single_write(fe, 0xEA, 0x01);

@@ -469,7 +473,7 @@ static int zl10353_get_parameters(struct
                break;
        }
 
-       param->frequency = 0;
+       param->frequency = state->frequency;
        op->bandwidth = state->bandwidth;
        param->inversion = INVERSION_AUTO;
 

@@ -549,9 +553,13 @@ static int zl10353_read_snr(struct dvb_f
 static int zl10353_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
 {
        struct zl10353_state *state = fe->demodulator_priv;
+       u32 ubl = 0;
+
+       ubl = zl10353_read_register(state, RS_UBC_1) << 8 |
+             zl10353_read_register(state, RS_UBC_0);
 
-       *ucblocks = zl10353_read_register(state, RS_UBC_1) << 8 |
-                   zl10353_read_register(state, RS_UBC_0);
+       state->ucblocks += ubl;
+       *ucblocks = state->ucblocks;
 
        return 0;
 }