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
> > 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.
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.
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.
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
--
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
