fc0011: Reduce number of retries

  Now that i2c transfers are fixed, 3 retries are enough.

Signed-off-by: Michael Buesch <m@bues.ch>

---
  

Hi,

On 04/03/2012 12:05 PM, Michael Büsch wrote:
> Now that i2c transfers are fixed, 3 retries are enough.
>
> Signed-off-by: Michael Buesch<m@bues.ch>
>
> ---
>
> Index: linux/drivers/media/common/tuners/fc0011.c
> ===================================================================
> --- linux.orig/drivers/media/common/tuners/fc0011.c	2012-04-03 08:48:39.000000000 +0200
> +++ linux/drivers/media/common/tuners/fc0011.c	2012-04-03 10:44:07.243418827 +0200
> @@ -314,7 +314,7 @@
>   	if (err)
>   		return err;
>   	vco_retries = 0;
> -	while (!(vco_cal&  FC11_VCOCAL_OK)&&  vco_retries<  6) {
> +	while (!(vco_cal&  FC11_VCOCAL_OK)&&  vco_retries<  3) {

Do we need to retry at all?
I2C core layer is responsible to retry is xfer() fails.
If failure is propagated to driver I'd assume:
  - I2C is still buggy by not return -EAGAIN on arbitrary error
  - I2C xfer failed for real.

Look this piece of code from i2c-core.c:

int i2c_transfer()
{
...
                 /* Retry automatically on arbitration loss */
                 orig_jiffies = jiffies;
                 for (ret = 0, try = 0; try <= adap->retries; try++) {
                         ret = adap->algo->master_xfer(adap, msgs, num);
                         if (ret != -EAGAIN)
                                 break;
                         if (time_after(jiffies, orig_jiffies + 
adap->timeout))
                                 break;
                 }
...
}

BR,

David

>   		/* Reset the tuner and try again */
>   		err = fe->callback(priv->i2c, DVB_FRONTEND_COMPONENT_TUNER,
>   				   FC0011_FE_CALLBACK_RESET, priv->addr);
>
>

--
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
  

On Tue, 03 Apr 2012 12:58:16 +0300
David Cohen <david.a.cohen@linux.intel.com> wrote:
> > -	while (!(vco_cal&  FC11_VCOCAL_OK)&&  vco_retries<  6) {
> > +	while (!(vco_cal&  FC11_VCOCAL_OK)&&  vco_retries<  3) {
> 
> Do we need to retry at all?

It is not an i2c retry. It retries the whole device configuration operation
after resetting it.
I shouldn't have mentioned i2c in the commit log, because this really only was
a side effect.
  

On 04/03/2012 01:07 PM, Michael Büsch wrote:
> On Tue, 03 Apr 2012 12:58:16 +0300
> David Cohen<david.a.cohen@linux.intel.com>  wrote:
>>> -	while (!(vco_cal&   FC11_VCOCAL_OK)&&   vco_retries<   6) {
>>> +	while (!(vco_cal&   FC11_VCOCAL_OK)&&   vco_retries<   3) {
>>
>> Do we need to retry at all?
>
> It is not an i2c retry. It retries the whole device configuration operation
> after resetting it.
> I shouldn't have mentioned i2c in the commit log, because this really only was
> a side effect.
>

Hm, got it. :)
--
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
  

On 03.04.2012 12:05, Michael Büsch wrote:
> Now that i2c transfers are fixed, 3 retries are enough.
>
> Signed-off-by: Michael Buesch<m@bues.ch>

Applied, thanks!
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/af9035_experimental

I think I will update original af9035 PULL request soon for the same 
level as af9035_experimental is currently.

regards
Antti
  

On Tue, 03 Apr 2012 18:24:20 +0300
Antti Palosaari <crope@iki.fi> wrote:

> On 03.04.2012 12:05, Michael Büsch wrote:
> > Now that i2c transfers are fixed, 3 retries are enough.
> >
> > Signed-off-by: Michael Buesch<m@bues.ch>
> 
> Applied, thanks!
> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/af9035_experimental
> 
> I think I will update original af9035 PULL request soon for the same 
> level as af9035_experimental is currently.

That's great. The driver really works well for me.

On another thing:
The af9035 driver doesn't look multi-device safe. There are lots of static
variables around that keep device state. So it looks like this will
blow up if multiple devices are present in the system. Unlikely, but still... .
Are there any plans to fix this up?
If not, I'll probably take a look at this. But don't hold your breath.
  

On 03.04.2012 18:33, Michael Büsch wrote:
> On Tue, 03 Apr 2012 18:24:20 +0300
> Antti Palosaari<crope@iki.fi>  wrote:
>
>> On 03.04.2012 12:05, Michael Büsch wrote:
>>> Now that i2c transfers are fixed, 3 retries are enough.
>>>
>>> Signed-off-by: Michael Buesch<m@bues.ch>
>>
>> Applied, thanks!
>> http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/af9035_experimental
>>
>> I think I will update original af9035 PULL request soon for the same
>> level as af9035_experimental is currently.
>
> That's great. The driver really works well for me.
>
> On another thing:
> The af9035 driver doesn't look multi-device safe. There are lots of static
> variables around that keep device state. So it looks like this will
> blow up if multiple devices are present in the system. Unlikely, but still... .
> Are there any plans to fix this up?
> If not, I'll probably take a look at this. But don't hold your breath.

That's true and same applies for many other DVB USB drivers. Main reason 
for current hackish situation is DVB USB core limits. For example priv 
is not available until frontend attach etc. It "just" works even a 
little bit luck. Good example is that sequence counter, if you have 
multiple devices it runs wrongly as all increases same counter. But as a 
firmware does not care sequence numbers it still works. Remote 
controller is other big problem - coming from same limitations. And that 
is not first time these are spoken :)

I have thought to redesign whole DVB USB framework, but as I am too busy 
always I haven't done that. Feel free to start fixing.


regards
Antti
  

On 03.04.2012 18:33, Michael Büsch wrote:
> On another thing:
> The af9035 driver doesn't look multi-device safe. There are lots of static
> variables around that keep device state. So it looks like this will
> blow up if multiple devices are present in the system. Unlikely, but still... .
> Are there any plans to fix this up?
> If not, I'll probably take a look at this. But don't hold your breath.

I fixed what was possible by moving af9033 and af9035 configurations for 
the state. That at least resolves most significant issues - like your 
fc0011 tuner callback.

But there is still some stuff in "static struct 
dvb_usb_device_properties" which cannot be fixed. Like dynamic remote 
configuration, dual mode, etc. I am going to make RFC for those maybe 
even this week after some analysis is done.

regards
Antti
  

On Mon, 07 May 2012 21:53:23 +0300
Antti Palosaari <crope@iki.fi> wrote:

> On 03.04.2012 18:33, Michael Büsch wrote:
> > On another thing:
> > The af9035 driver doesn't look multi-device safe. There are lots of static
> > variables around that keep device state. So it looks like this will
> > blow up if multiple devices are present in the system. Unlikely, but still... .
> > Are there any plans to fix this up?
> > If not, I'll probably take a look at this. But don't hold your breath.
> 
> I fixed what was possible by moving af9033 and af9035 configurations for 
> the state. That at least resolves most significant issues - like your 
> fc0011 tuner callback.

Cool, thanks a lot!

> But there is still some stuff in "static struct 
> dvb_usb_device_properties" which cannot be fixed. Like dynamic remote 
> configuration, dual mode, etc. I am going to make RFC for those maybe 
> even this week after some analysis is done.

Thanks. I'm currently lacking the time to do this kind of intrusive changes,
so I'm happy to see you looking into this.