cc added to Mauro. Mauro, please see below. Luca Olivetti wrote: > En/na Michael Krufky ha escrit: > >> I see that inside af9005_fe_init, you are reading from the eeprom to determine >> which tuner is present. Yes, the correct place for this would be inside the >> "tuner_attach" callback of af9005_properties ... You say that isn't working for >> you?? Exactly what happens when you do that? > > IIRC (that was back in december) I couldn't tune. I don't remember if I > could talk to the tuner or not > >> Is it possible that there are some initializations happening inside af9005-fe.c >> that is opening up access to the i2c bus, which you didnt have access to at the >> time of tuner_attach? If that's the case, then it can (and should) be fixed by >> moving the bus initialization code to a function that is callable from tuner_attach. > > I think I tried to separate what is (supposedly) the i2c initialization > in af9005_fe_init somewhere else but it didn't work out. Maybe because I > hadn't clear the exact sequence of events in the dvb-usb infrastructure. > >> Perhaps there is an i2c gate being controlled by the demod? If that's the case, >> then the best way to take care of this is by creating an i2c_gate_ctrl function >> and add it to the frontend_ops struct, so that tuner_attach can call it from >> there, and it will be accessible from within the set_params function of the >> tuner module. >> >> I didn't do a full analysis of this driver yet, but these are some ideas that >> pop into my head at first glance. > > Alas, I cannot test anything since my stick died. > > Bye > :-/ ... Do you plan on getting a replacement? Perhaps you may contact the vendor so that they may send you a sample at no charge? How did your stick die? Maybe the driver broke it? I don't think this driver is ready yet for kernel inclusion, due to the problems spoken about in this thread, and the fact that your stick has died, potentially as a result of using the driver. Mauro, I think you should hold the af9005 code back from your git tree, and do not send it in for 2.6.23 nor -mm ... We should keep the code in the v4l-dvb master branch, and we should try to fix these issues asap, and send it to -mm and the next kernel version as soon as we can confirm that the driver is not responsible for damaging Luca's device. If anybody disagrees with me, please say so now. I don't think we should send this upstream yet, with good conscience, knowing that it could be potentially harmful to the device, and the fact that its module usage count handling is broken. I'm sorry, Luca. Regards, Michael Krufky _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
