Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Also note in your tda18271_set_params() sgIF gets set for ATSC mode but is left at zero for OFDM mode - this is incorrect I believe, and the datasheet gives the required IFs as 3.3, 3.8 and 4.3 MHz Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: It's not wrong -- it's just missing. I said it before -- the driver is not tested with DVB-T -- I need a test case for it first. Feel free to send in a patch, since you DO have that test case. Cheers, Mike Krufky Sadly I have not yet achieved FE_HAS_SIGNAL (TDA10048 reg 1A: FREQ_LOCK) with _any_ code, though I /have/ had FE_HAS_CARRIER, FE_HAS_SYNC FE_HAS_VITERBI. Hence do not get FE_HAS_LOCK (TDA10048 reg 1A: FEL) Possibly need to get a spectrum analyser onto the IFOUT pins to see why the 10048 is not achieving proper lock. May be a 10048 setup mismatch ... On that basis I am not willing to submit patches, until I have demonstrably working tuning ! Regards MikeW PS. One of the RF techies said that silicon tuners were _much_ harder work than can tuners, hence the increase in s/w needed to work them ... ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Thanks. I also note in your repository code that there is no account taken of whether the chip is in Master or Slave mode - the 18211 needs different frequency setting depending on whether it is running the 16MHz crystal (Master), or whether it just has the 16MHz input (Slave). This is relevant if you have a dual-tuner configuration, increasingly common to allow PVR and viewing on different channels. In Master mode you set the required frequency on the Main PLL, in Slave mode you have to use the Cal PLL. Also set CALVCO_forLOn: EB1[2] and a few other bits ! Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: On 11/1/07, MikeW xx_ at yahoo.co.uk wrote: Using the OM5776 eval board, and using the algorithm published in the rev 1.1.0 datasheet, I find I am getting an I2C NAK, which does not go away and requires a chip reset to restore any I2C communication, after successfully writing EP4 (r06) in the 'image rejection cal pt I, wanted signal measurement' section where registers are written back. (NAK occurs on write to EP5) While in calibration mode, the bytes of sub addresses 0x03 thru 0x0f must be written in one single i2c sequence. Yes, I did consider this, but, annoyingly, the kernel I2C primitives do not allow chaining of I2C buffers except as a 'repeated START' transaction, hence you need to copy the register address into a buffer followed by the data bytes, then send all as one transaction. (Could implement by saving content of previous byte in the reg map, replace with reg sddress value, sending bytes, then restoring original value ...) The data sheet flowchart actually says: SubAddr(hex): 03 to 0F suggesting that separate writes would be permissible. However, it's worth trying the single transfer approach. The version 1.0.1 document is actually a little more explicit in some cases, but I thought that since its version was earlier, it had been superceded. Will have another look at the sequence there since it's rather more prescriptive. Are you sure that you're using the exact algorithm from the datasheet? You're better off storing the values that you plan to write, then write them all at once in a single transaction. You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Thanks for the suggestion ! Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
