Re: [PATCH] af9013 frontend tuner bus lock

Re: [PATCH] af9013 frontend tuner bus lock

[Josu Lazkano]

2011/9/28 tvboxspy <tvboxspy@gmail.com>:
> Frontend bus lock for af9015 devices.
>
> Last week, I aqcuired a dual KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
>
> The lock is intended for dual frontends that share the same tuner I2C address
> to stop either frontend sending data while any gate is open. The patch
> should have no effect on single devices or multiple single devices, well
> not on the ones I have!
>
> It also delays read_status call backs being sent while either gate is open, a
> mostly like cause of corruption.
>
> The lock also covers the attachment process of the tuner in case there is any
> race condition, although unlikely.
>
> Points about troubles with Myth TV;
> Streaming corruptions are more likely to appear from the I2C noise generated
> from setting either frontend. Afatech love their bits as bytes:-)
>
> Latest version of Myth TV appears to have a bug where you can't select the second
> frontend independently and when it does it tunes to the same frequency as
> the first frontend!
>
> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
> ---
>  drivers/media/dvb/dvb-usb/af9015.c   |    7 ++++++-
>  drivers/media/dvb/frontends/af9013.c |   13 ++++++++++++-
>  drivers/media/dvb/frontends/af9013.h |    5 +++--
>  3 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
> index c6c275b..0089858 100644
> --- a/drivers/media/dvb/dvb-usb/af9015.c
> +++ b/drivers/media/dvb/dvb-usb/af9015.c
> @@ -43,6 +43,7 @@ MODULE_PARM_DESC(remote, "select remote");
>  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
>  static DEFINE_MUTEX(af9015_usb_mutex);
> +static DEFINE_MUTEX(af9015_fe_mutex);
>
>  static struct af9015_config af9015_config;
>  static struct dvb_usb_device_properties af9015_properties[3];
> @@ -1114,7 +1115,7 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
>
>        /* attach demodulator */
>        adap->fe_adap[0].fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id],
> -               &adap->dev->i2c_adap);
> +               &adap->dev->i2c_adap, &af9015_fe_mutex);
>
>        return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
>  }
> @@ -1187,6 +1188,9 @@ static int af9015_tuner_attach(struct dvb_usb_adapter *adap)
>        int ret;
>        deb_info("%s:\n", __func__);
>
> +       if (mutex_lock_interruptible(&af9015_fe_mutex) < 0)
> +               return -EAGAIN;
> +
>        switch (af9015_af9013_config[adap->id].tuner) {
>        case AF9013_TUNER_MT2060:
>        case AF9013_TUNER_MT2060_2:
> @@ -1242,6 +1246,7 @@ static int af9015_tuner_attach(struct dvb_usb_adapter *adap)
>                err("Unknown tuner id:%d",
>                        af9015_af9013_config[adap->id].tuner);
>        }
> +       mutex_unlock(&af9015_fe_mutex);
>        return ret;
>  }
>
> diff --git a/drivers/media/dvb/frontends/af9013.c b/drivers/media/dvb/frontends/af9013.c
> index 345311c..b220a87 100644
> --- a/drivers/media/dvb/frontends/af9013.c
> +++ b/drivers/media/dvb/frontends/af9013.c
> @@ -50,6 +50,7 @@ struct af9013_state {
>        u16 snr;
>        u32 frequency;
>        unsigned long next_statistics_check;
> +       struct mutex *fe_mutex;
>  };
>
>  static u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 0xff };
> @@ -630,9 +631,14 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
>        state->frequency = params->frequency;
>
>        /* program tuner */
> +       if (mutex_lock_interruptible(state->fe_mutex) < 0)
> +               return -EAGAIN;
> +
>        if (fe->ops.tuner_ops.set_params)
>                fe->ops.tuner_ops.set_params(fe, params);
>
> +       mutex_unlock(state->fe_mutex);
> +
>        /* program CFOE coefficients */
>        ret = af9013_set_coeff(state, params->u.ofdm.bandwidth);
>        if (ret)
> @@ -1038,6 +1044,9 @@ static int af9013_read_status(struct dvb_frontend *fe, fe_status_t *status)
>        u8 tmp;
>        *status = 0;
>
> +       if (mutex_lock_interruptible(state->fe_mutex) < 0)
> +               return -EAGAIN;
> +
>        /* MPEG2 lock */
>        ret = af9013_read_reg_bits(state, 0xd507, 6, 1, &tmp);
>        if (ret)
> @@ -1086,6 +1095,7 @@ static int af9013_read_status(struct dvb_frontend *fe, fe_status_t *status)
>        ret = af9013_update_statistics(fe);
>
>  error:
> +       mutex_unlock(state->fe_mutex);
>        return ret;
>  }
>
> @@ -1446,7 +1456,7 @@ static void af9013_release(struct dvb_frontend *fe)
>  static struct dvb_frontend_ops af9013_ops;
>
>  struct dvb_frontend *af9013_attach(const struct af9013_config *config,
> -       struct i2c_adapter *i2c)
> +       struct i2c_adapter *i2c, struct mutex *fe_mutex)
>  {
>        int ret;
>        struct af9013_state *state = NULL;
> @@ -1459,6 +1469,7 @@ struct dvb_frontend *af9013_attach(const struct af9013_config *config,
>
>        /* setup the state */
>        state->i2c = i2c;
> +       state->fe_mutex = fe_mutex;
>        memcpy(&state->config, config, sizeof(struct af9013_config));
>
>        /* download firmware */
> diff --git a/drivers/media/dvb/frontends/af9013.h b/drivers/media/dvb/frontends/af9013.h
> index e53d873..95c966a 100644
> --- a/drivers/media/dvb/frontends/af9013.h
> +++ b/drivers/media/dvb/frontends/af9013.h
> @@ -96,10 +96,11 @@ struct af9013_config {
>  #if defined(CONFIG_DVB_AF9013) || \
>        (defined(CONFIG_DVB_AF9013_MODULE) && defined(MODULE))
>  extern struct dvb_frontend *af9013_attach(const struct af9013_config *config,
> -       struct i2c_adapter *i2c);
> +       struct i2c_adapter *i2c, struct mutex *fe_mutex);
>  #else
>  static inline struct dvb_frontend *af9013_attach(
> -const struct af9013_config *config, struct i2c_adapter *i2c)
> +       const struct af9013_config *config, struct i2c_adapter *i2,
> +               struct mutex *fe_mutex)
>  {
>        printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
>        return NULL;
> --
> 1.7.5.4
>
>

Thanks!!! I have same device, I apply the patch to the s2-liplianin
branch and it works well.

Two days on MythTV and there is no pixeled playback and not I2C
messges on dmesg.

Thank you very much, I was waiting long for this fix.

Kind regards.

-- 
Josu Lazkano

Re: [PATCH] af9013 frontend tuner bus lock

[Jason Hecker]

I have had some luck with this patch.  I am still getting fouled
recordings with tuner A but it's not consistent.  I have yet to
ascertain if the problem occurs depending on the order of tuning to
have both tuners recording different frquencies at the same time, ie
Tuner B then Tuner A or vice versa.

Malcolm, did you say there was a MythTV tubing bug?  Do you have an
URL for the bug if it has been reported?

I fear I might have a multi-layered problem - not only the Afatech
tuners but perhaps some PCI issue too.  It doesn't help if MythTV
isn't doing the right thing either.

On 5 October 2011 06:28, Josu Lazkano <josu.lazkano@gmail.com> wrote:
> 2011/9/28 tvboxspy <tvboxspy@gmail.com>:
>> Frontend bus lock for af9015 devices.
>>
>> Last week, I aqcuired a dual KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
>>
>> The lock is intended for dual frontends that share the same tuner I2C address
>> to stop either frontend sending data while any gate is open. The patch
>> should have no effect on single devices or multiple single devices, well
>> not on the ones I have!
>>
>> It also delays read_status call backs being sent while either gate is open, a
>> mostly like cause of corruption.
>>
>> The lock also covers the attachment process of the tuner in case there is any
>> race condition, although unlikely.
>>
>> Points about troubles with Myth TV;
>> Streaming corruptions are more likely to appear from the I2C noise generated
>> from setting either frontend. Afatech love their bits as bytes:-)
>>
>> Latest version of Myth TV appears to have a bug where you can't select the second
>> frontend independently and when it does it tunes to the same frequency as
>> the first frontend!
>>
>> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
>> ---
>>  drivers/media/dvb/dvb-usb/af9015.c   |    7 ++++++-
>>  drivers/media/dvb/frontends/af9013.c |   13 ++++++++++++-
>>  drivers/media/dvb/frontends/af9013.h |    5 +++--
>>  3 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
>> index c6c275b..0089858 100644
>> --- a/drivers/media/dvb/dvb-usb/af9015.c
>> +++ b/drivers/media/dvb/dvb-usb/af9015.c
>> @@ -43,6 +43,7 @@ MODULE_PARM_DESC(remote, "select remote");
>>  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>>
>>  static DEFINE_MUTEX(af9015_usb_mutex);
>> +static DEFINE_MUTEX(af9015_fe_mutex);
>>
>>  static struct af9015_config af9015_config;
>>  static struct dvb_usb_device_properties af9015_properties[3];
>> @@ -1114,7 +1115,7 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
>>
>>        /* attach demodulator */
>>        adap->fe_adap[0].fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id],
>> -               &adap->dev->i2c_adap);
>> +               &adap->dev->i2c_adap, &af9015_fe_mutex);
>>
>>        return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
>>  }
>> @@ -1187,6 +1188,9 @@ static int af9015_tuner_attach(struct dvb_usb_adapter *adap)
>>        int ret;
>>        deb_info("%s:\n", __func__);
>>
>> +       if (mutex_lock_interruptible(&af9015_fe_mutex) < 0)
>> +               return -EAGAIN;
>> +
>>        switch (af9015_af9013_config[adap->id].tuner) {
>>        case AF9013_TUNER_MT2060:
>>        case AF9013_TUNER_MT2060_2:
>> @@ -1242,6 +1246,7 @@ static int af9015_tuner_attach(struct dvb_usb_adapter *adap)
>>                err("Unknown tuner id:%d",
>>                        af9015_af9013_config[adap->id].tuner);
>>        }
>> +       mutex_unlock(&af9015_fe_mutex);
>>        return ret;
>>  }
>>
>> diff --git a/drivers/media/dvb/frontends/af9013.c b/drivers/media/dvb/frontends/af9013.c
>> index 345311c..b220a87 100644
>> --- a/drivers/media/dvb/frontends/af9013.c
>> +++ b/drivers/media/dvb/frontends/af9013.c
>> @@ -50,6 +50,7 @@ struct af9013_state {
>>        u16 snr;
>>        u32 frequency;
>>        unsigned long next_statistics_check;
>> +       struct mutex *fe_mutex;
>>  };
>>
>>  static u8 regmask[8] = { 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f, 0xff };
>> @@ -630,9 +631,14 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
>>        state->frequency = params->frequency;
>>
>>        /* program tuner */
>> +       if (mutex_lock_interruptible(state->fe_mutex) < 0)
>> +               return -EAGAIN;
>> +
>>        if (fe->ops.tuner_ops.set_params)
>>                fe->ops.tuner_ops.set_params(fe, params);
>>
>> +       mutex_unlock(state->fe_mutex);
>> +
>>        /* program CFOE coefficients */
>>        ret = af9013_set_coeff(state, params->u.ofdm.bandwidth);
>>        if (ret)
>> @@ -1038,6 +1044,9 @@ static int af9013_read_status(struct dvb_frontend *fe, fe_status_t *status)
>>        u8 tmp;
>>        *status = 0;
>>
>> +       if (mutex_lock_interruptible(state->fe_mutex) < 0)
>> +               return -EAGAIN;
>> +
>>        /* MPEG2 lock */
>>        ret = af9013_read_reg_bits(state, 0xd507, 6, 1, &tmp);
>>        if (ret)
>> @@ -1086,6 +1095,7 @@ static int af9013_read_status(struct dvb_frontend *fe, fe_status_t *status)
>>        ret = af9013_update_statistics(fe);
>>
>>  error:
>> +       mutex_unlock(state->fe_mutex);
>>        return ret;
>>  }
>>
>> @@ -1446,7 +1456,7 @@ static void af9013_release(struct dvb_frontend *fe)
>>  static struct dvb_frontend_ops af9013_ops;
>>
>>  struct dvb_frontend *af9013_attach(const struct af9013_config *config,
>> -       struct i2c_adapter *i2c)
>> +       struct i2c_adapter *i2c, struct mutex *fe_mutex)
>>  {
>>        int ret;
>>        struct af9013_state *state = NULL;
>> @@ -1459,6 +1469,7 @@ struct dvb_frontend *af9013_attach(const struct af9013_config *config,
>>
>>        /* setup the state */
>>        state->i2c = i2c;
>> +       state->fe_mutex = fe_mutex;
>>        memcpy(&state->config, config, sizeof(struct af9013_config));
>>
>>        /* download firmware */
>> diff --git a/drivers/media/dvb/frontends/af9013.h b/drivers/media/dvb/frontends/af9013.h
>> index e53d873..95c966a 100644
>> --- a/drivers/media/dvb/frontends/af9013.h
>> +++ b/drivers/media/dvb/frontends/af9013.h
>> @@ -96,10 +96,11 @@ struct af9013_config {
>>  #if defined(CONFIG_DVB_AF9013) || \
>>        (defined(CONFIG_DVB_AF9013_MODULE) && defined(MODULE))
>>  extern struct dvb_frontend *af9013_attach(const struct af9013_config *config,
>> -       struct i2c_adapter *i2c);
>> +       struct i2c_adapter *i2c, struct mutex *fe_mutex);
>>  #else
>>  static inline struct dvb_frontend *af9013_attach(
>> -const struct af9013_config *config, struct i2c_adapter *i2c)
>> +       const struct af9013_config *config, struct i2c_adapter *i2,
>> +               struct mutex *fe_mutex)
>>  {
>>        printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
>>        return NULL;
>> --
>> 1.7.5.4
>>
>>
>
> Thanks!!! I have same device, I apply the patch to the s2-liplianin
> branch and it works well.
>
> Two days on MythTV and there is no pixeled playback and not I2C
> messges on dmesg.
>
> Thank you very much, I was waiting long for this fix.
>
> Kind regards.
>
> --
> Josu Lazkano
>

Re: [PATCH] af9013 frontend tuner bus lock

[Malcolm Priestley]

On Wed, 2011-10-05 at 07:44 +1100, Jason Hecker wrote:
> I have had some luck with this patch.  I am still getting fouled
> recordings with tuner A but it's not consistent.  I have yet to
> ascertain if the problem occurs depending on the order of tuning to
> have both tuners recording different frquencies at the same time, ie
> Tuner B then Tuner A or vice versa.

Which Firmware are your using?

I am having some problems with firmware version:5.1.0
I have gone back to using firmware version:4.95.0 no problems at all.

> 
> Malcolm, did you say there was a MythTV tubing bug?  
Yes, sometimes tries to tune to same frequency as the other frontend for
a different channel.

> Do you have an
> URL for the bug if it has been reported?
No

> 
> I fear I might have a multi-layered problem - not only the Afatech
> tuners but perhaps some PCI issue too.  It doesn't help if MythTV
> isn't doing the right thing either.
> 
Yes, because it is also happening with other duo devices on Myth TV
0.24.1

So far Myth TV 0.23.0 on Kernel 2.6.35 seems consistently stable.

Regards

Malcolm

Re: [PATCH] af9013 frontend tuner bus lock

[Jason Hecker]

> Which Firmware are your using?

4.95

> Yes, because it is also happening with other duo devices on Myth TV
> 0.24.1

OK, well that is what I am using so I guess I am stuck until it's fixed.

Josu what software and versions are you using?

Re: [PATCH] af9013 frontend tuner bus lock

[Josu Lazkano]

2011/10/5 Jason Hecker <jwhecker@gmail.com>:
>> Which Firmware are your using?
>
> 4.95
>
>> Yes, because it is also happening with other duo devices on Myth TV
>> 0.24.1
>
> OK, well that is what I am using so I guess I am stuck until it's fixed.
>
> Josu what software and versions are you using?
>

Hello, I am using this firmware:
http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw

The MythTV version is the 0.24.1-0.0squeeze1 version of
debian-multimedia.org (stable) repository.

This morning I get a little pixeled playback, less than a second.

Best regards.

-- 
Josu Lazkano

Re: [PATCH] af9013 frontend tuner bus lock

[Jason Hecker]

> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw

5.1?  OK, I might eventually try that one too.

> This morning I get a little pixeled playback, less than a second.

OK, mine was fine for a few days then the pixellation started up in earnest.

At the moment my symptoms were always:

TunerA: Tuned - picture good
TunerB: Idle

Tuner B gets tuned, Tuner A starts to pixellate badly.

I am sure this is the case too:

TunerA: Idle
TunerB: Tuned - picture good

Tuner A gets tuned and has a bad recording.  *Never* has Tuner B
suffered from the pixellation in spite of whatever Tuner A is doing!

Anyway, Malcolm has suggested there is a bug lurking in MythTV too
causing problems with dual tuners so it's a bit hard to isolate the
issue.

Re: [PATCH] af9013 frontend tuner bus lock

[Josu Lazkano]

2011/10/6 Jason Hecker <jwhecker@gmail.com>:
>> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw
>
> 5.1?  OK, I might eventually try that one too.
>
>> This morning I get a little pixeled playback, less than a second.
>
> OK, mine was fine for a few days then the pixellation started up in earnest.
>
> At the moment my symptoms were always:
>
> TunerA: Tuned - picture good
> TunerB: Idle
>
> Tuner B gets tuned, Tuner A starts to pixellate badly.
>
> I am sure this is the case too:
>
> TunerA: Idle
> TunerB: Tuned - picture good
>
> Tuner A gets tuned and has a bad recording.  *Never* has Tuner B
> suffered from the pixellation in spite of whatever Tuner A is doing!
>
> Anyway, Malcolm has suggested there is a bug lurking in MythTV too
> causing problems with dual tuners so it's a bit hard to isolate the
> issue.
>

Hello again, I am having more pixeled playback, I don't know how to
explain so I record a video:
http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp

I get this I2C messages:

# tail -f /var/log/messages
Oct  5 20:16:44 htpc kernel: [  534.168957] af9013: I2C read failed reg:d330
Oct  5 20:16:49 htpc kernel: [  538.626152] af9013: I2C read failed reg:d330
Oct  5 21:22:15 htpc kernel: [ 4464.930734] af9013: I2C write failed
reg:d2e2 len:1
Oct  5 21:40:46 htpc kernel: [ 5576.241897] af9013: I2C read failed reg:d2e6
Oct  5 23:07:33 htpc kernel: [10782.852522] af9013: I2C read failed reg:d2e6
Oct  5 23:20:11 htpc kernel: [11540.824515] af9013: I2C read failed reg:d07c
Oct  6 00:11:41 htpc kernel: [14631.122384] af9013: I2C read failed reg:d2e6
Oct  6 00:26:13 htpc kernel: [15502.900549] af9013: I2C read failed reg:d2e6
Oct  6 00:39:58 htpc kernel: [16328.273015] af9013: I2C read failed reg:d330

My signal is this:

(idle)
$ femon -H -a 4
FE: Afatech AF9013 DVB-T (DVBT)
status S     | signal  75% | snr   0% | ber 0 | unc 0 |
status S     | signal  75% | snr   0% | ber 0 | unc 0 |
status S     | signal  75% | snr   0% | ber 0 | unc 0 |
status S     | signal  75% | snr   0% | ber 0 | unc 0 |
status S     | signal  74% | snr   0% | ber 0 | unc 0 |
status S     | signal  74% | snr   0% | ber 0 | unc 0 |

(watching)
$ femon -H -a 5
FE: Afatech AF9013 DVB-T (DVBT)
status SCVYL | signal  74% | snr   0% | ber 142 | unc 319408 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 142 | unc 319408 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 31 | unc 319430 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 31 | unc 319430 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 56 | unc 319519 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 0 | unc 319519 | FE_HAS_LOCK
status SCVYL | signal  74% | snr   0% | ber 0 | unc 319519 | FE_HAS_LOCK

There are lots of ber and unc bits, I have connected the TV to the
same wire and there is a good signal.

Thanks for your help.

Regards.

-- 
Josu Lazkano

Re: [PATCH] af9013 frontend tuner bus lock

[Jason Hecker]

> http://dl.dropbox.com/u/1541853/VID_20111006_004447.3gp

That looks very familiar!  Does it occur on tuner A or B?

> I get this I2C messages:
> # tail -f /var/log/messages
> Oct  5 20:16:44 htpc kernel: [  534.168957] af9013: I2C read failed reg:d330

As far as I know I never had any such messages.  Maybe though the
debugging isn't enabled properly.

> There are lots of ber and unc bits, I have connected the TV to the
> same wire and there is a good signal.

Yes, your TV might have a better receiver though - I have the same
problem, if my TV decoding is OK but the signal is weak then my DVB
cards have problems.  I have solved this signal problem by using
quad-shield cable and F-connectors and proper metal can splitters so
now everything gets a good signal.  I am pretty sure my issues are not
signal related because Tuner A is fine until tuner B is enabled and
tuner B always records a very low error signal (usually not even one
visible error).

Re: [PATCH] af9013 frontend tuner bus lock

[dave cunningham]

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

In message 
<CAL9G6WXX2eGmoT+ozv1F0JQdSV5JPwbB0vn70UL+ghgkLGsYQg@mail.gmail.com>, 
Josu Lazkano wrote

<snip>
>
>I get this I2C messages:
>
># tail -f /var/log/messages
>Oct  5 20:16:44 htpc kernel: [  534.168957] af9013: I2C read failed reg:d330
>Oct  5 20:16:49 htpc kernel: [  538.626152] af9013: I2C read failed reg:d330
>Oct  5 21:22:15 htpc kernel: [ 4464.930734] af9013: I2C write failed
>reg:d2e2 len:1
>Oct  5 21:40:46 htpc kernel: [ 5576.241897] af9013: I2C read failed reg:d2e6
>Oct  5 23:07:33 htpc kernel: [10782.852522] af9013: I2C read failed reg:d2e6
>Oct  5 23:20:11 htpc kernel: [11540.824515] af9013: I2C read failed reg:d07c
>Oct  6 00:11:41 htpc kernel: [14631.122384] af9013: I2C read failed reg:d2e6
>Oct  6 00:26:13 htpc kernel: [15502.900549] af9013: I2C read failed reg:d2e6
>Oct  6 00:39:58 htpc kernel: [16328.273015] af9013: I2C read failed reg:d330
>

I have two af9013 sticks in my mythtv backend. One is a KWorld 399U, the 
other a single tuner Tevion stick.

When I originally setup this system I had major problems with these 
sticks and also a pair of Freecom WT-220U (which worked perfectly in an 
older system - I've since disposed of these).

I was seeing I2C read fails similar to the above.

The system in question has an AMD760G southbridge.

After a lot of googling I came across a post somewhere which said that 
the USB host controller on the 760G is problematic and suggested getting 
a NEC or VIA hub and using this between the DVB sticks and the root hub.

I bought a cheap hub with an NEC chip on and since then (6 months maybe) 
I've had no problems with the system. Having said this I probably don't 
use all three frontends that often (I also have a DVB-S card and this 
takes precedence) though I certainly have on occasion and don't recall 
any problems.

-- 
Dave Cunningham                                  PGP KEY ID: 0xA78636DC

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 177 bytes --]

Re: [PATCH] af9013 frontend tuner bus lock

[Josu Lazkano]

2011/10/6 dave cunningham <ml@upsilon.org.uk>:
> In message
> <CAL9G6WXX2eGmoT+ozv1F0JQdSV5JPwbB0vn70UL+ghgkLGsYQg@mail.gmail.com>, Josu
> Lazkano wrote
>
> <snip>
>>
>> I get this I2C messages:
>>
>> # tail -f /var/log/messages
>> Oct  5 20:16:44 htpc kernel: [  534.168957] af9013: I2C read failed
>> reg:d330
>> Oct  5 20:16:49 htpc kernel: [  538.626152] af9013: I2C read failed
>> reg:d330
>> Oct  5 21:22:15 htpc kernel: [ 4464.930734] af9013: I2C write failed
>> reg:d2e2 len:1
>> Oct  5 21:40:46 htpc kernel: [ 5576.241897] af9013: I2C read failed
>> reg:d2e6
>> Oct  5 23:07:33 htpc kernel: [10782.852522] af9013: I2C read failed
>> reg:d2e6
>> Oct  5 23:20:11 htpc kernel: [11540.824515] af9013: I2C read failed
>> reg:d07c
>> Oct  6 00:11:41 htpc kernel: [14631.122384] af9013: I2C read failed
>> reg:d2e6
>> Oct  6 00:26:13 htpc kernel: [15502.900549] af9013: I2C read failed
>> reg:d2e6
>> Oct  6 00:39:58 htpc kernel: [16328.273015] af9013: I2C read failed
>> reg:d330
>>
>
> I have two af9013 sticks in my mythtv backend. One is a KWorld 399U, the
> other a single tuner Tevion stick.
>
> When I originally setup this system I had major problems with these sticks
> and also a pair of Freecom WT-220U (which worked perfectly in an older
> system - I've since disposed of these).
>
> I was seeing I2C read fails similar to the above.
>
> The system in question has an AMD760G southbridge.
>
> After a lot of googling I came across a post somewhere which said that the
> USB host controller on the 760G is problematic and suggested getting a NEC
> or VIA hub and using this between the DVB sticks and the root hub.
>
> I bought a cheap hub with an NEC chip on and since then (6 months maybe)
> I've had no problems with the system. Having said this I probably don't use
> all three frontends that often (I also have a DVB-S card and this takes
> precedence) though I certainly have on occasion and don't recall any
> problems.
>
> --
> Dave Cunningham                                  PGP KEY ID: 0xA78636DC
>

Thanks Dave, I have a MCP79 nvidia USB controller:

$ lspci | grep USB
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
Controller (rev b1)
00:06.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1
Controller (rev b1)
00:06.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0
Controller (rev b1)

When I add a USB hub it can not boot, the system stop on boot. I can
not change the system board. Need I some extra configuration on BIOS?
I will appreciate any help, I have no experience on system
performance.

Thanks for all your help.

Regards.

-- 
Josu Lazkano

Re: [PATCH] af9013 frontend tuner bus lock

[Jason Hecker]

> Thanks Dave, I have a MCP79 nvidia USB controller:

I too have:

USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0
Controller (rev a1)

BUT I have never had boot trouble if I plugged in a 4-port hub.

I think Dave means that you need to buy a USB to PCI or PCIe card.
Avoid VIA if you can and try to get an NEC or Intel based card.

> not change the system board. Need I some extra configuration on BIOS?

Do you have the latest BIOS installed?  Try that and reset to safe
defaults.  I think AMI Bios (if you have it) has hidden performance
menus if you type in CTRL-F1 or SHIFT-F1 in the BIOS menu.

My Afatech dual tuners are the Leadtek DS2000
(http://www.linuxtv.org/wiki/index.php/Leadtek_WinFast_DTV2000DS)
which are on a PCI card.  They have the same USB tuner parts you have
plus a VIA USB->PCI bus chip.

My next step is to once again try the PID filter and maybe disable USB
sleeping/powerdown.

Someone on another mailing list is having similar problems in
Windows(!) and found the errors were minimal if PCI latency was set to
96.

I am beginning to think Afatech is just crappy.

Jason

Re: [PATCH] af9013 frontend tuner bus lock

[Malcolm Priestley]

On Thu, 2011-10-06 at 01:12 +0200, Josu Lazkano wrote:
> 2011/10/6 Jason Hecker <jwhecker@gmail.com>:
> >> http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw
> >
> > 5.1?  OK, I might eventually try that one too.
> >

> Oct  5 21:40:46 htpc kernel: [ 5576.241897] af9013: I2C read failed reg:d2e6
> Oct  5 23:07:33 htpc kernel: [10782.852522] af9013: I2C read failed reg:d2e6
> Oct  5 23:20:11 htpc kernel: [11540.824515] af9013: I2C read failed reg:d07c
> Oct  6 00:11:41 htpc kernel: [14631.122384] af9013: I2C read failed reg:d2e6
> Oct  6 00:26:13 htpc kernel: [15502.900549] af9013: I2C read failed reg:d2e6
> Oct  6 00:39:58 htpc kernel: [16328.273015] af9013: I2C read failed reg:d330
> 
> My signal is this:
> 
> (idle)
> $ femon -H -a 4
> FE: Afatech AF9013 DVB-T (DVBT)
> status S     | signal  75% | snr   0% | ber 0 | unc 0 |
> status S     | signal  75% | snr   0% | ber 0 | unc 0 |
> status S     | signal  75% | snr   0% | ber 0 | unc 0 |
> status S     | signal  75% | snr   0% | ber 0 | unc 0 |
> status S     | signal  74% | snr   0% | ber 0 | unc 0 |
> status S     | signal  74% | snr   0% | ber 0 | unc 0 |
> 
> (watching)
> $ femon -H -a 5
> FE: Afatech AF9013 DVB-T (DVBT)
> status SCVYL | signal  74% | snr   0% | ber 142 | unc 319408 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 142 | unc 319408 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 31 | unc 319430 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 31 | unc 319430 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 56 | unc 319519 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 0 | unc 319519 | FE_HAS_LOCK
> status SCVYL | signal  74% | snr   0% | ber 0 | unc 319519 | FE_HAS_LOCK
> 
> There are lots of ber and unc bits, I have connected the TV to the
> same wire and there is a good signal.
Using femon bypasses the bus lock, so changes will have to be made to
the patch.

At the moment it looks like not much change.  Unless the corruption in
the first frontend can be solved.

Regards

Malcolm

[PATCH] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

Try this patch, it should stop start up corruption on the same frontend.

It is a missing section of code that checks the frontend is ready to go.

However, it will not stop corruptions on frontend A.

af9013 Extended monitoring in set_front.

---
 drivers/media/dvb/frontends/af9013.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/af9013.c b/drivers/media/dvb/frontends/af9013.c
index b220a87..347c187 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -622,8 +622,9 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
 	struct dvb_frontend_parameters *params)
 {
 	struct af9013_state *state = fe->demodulator_priv;
-	int ret;
+	int ret, i;
 	u8 auto_mode; /* auto set TPS */
+	u8 v1, v2;
 
 	deb_info("%s: freq:%d bw:%d\n", __func__, params->frequency,
 		params->u.ofdm.bandwidth);
@@ -694,6 +695,19 @@ static int af9013_set_frontend(struct dvb_frontend *fe,
 	if (ret)
 		goto error;
 
+	for (i = 0; i < 27; ++i) {
+		ret = af9013_read_reg(state, 0x9bc2, &v1);
+		if (ret)
+			break;
+		ret = af9013_read_reg(state, 0xd330, &v2);
+		if (ret)
+			break;
+		if (v1 == 0 && v2 > 0)
+				break;
+		msleep(40);
+	}
+
+
 error:
 	return ret;
 }
-- 
1.7.5.4

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Jason Hecker]

> Try this patch, it should stop start up corruption on the same frontend.

Thanks.  I'll try it today.

Have you been able to reproduce any of the corruption issues I and
others are having?

I noticed last night some recordings on the same card had different
levels of corruption depending on the order of tuning

Tuner A then tuner B : Tuner A was heavily corrupted.  Tuner B was a fine.
Tuner B then tuner A: Tuner A had a small corruption every few seconds
and the show was watchable, Tuner B was fine.

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

On Sat, 2011-10-08 at 09:46 +1100, Jason Hecker wrote:
> > Try this patch, it should stop start up corruption on the same frontend.
> 
> Thanks.  I'll try it today.
> 
> Have you been able to reproduce any of the corruption issues I and
> others are having?
Yes , I left it recording various programmes overnight, but the symptoms
come and go.

> 
> I noticed last night some recordings on the same card had different
> levels of corruption depending on the order of tuning
> 
> Tuner A then tuner B : Tuner A was heavily corrupted.  Tuner B was a fine.
> Tuner B then tuner A: Tuner A had a small corruption every few seconds
> and the show was watchable, Tuner B was fine.

It seems like a lagging effect, as if the devices firmware is slowing
down.

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Josu Lazkano]

2011/10/8 Jason Hecker <jwhecker@gmail.com>:
>> Try this patch, it should stop start up corruption on the same frontend.
>
> Thanks.  I'll try it today.
>
> Have you been able to reproduce any of the corruption issues I and
> others are having?
>
> I noticed last night some recordings on the same card had different
> levels of corruption depending on the order of tuning
>
> Tuner A then tuner B : Tuner A was heavily corrupted.  Tuner B was a fine.
> Tuner B then tuner A: Tuner A had a small corruption every few seconds
> and the show was watchable, Tuner B was fine.
>

Thanks again, I try the patch and it works well last nigh. This
morning one tuner is getting pixeled images and the other can not
LOCK.

This is the kernel messages:

# tail /var/log/messages
Oct  8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed
Oct  8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed
Oct  8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed
Oct  8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed
Oct  8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed
Oct  8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed
Oct  8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed
Oct  8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed
Oct  8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed
Oct  8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed

I try to increase the signal timeout from 1000 to 2000 ms and the
tuning timeout from 3000 to 6000 ms on mythbackend.

Which will be the best value for the Kworld 399U?

Thank for your great work on this device.

Best regards!

-- 
Josu Lazkano

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

On Sat, 2011-10-08 at 15:13 +0200, Josu Lazkano wrote:
> 2011/10/8 Jason Hecker <jwhecker@gmail.com>:
> >> Try this patch, it should stop start up corruption on the same frontend.
> >
> > Thanks.  I'll try it today.
> >
> > Have you been able to reproduce any of the corruption issues I and
> > others are having?
> >
> > I noticed last night some recordings on the same card had different
> > levels of corruption depending on the order of tuning
> >
> > Tuner A then tuner B : Tuner A was heavily corrupted.  Tuner B was a fine.
> > Tuner B then tuner A: Tuner A had a small corruption every few seconds
> > and the show was watchable, Tuner B was fine.
> >
> 
> Thanks again, I try the patch and it works well last nigh. This
> morning one tuner is getting pixeled images and the other can not
> LOCK.
> 
> This is the kernel messages:
> 
> # tail /var/log/messages
> Oct  8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed
> Oct  8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed
> Oct  8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed
> Oct  8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed
> Oct  8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed
> Oct  8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed
> Oct  8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed
> Oct  8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed
> Oct  8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed
> Oct  8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed
> 
> I try to increase the signal timeout from 1000 to 2000 ms and the
> tuning timeout from 3000 to 6000 ms on mythbackend.
> 
I have left these at the default settings

Which kernels are you all running?

uname -rv

I think replicate your systems on my test pc.

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Josu Lazkano]

2011/10/8 Malcolm Priestley <tvboxspy@gmail.com>:
> On Sat, 2011-10-08 at 15:13 +0200, Josu Lazkano wrote:
>> 2011/10/8 Jason Hecker <jwhecker@gmail.com>:
>> >> Try this patch, it should stop start up corruption on the same frontend.
>> >
>> > Thanks.  I'll try it today.
>> >
>> > Have you been able to reproduce any of the corruption issues I and
>> > others are having?
>> >
>> > I noticed last night some recordings on the same card had different
>> > levels of corruption depending on the order of tuning
>> >
>> > Tuner A then tuner B : Tuner A was heavily corrupted.  Tuner B was a fine.
>> > Tuner B then tuner A: Tuner A had a small corruption every few seconds
>> > and the show was watchable, Tuner B was fine.
>> >
>>
>> Thanks again, I try the patch and it works well last nigh. This
>> morning one tuner is getting pixeled images and the other can not
>> LOCK.
>>
>> This is the kernel messages:
>>
>> # tail /var/log/messages
>> Oct  8 14:16:06 htpc kernel: [45025.328902] mxl5005s I2C write failed
>> Oct  8 14:16:06 htpc kernel: [45025.333147] mxl5005s I2C write failed
>> Oct  8 14:16:06 htpc kernel: [45025.333637] mxl5005s I2C write failed
>> Oct  8 14:16:06 htpc kernel: [45025.490524] mxl5005s I2C write failed
>> Oct  8 14:16:06 htpc kernel: [45025.491014] mxl5005s I2C write failed
>> Oct  8 14:16:08 htpc kernel: [45027.642858] mxl5005s I2C write failed
>> Oct  8 14:16:08 htpc kernel: [45027.647477] mxl5005s I2C write failed
>> Oct  8 14:16:08 htpc kernel: [45027.647970] mxl5005s I2C write failed
>> Oct  8 14:16:09 htpc kernel: [45027.806477] mxl5005s I2C write failed
>> Oct  8 14:16:09 htpc kernel: [45027.806969] mxl5005s I2C write failed
>>
>> I try to increase the signal timeout from 1000 to 2000 ms and the
>> tuning timeout from 3000 to 6000 ms on mythbackend.
>>
> I have left these at the default settings
>
> Which kernels are you all running?
>
> uname -rv
>
> I think replicate your systems on my test pc.
>
>

Hello again, this is my kernel:

$ uname -rv
2.6.32-5-686 #1 SMP Fri Sep 9 20:51:05 UTC 2011

This is a Debian Squeeze system.

Regards.

-- 
Josu Lazkano

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Antti Palosaari]

I have been following that discussion and hoping you would finally find 
out the reason.

But I want to point out few things;
* .set_frontend() is called only when channel changed
* .set_params() is called only when channel changed
* there is no I2C traffic for tuner after channel changed
* there is I2C traffic to tuner only when channel is changed

Since generally changes to .set_frontend() will not have effect in 
normal use, when both devices are already streaming. Only in case of 
lock is missed and re-tune initialized or channel changed.

regards
Antti


-- 
http://palosaari.fi/

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Jason Hecker]

> Which kernels are you all running?

2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Antti Palosaari]

On 10/08/2011 11:05 PM, Jason Hecker wrote:
>> Which kernels are you all running?
>
> 2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)

Have you tried other USB-cable or connect it directly to the mobo USB port.

I just used one af9015 + 2x mxl5007t and got some streaming corruptions. 
I was WTF. Switched to af9015 + 2x mxl5005s since it is device I usually 
have used. Still errors. Then I commented out remote controller polling 
and all status polling from drivers. Still some stream corruptions. 
Finally I realized I have other USB-cable than normally. Plugged device 
directly to the mobo USB and now both tuners are streaming same time 
without errors.

Antti


-- 
http://palosaari.fi/

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

On Mon, 2011-10-10 at 22:31 +0300, Antti Palosaari wrote:
> On 10/08/2011 11:05 PM, Jason Hecker wrote:
> >> Which kernels are you all running?
> >
> > 2.6.38-11-generic #50-Ubuntu SMP (Mythbuntu 11.04)
> 
> Have you tried other USB-cable or connect it directly to the mobo USB port.
> 
> I just used one af9015 + 2x mxl5007t and got some streaming corruptions. 
> I was WTF. Switched to af9015 + 2x mxl5005s since it is device I usually 
> have used. Still errors. Then I commented out remote controller polling 
> and all status polling from drivers. Still some stream corruptions. 
> Finally I realized I have other USB-cable than normally. Plugged device 
> directly to the mobo USB and now both tuners are streaming same time 
> without errors.

I have just been testing af9015s both 399U and single, along with other
devices on Mythbuntu 11.04 on 2.6.38-11 and getting the same corruption.

Playing with Kaffeine or Mplayer all the devices are fine on the same
system.

This is very strange!

At the moment, I am going step by step what Myth TV is sending to the
devices.

Regards 

Malcolm

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Jason Hecker]

> Playing with Kaffeine or Mplayer all the devices are fine on the same
> system.

Right, admittedly most of my testing has been done with MythTV.  I
recall about a month ago I could also get corruption with mplayer.

> At the moment, I am going step by step what Myth TV is sending to the
> devices.

Great.  If you want I can replicate your tests here to see what I get.

Antti, my AF9015 chips are integrated on PCI so I can't swap cables
(alas, if only this was my problem!)

Cheers
Jason

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Malcolm Priestley]

On Tue, 2011-10-11 at 08:06 +1100, Jason Hecker wrote:
> > Playing with Kaffeine or Mplayer all the devices are fine on the same
> > system.
> 
> Right, admittedly most of my testing has been done with MythTV.  I
> recall about a month ago I could also get corruption with mplayer.
> 
> > At the moment, I am going step by step what Myth TV is sending to the
> > devices.
> 
> Great.  If you want I can replicate your tests here to see what I get.
> 
> Antti, my AF9015 chips are integrated on PCI so I can't swap cables
> (alas, if only this was my problem!)

Jason, do you get firmware loading fails on boot with the PCI device?

There needs to be a delay put in the firmware download of at least 250uS
after each write, but this does not solve the corruption.

I have tried everything, but all of them fail to get rid of the
corruption on the first frontend when the second frontend starts and
then corruptions every 5 seconds or so. These only come through demux on
endpoint 84 and are not caused by any other frontend operations.

Trouble is, on a Nvidia motherboard I have it does not do it at all and
all applications work without any troubles.  This seems to suggest a USB
motherboard driver issue.

However, the frontend lock does make it at least work on Myth TV.

I am continuing to look into it.

Regards

Malcolm

Re: [PATCH] af9013 Extended monitoring in set_frontend.

[Jason Hecker]

> Trouble is, on a Nvidia motherboard I have it does not do it at all and
> all applications work without any troubles.  This seems to suggest a USB
> motherboard driver issue.

Right.  Well, I can say with high confidence that my dual tuner worked
flawlessly for 18 months using Ubuntu's kernel 2.6.32 up until some
update around May.   Some kernel (or other) update apparently made it
all go pear shaped which prompted me to get another card then update
the whole system to try fix the problem - I haven't gone back to an
old 2.6.32 kernel.  So I am wondering if some other non v4l related
patch has affected us all.

> I am continuing to look into it.

OK, well I am still running my system with your two patches, with
corruptions alas, so if you'd like me to independently try stuff out
let me know.

Jason