On 02/01/13 21:07, Devin Heitmueller wrote:
On Fri, Feb 1, 2013 at 4:03 PM, Chris Clayton <chris2553@xxxxxxxxxxxxxx> wrote:
Yes, I noticed that but even with the tuning timeout set at medium or
longest, I doesn't find any channels. However, I've been following the debug
messages through the code and ended up at
drivers/media/pci/cx23885/cx23885-i2c.c.
I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved
results from scanning. With that delay doubled, scandvb now finds 49
channels over 3 frequencies. That's with all debugging turned off, so no
extra delays provided by the production of debug messages.
I'll play around more tomorrow and update then.
It could be that the cx23885 driver doesn't properly implement I2C
clock stretching, which is something you don't encounter on most
tuners but is an issue when communicating with the Xceive parts.
Well, the action seems to be in drivers/pci/cx23885/cx23885-i2c.c.
I answer to your point above, I've had to look up what I2C clock
stretching is and I believe that, basically, the driver would wait for
the hardware to give the go-ahead to continue. That's what seems to be
happening in i2c_wait_done(), but whether that's a good implementation I
cannot say.
I've noticed that there is some consistency in the failure. For example,
if I boot the laptop, activate the dvb-t card and then run a channel
scan, no channels will be found. If I then turn on debugging in the
cx23885 driver (by writing 1 to
/sys/module/cx23885/parameters/i2c_debug), and then run the scan again,
some channels will be found. The number found varies from just a few to,
on one occasion, all 117 of them. Then, I can turn debugging off again
and channels will again be found when I run the scan and continue to be
found each time I run the scan. If I reboot, the cycle starts again.
I've also added some printks to the cx23885-i2c.c to find out where the
return value of -5 (-EIO) comes from. I've found that the call to
i2c_wait_done in i2c_sendbytes (line 145) returns 0 and that results in
-EIO being returned a few lines later. My debug output also contained
the value of the variable cnt, which controls the enclosing for() loop.
cnt always has the value 3. I don't know what this might mean in terms
of locating the problem, but hopefully someone on the list will.
Chris
Devin
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
