Re: [PATCH] fc0011: Reduce number of retries
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 -- http://palosaari.fi/ -- 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] fc0011: Reduce number of retries
On Mon, 07 May 2012 21:53:23 +0300 Antti Palosaari cr...@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. -- Greetings, Michael. PGP encryption is encouraged / 908D8B0E signature.asc Description: PGP signature
[PATCH] fc0011: Reduce number of retries
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.0 +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) {
/* Reset the tuner and try again */
err = fe-callback(priv-i2c, DVB_FRONTEND_COMPONENT_TUNER,
FC0011_FE_CALLBACK_RESET, priv-addr);
--
Greetings, Michael.
PGP encryption is encouraged / 908D8B0E
signature.asc
Description: PGP signature
Re: [PATCH] fc0011: Reduce number of retries
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 Bueschm...@bues.ch
---
Index: linux/drivers/media/common/tuners/fc0011.c
===
--- linux.orig/drivers/media/common/tuners/fc0011.c 2012-04-03
08:48:39.0 +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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fc0011: Reduce number of retries
On Tue, 03 Apr 2012 12:58:16 +0300
David Cohen david.a.co...@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.
--
Greetings, Michael.
PGP encryption is encouraged / 908D8B0E
signature.asc
Description: PGP signature
Re: [PATCH] fc0011: Reduce number of retries
On 04/03/2012 01:07 PM, Michael Büsch wrote:
On Tue, 03 Apr 2012 12:58:16 +0300
David Cohendavid.a.co...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fc0011: Reduce number of retries
On 03.04.2012 12:05, Michael Büsch wrote: Now that i2c transfers are fixed, 3 retries are enough. Signed-off-by: Michael Bueschm...@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 -- http://palosaari.fi/ -- 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] fc0011: Reduce number of retries
On Tue, 03 Apr 2012 18:24:20 +0300 Antti Palosaari cr...@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 Bueschm...@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. -- Greetings, Michael. PGP encryption is encouraged / 908D8B0E signature.asc Description: PGP signature
Re: [PATCH] fc0011: Reduce number of retries
On 03.04.2012 18:33, Michael Büsch wrote: On Tue, 03 Apr 2012 18:24:20 +0300 Antti Palosaaricr...@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 Bueschm...@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 -- http://palosaari.fi/ -- 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
