On Sat, Oct 31, 2009 at 7:17 PM, Michael Krufky <mkrufky@xxxxxxxxxxxxxx> wrote: >> 2009/11/1 Michael Krufky <mkrufky@xxxxxxxxxxxxxx>: >>> On Sat, Oct 31, 2009 at 6:43 PM, Michael Krufky <mkrufky@xxxxxxxxxxxxxx> wrote: >>>> On Sat, Oct 31, 2009 at 6:08 PM, Michael Obst >>>> <m.obst@xxxxxxxxxxxxxxxxxxxx> wrote: >>>>> Hi, >>>>> Thanks for fixing this, I can confirm that it now compiles and >>>>> inserts and the remote works, so does the av input to the tvcard >>>>> however the card does not seem to be able to tune any channels, I have >>>>> checked the old driver and that is still able to tune in channels. The >>>>> output from my dmesg is below. >>>>> >>>>> Thanks >>>>> Michael Obst >>>> >>>> Michael, >>>> >>>> This is an interesting problem -- the part of your dmesg that stands >>>> out to me is this: >>>> >>>>> [ 502.928544] tuner 0-0060: chip found @ 0xc0 (saa7130[0]) >>>>> [ 502.960501] tda8290: no gate control were provided! >>>> >>>> That error message was added as a safety measure -- it shouldn't be >>>> possible to ever hit that code path. Are you running any non-GPL >>>> binary drivers on your system, such as NVIDIA or anything else? >>>> >>>> Let me explain: >>>> >>>> The "no gate control were provided!" message was added by Mauro to the >>>> tda8290 driver, mainly as a check to ensure that we don't call a null >>>> function pointer. The gate control is actually provided by the >>>> tda8290 driver itself, by either tda8290_i2c_bridge or >>>> tda8295_i2c_bridge, depending on which hardware is present. In your >>>> case, it's a tda8290. >>>> >>>> The function pointer is filled during the tda829x_attach() function, >>>> before we call the tda829x_find_tuner function, where this error >>>> message is displayed. The only way for this to have occurred, as far >>>> as I can tell, is if the probe to detect the tda8290 itself had >>>> failed. >>>> >>>> Have you repeated your test with the same problem each time, or did >>>> this only happen once? >>>> >>>> Can you try again, from a cold reboot? >>>> >>>> Also, I'm just assuming that this failure occurred during a digital >>>> tune -- is that correct? Does analog television work? >>>> >>>> If the problem is reproducible, can you also show us dmesg during a failed tune? >>>> >>>> I'm very interested in hearing more about this -- please let me know. >>> >>> Oops, on second look, seems that the error occurred during analog >>> bring-up ... does digital tv work? >>> >>> -Mike >>> -- >>> 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 >>> >> > > On Sat, Oct 31, 2009 at 7:04 PM, Michael Obst > <m.obst@xxxxxxxxxxxxxxxxxxxx> wrote: >> This problem is reproducible and occurs the same from a cold boot or >> inserting saa7134. Analog tv has never worked on this card, I was >> under the impression there was no analog tuner on the card (looking at >> http://www.leadtek.com/eng/tv_tuner/image/digital_tv.pdf). The info >> was simply from doing a modprobe on saa7134. The only lines in the >> dmesg that were different from the old driver was >> >> saa7130[0]/alsa: Leadtek Winfast DTV1000S doesn't support digital audio >> >> So I guess the analog part has always failed >> >> I am using the nvidia driver and a driver for my wireless card, I will >> turn these off and see if I can get a different result. >> >> During tuning for digital tv with the old driver I got >> >> [ 1081.808505] tda18271: performing RF tracking filter calibration >> [ 1086.152006] tda18271: RF tracking filter calibration complete >> [ 1091.020535] hda-intel: IRQ timing workaround is activated for card >> #0. Suggest a bigger bdl_pos_adj. >> >> >> The final line did not appear when I tried to tune using the new version >> >> [ 1225.904503] tda18271: performing RF tracking filter calibration >> [ 1230.272003] tda18271: RF tracking filter calibration complete > > Michael, > > The policy on this mailing list is to reply BELOW the quoted text. > Please keep this in mind for the future. > > I didn't realize the board had a saa7130 chipset -- That explains a > lot. This means that there actually is no tda8290 on the board. (the > tda8290 is usually found inside the saa7131 chipset) > > You can remove the line, TUNER_PHILIPS_TDA8290 from the card > definition in saa7134-cards.c -- replace it with TUNER_ABSENT. > > That shouldn't fix the problem, but it would be interesting to hear if > it changes anything. I see that communication with the tuner is > working properly... It's taking 5 seconds to complete the rf tracking > filter calibration in either case, so we know that the line of > communication to the tuner itself isn't a problem. > > I think this will be easier if we meet in irc. Can you meed me in > #linuxtv on irc.freenode.net? > > If not, please enable module option debug=1 to tda18271 and send back > full dmesg, unedited, including startup of the device and a tune > attempt. > > Also, enable debug=1 for the tda10048 module -- maybe something > changed there. I just tested this code with my ATSC saa7134 board > that uses the tda18271, and it's working fine, so I doubt it's the > tuner persay, but we should investigate anyway. > > -Mike > For any interested readers, Michael did some testing and helped me to find the cause of the problem... Turns out one of my recent tda18271 changesets broke the std_map override functionality of the tda18271 driver -- I already pushed up a fix and requested merge to the master branch. For those that want their dtv1000s board working with the latest code, use the following tree: http://kernellabs.com/hg/~mkrufky/dtv1000s-fix I will delete the tree once the fix is merged into the v4l-dvb master branch. -Mike -- 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
