2011/4/2 adq <adq@xxxxxxxxxxxxx>: > 2011/4/2 Antti Palosaari <crope@xxxxxx>: >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
