syrius.ml@xxxxxxxxxx wrote:
> (someone broke quoting so we don't know who wrote this:)
> >> After a long and painful search, I found out that the delay
> >> happened in I2C comms. I noticed that, in av7110.c, a flag was set,
> >> called SAA7146_I2C_SHORT_DELAY, in the saa7146_extension
> >> structure. So, I applied the following simple patch:
> >>
> >> --- budget.c~ 2005-09-04 14:58:21.000000000 +0200
> >> +++ budget.c 2005-09-17 23:28:14.000000000 +0200
> >> @@ -740,7 +740,7 @@
> >>
> >> static struct saa7146_extension budget_extension = {
> >> .name = "budget dvb\0",
> >> - .flags = 0,
> >> + .flags = SAA7146_I2C_SHORT_DELAY,
> >>
> >> .module = THIS_MODULE,
> >> .pci_tbl = pci_tbl,
> >>
> >> Well, the card now reacts *very* quickly, and I do not notice any side
> >> effects.
> >>
> >> Is there any reason why this flag is not set?
>
>
> Same here !
> my 1131:7146 tt budget card (without ci) now works correctly with this
> correction to budget-ci.c and recent kernels (2.6.14-rc2-git5 + cvs
> dvb-kernel)
> without this, the budget card only tune to some channels
> (if i recall correctly, only low band horizontal polarity ones)
It looks to me like SAA7146_I2C_SHORT_DELAY should be safe
for all cards? Looking at saa7146_i2c.c it seems the worst
which could happen is that with some slow i2c devices it
would wast some CPU? Why does SAA7146_I2C_SHORT_DELAY
exist in the first place? Why does the short_delay flag
depend on the result of saa7146_i2c_msg_prepare()?
Comments?
Johannes
