| Message ID | AANLkTik9cSnAFWNdTUv3NNU3K2SoeECDO2036Htx-OAi@mail.gmail.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
2011/3/18 Antti Palosaari <crope@iki.fi>: > On 03/08/2011 12:12 AM, adq wrote: >> >> Ah well, so its definitely /not/ conflicting i2c writes that cause the >> tuner problem as it has finally just died. The festats for a "crashed" >> tuner are: >> Sig: 50933 SNR: 50 BER: 0 UBLK: 5370554 Stat: 0x01 [SIG ] >> (no other error messages) >> >> For the other tuner, it is: >> Sig: 55703 SNR: 120 BER: 0 UBLK: 919 Stat: 0x1f [SIG CARR VIT SYNC >> LOCK ] >> >> Note the /massive/ difference in ubclocks; the tuner that died always >> had a massively larger UCBLOCKS count even when it was working fine. >> >> Antii, I'll try out your GPIO suggestions today or tomorrow, and I'll >> try and snag an i2c register dump to see if that sheds any light... > > Any new findings? Hi, just been trying it out, with no success. On my test machine, FE0 no longer tunes, but FE1 is still fine, so I've just been testing FE0. I've tried your suggestions, mainly concentrating on the af9013's GPIOs, but I also tried your power management suggestion. Since I was just using FE0, I've just been setting all the GPIOs at the start of af9013.c's set_frontend() implementation; I've tried turning them all off, all on, on->mdelay->off, and also off->mdelay->on. Nothing works. -- 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 04/02/2011 04:24 AM, adq wrote: > Hi, just been trying it out, with no success. On my test machine, FE0 > no longer tunes, but FE1 is still fine, so I've just been testing FE0. You try to say other frontend / tuner is physically dead? Which one? > I've tried your suggestions, mainly concentrating on the af9013's > GPIOs, but I also tried your power management suggestion. > > Since I was just using FE0, I've just been setting all the GPIOs at > the start of af9013.c's set_frontend() implementation; I've tried > turning them all off, all on, on->mdelay->off, and also > off->mdelay->on. Nothing works. So GPIOs are blocked out. I wonder if someone can ran similar many day tuning stress test using Windows drivers to see if that happen. Antti
2011/4/2 Antti Palosaari <crope@iki.fi>: > On 04/02/2011 04:24 AM, adq wrote: >> >> Hi, just been trying it out, with no success. On my test machine, FE0 >> no longer tunes, but FE1 is still fine, so I've just been testing FE0. > > You try to say other frontend / tuner is physically dead? Which one? No no - I can revive it by simply unplugging and replugging the device, but I was avoiding doing that to see if we could either track down something erroneous, or be able to reset it from software. It'd be /really/ handy if they'd connected that reset tuner GPIO :( There isn't a way to completely reset the device from software I take it? Or any other GPIOs hanging about I could test with? I have an MXL5005R tuner apparently - id 30 - BTW. >> I've tried your suggestions, mainly concentrating on the af9013's >> GPIOs, but I also tried your power management suggestion. >> >> Since I was just using FE0, I've just been setting all the GPIOs at >> the start of af9013.c's set_frontend() implementation; I've tried >> turning them all off, all on, on->mdelay->off, and also >> off->mdelay->on. Nothing works. > > So GPIOs are blocked out. > > I wonder if someone can ran similar many day tuning stress test using > Windows drivers to see if that happen. Might be hard to script under windows I suppose... -- 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
2011/4/2 adq <adq@lidskialf.net>: > 2011/4/2 Antti Palosaari <crope@iki.fi>: >> On 04/02/2011 04:24 AM, adq wrote: >>> >>> Hi, just been trying it out, with no success. On my test machine, FE0 >>> no longer tunes, but FE1 is still fine, so I've just been testing FE0. >> >> You try to say other frontend / tuner is physically dead? Which one? > > No no - I can revive it by simply unplugging and replugging the > device, but I was avoiding doing that to see if we could either track > down something erroneous, or be able to reset it from software. > > It'd be /really/ handy if they'd connected that reset tuner GPIO :( > There isn't a way to completely reset the device from software I take > it? Or any other GPIOs hanging about I could test with? > > I have an MXL5005R tuner apparently - id 30 - BTW. Forgot to mention - its the tuner attached to the internal af9013 (fe0) that is having the problem. The one attached to the external one (fe1) is still fine. I don't know if this is always the case though. >>> I've tried your suggestions, mainly concentrating on the af9013's >>> GPIOs, but I also tried your power management suggestion. >>> >>> Since I was just using FE0, I've just been setting all the GPIOs at >>> the start of af9013.c's set_frontend() implementation; I've tried >>> turning them all off, all on, on->mdelay->off, and also >>> off->mdelay->on. Nothing works. >> >> So GPIOs are blocked out. >> >> I wonder if someone can ran similar many day tuning stress test using >> Windows drivers to see if that happen. > > Might be hard to script under windows I suppose... > -- 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 04/02/2011 02:06 PM, adq wrote: > 2011/4/2 Antti Palosaari<crope@iki.fi>: >> On 04/02/2011 04:24 AM, adq wrote: >>> >>> Hi, just been trying it out, with no success. On my test machine, FE0 >>> no longer tunes, but FE1 is still fine, so I've just been testing FE0. >> >> You try to say other frontend / tuner is physically dead? Which one? > > No no - I can revive it by simply unplugging and replugging the > device, but I was avoiding doing that to see if we could either track > down something erroneous, or be able to reset it from software. > > It'd be /really/ handy if they'd connected that reset tuner GPIO :( > There isn't a way to completely reset the device from software I take > it? Or any other GPIOs hanging about I could test with? There is few I know, USB command 0x13 boots AF9015 somehow, USB command 0x5a reconnects it from USB bus. But most interesting one is demodulator reset register 0xe205, write 1 to that reg should reset it. > I have an MXL5005R tuner apparently - id 30 - BTW. I suspect it is demod which hangs since I have feeling it happens every tuner used. >>> I've tried your suggestions, mainly concentrating on the af9013's >>> GPIOs, but I also tried your power management suggestion. >>> >>> Since I was just using FE0, I've just been setting all the GPIOs at >>> the start of af9013.c's set_frontend() implementation; I've tried >>> turning them all off, all on, on->mdelay->off, and also >>> off->mdelay->on. Nothing works. >> >> So GPIOs are blocked out. >> >> I wonder if someone can ran similar many day tuning stress test using >> Windows drivers to see if that happen. > > Might be hard to script under windows I suppose... I am not aware any good commandline BDA tuning app for Windows. Only one I know is ScanChannelsBDA.exe which is rather buggy - but works. Antti
2011/4/2 Antti Palosaari <crope@iki.fi>: > On 04/02/2011 02:06 PM, adq wrote: >> >> 2011/4/2 Antti Palosaari<crope@iki.fi>: >>> >>> On 04/02/2011 04:24 AM, adq wrote: >>>> >>>> Hi, just been trying it out, with no success. On my test machine, FE0 >>>> no longer tunes, but FE1 is still fine, so I've just been testing FE0. >>> >>> You try to say other frontend / tuner is physically dead? Which one? >> >> No no - I can revive it by simply unplugging and replugging the >> device, but I was avoiding doing that to see if we could either track >> down something erroneous, or be able to reset it from software. >> >> It'd be /really/ handy if they'd connected that reset tuner GPIO :( >> There isn't a way to completely reset the device from software I take >> it? Or any other GPIOs hanging about I could test with? > > There is few I know, USB command 0x13 boots AF9015 somehow, USB command 0x5a > reconnects it from USB bus. But most interesting one is demodulator reset > register 0xe205, write 1 to that reg should reset it. Just tried writing 1 to 0xe205 - no change. Looks like USB commands 0x13/0x5a will be done as part of a normal module reload? (In which case it doesn't fix it). I can actually reboot the machine completely, and the problem stays! Only physically unplugging the device sorts 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 04/02/2011 04:45 PM, adq wrote: > 2011/4/2 Antti Palosaari<crope@iki.fi>: >> On 04/02/2011 02:06 PM, adq wrote: >>> >>> 2011/4/2 Antti Palosaari<crope@iki.fi>: >>>> >>>> On 04/02/2011 04:24 AM, adq wrote: >>>>> >>>>> Hi, just been trying it out, with no success. On my test machine, FE0 >>>>> no longer tunes, but FE1 is still fine, so I've just been testing FE0. >>>> >>>> You try to say other frontend / tuner is physically dead? Which one? >>> >>> No no - I can revive it by simply unplugging and replugging the >>> device, but I was avoiding doing that to see if we could either track >>> down something erroneous, or be able to reset it from software. >>> >>> It'd be /really/ handy if they'd connected that reset tuner GPIO :( >>> There isn't a way to completely reset the device from software I take >>> it? Or any other GPIOs hanging about I could test with? >> >> There is few I know, USB command 0x13 boots AF9015 somehow, USB command 0x5a >> reconnects it from USB bus. But most interesting one is demodulator reset >> register 0xe205, write 1 to that reg should reset it. > > Just tried writing 1 to 0xe205 - no change. OK. > Looks like USB commands 0x13/0x5a will be done as part of a normal > module reload? (In which case it doesn't fix it). > > I can actually reboot the machine completely, and the problem stays! > Only physically unplugging the device sorts it. You are correct. I don't have any idea anymore. Only is wish to know if that happens in Windows too. Antti
2011/4/2 Antti Palosaari <crope@iki.fi>: > On 04/02/2011 04:45 PM, adq wrote: >> >> 2011/4/2 Antti Palosaari<crope@iki.fi>: >>> >>> On 04/02/2011 02:06 PM, adq wrote: >>>> >>>> 2011/4/2 Antti Palosaari<crope@iki.fi>: >>>>> >>>>> On 04/02/2011 04:24 AM, adq wrote: >>>>>> >>>>>> Hi, just been trying it out, with no success. On my test machine, FE0 >>>>>> no longer tunes, but FE1 is still fine, so I've just been testing FE0. >>>>> >>>>> You try to say other frontend / tuner is physically dead? Which one? >>>> >>>> No no - I can revive it by simply unplugging and replugging the >>>> device, but I was avoiding doing that to see if we could either track >>>> down something erroneous, or be able to reset it from software. >>>> >>>> It'd be /really/ handy if they'd connected that reset tuner GPIO :( >>>> There isn't a way to completely reset the device from software I take >>>> it? Or any other GPIOs hanging about I could test with? >>> >>> There is few I know, USB command 0x13 boots AF9015 somehow, USB command >>> 0x5a >>> reconnects it from USB bus. But most interesting one is demodulator reset >>> register 0xe205, write 1 to that reg should reset it. >> >> Just tried writing 1 to 0xe205 - no change. > > OK. > >> Looks like USB commands 0x13/0x5a will be done as part of a normal >> module reload? (In which case it doesn't fix it). >> >> I can actually reboot the machine completely, and the problem stays! >> Only physically unplugging the device sorts it. > > You are correct. I don't have any idea anymore. Only is wish to know if that > happens in Windows too. Yeah, no more ideas here either, and I can't really try it under windows. Beginning to think its some hardware issue. As a "workaround", if you make sure your software doesn't retune constantly, it seems to survive reasonably ok. The other one I have in my server is fine after a few weeks now I've turned off any auto EIT/signalmonitoring stuff in tvheadend. I just need to write a quick cron job to check the tuning still works. :( -- 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
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c index 31c0a0e..d9f32fe 100644 --- a/drivers/media/dvb/dvb-usb/af9015.c +++ b/drivers/media/dvb/dvb-usb/af9015.c @@ -1083,6 +1083,24 @@ static int af9015_i2c_init(struct dvb_usb_device *d) return ret; } +static int af9015_lock_i2c_gate_ctrl(struct dvb_frontend *fe, int enable) +{ + int result; + struct dvb_usb_adapter *adap = fe->dvb->priv; + struct af9015_state *state = adap->dev->priv; + + if (enable) + if (mutex_lock_interruptible(&adap->dev->usb_mutex)) + return -EAGAIN; + + result = state->i2c_gate_ctrl[adap->id](fe, enable); + + if (!enable) + mutex_unlock(&adap->dev->usb_mutex); + + return result; +} + static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap) { int ret; @@ -1116,6 +1134,11 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap) /* attach demodulator */ adap->fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id], i2c_adap); + + if (adap->fe && adap->fe->ops.i2c_gate_ctrl) { + state->i2c_gate_ctrl[adap->id] = adap->fe->ops.i2c_gate_ctrl; + adap->fe->ops.i2c_gate_ctrl = af9015_lock_i2c_gate_ctrl; + } return adap->fe == NULL ? -ENODEV : 0; } diff --git a/drivers/media/dvb/dvb-usb/af9015.h b/drivers/media/dvb/dvb-usb/af9015.h index f20cfa6..094b1e3 100644 --- a/drivers/media/dvb/dvb-usb/af9015.h +++ b/drivers/media/dvb/dvb-usb/af9015.h @@ -102,6 +102,7 @@ struct af9015_state { struct i2c_adapter i2c_adap; /* I2C adapter for 2nd FE */ u8 rc_repeat; u32 rc_keycode; + int (*i2c_gate_ctrl[2])(struct dvb_frontend *fe, int enable); }; struct af9015_config {