on Fri, 16 Apr 2010 09:50 am in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure hermann pitton wrote: > Hi Peter, > > Am Donnerstag, den 15.04.2010, 23:30 +1000 schrieb 0123peter@xxxxxxxxx: >> on Thu, 15 Apr 2010 01:32 pm >> in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure >> hermann pitton wrote: >> >> > Hi, >> > >> > to be honest, there is a little too much delay on those reports. >> >> I have been very slow, sorry. > > no problem, but it becomes also a little hard to me to recap the issues. > > As said, Hartmut had the best pointers I guess. > >> >> > did not even notice a problem with Trent's prior patch. >> >> > The same is also at vivi. >> >> > >> >> >> Should I have a file called /etc/modprobe.d/TVanywhereAD >> >> >> that contains the line, >> >> >> >> >> >> options saa7134 card=94 gpio_tracking i2c_debug=1 >> >> >> >> >> >> and then watch the command line output of "kaffeine"? >> >> >> >> I've found a GUI that allows tweaking lots of module parameters >> >> that I have never heard of. Card=94 in the config file, >> >> gpio_tracking and i2c_debug are set to "1" in the GUI. >> >> >> >> Strange things are appearing in dmesg and syslog. I assume that >> >> [snip] >> >> saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> >> i2c-adapter i2c-0: Invalid 7-bit address 0x7a >> >> saa7133[0]: i2c xfer: < 8e ERROR: NO_DEVICE >> >> [snip] >> >> is significant. >> > >> > No, not at all for my knowledge. >> >> Unsurprisingly, that just highlights my ignorance. >> >> >> > If you want to produce debug output for failing firmware loading from >> >> > file after a cold boot, yes, you might eventually be able to see that >> >> > failing tuner initialization brings down i2c. >> >> > >> >> > If it is a additional new regression, then mercurial bisect can find the >> >> > patch in question fairly quick. >> >> >> >> That sounds like something that I should be able to do, if only >> >> I'd read the instructions. >> > >> > It is totally up to you and all others with that hardware. >> >> Can you provide a like for where to start reading? > > README.patches. > > Part III - Best Practices > 1. Community best practices > 2. Mercurial specific procedures > 3. Knowing about newer patches committed at the development repositories > 4. Patch submission from the community > 5. Identifying regressions with Mercurial I have not found the file README.patches. >> > Since already in some multiple broken conditions, never working without >> > flaws previously, I would suggest not to wait any longer, until some >> > sort of hadron collider is available ... >> >> Now I'm discouraged. It might be a better use of my time to do >> something else - anything else. Maybe I'll just put it in a box >> for a year and see what happens. > > I (un)fortunately ;) don't have such hardware and Hartmut did not have > any at that time either. > > Don't just wait, also no need to hurry on next day. > > If the problem is described well, someone can take it as a challenge to > work on it. We indeed had people from CERN fixing tuners. > > Trying to recap. I have allowed things to get confused. > You have been interested to add the card to auto detection, but firmware > load was only successful in one of three cases only already that time > and we have not been aware of that flaw in the beginning. I am not the original poster. When a link was posted that mentioned one of my cards (an MSI TV@nywhere A/D) I said, "Aha". Because there was a different, working, card next to it, problems with the MSI were less obvious than they should have been. In retrospect, the MSI has not worked at all for a long time and might have always been a little bit unreliable. I have not noticed a one-in-three firmware load failure on the MSI. That would have been the original poster about his Kworld. Although I did post a bit of dmesg that I thought might be relevant. > Hartmut assumed later, on such a card is some locking protection needed > during the firmware load, and my guess is the longish tuner > initialization sequence gets corrupted, because of that missing locking, > and all goes doom. (at least well known on all of such before any > support for the tda8275a) > > Now, improved, only one of ten tries loads the firmware and keeps the > card in a responding state. That is of course also very unpleasant for > using mercurial bisect, I really do admit. > > Also, as reported too now, with two of such kind of cards in one > machine, likely better don't try at all. My MSI tuner is currently in a test computer with no other tuner cards. > OTOH, the m$ driver obviously does manage to load the firmware even for > multiple such cards. (but maybe breaks all others ...) > > Which doesn't help us, since rebooting after that only hides our > problem. > > Those cards following the Philips/NXP/Trident reference designs do not > have it, but I don't test per day anymore. (we have problems with > different cards with the same PCI subsystem IDs and different LNAs too, > introduced by OEMs) > > So, on some first thought, which is only as random as the card's > behavior, debug logs from the time it was added might be useful. > (i2c works/works not) > > That it is now even worse, is still a chance to find out something more > and not only a improved regression on something never working properly. > > If the hardware is not going out of specs by will, excluding others, OEM > engineers, having more details, can still help to improve it for us too. > > Anyway, we should have start with some #ifdef 0 on it. > > Cheers, > Hermann -- Sig goes here... Peter D. -- 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
