From: abraham.manu@gmail.com (Manu Abraham)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow
Date: Fri, 02 Jun 2006 12:42:40 +0000 [thread overview]
Message-ID: <44803240.1010108@gmail.com> (raw)
In-Reply-To: <44802319.4050609@gmail.com>
Hans Verkuil wrote:
>> Hans Verkuil wrote:
>>
>>>> Hi All,
>>>>
>>>> Nathan Lutchansky wrote:
>>>>
>>>>
>>>>> At the moment, anyway. It will become more and more necessary as the
>>>>> number of different I2C sensor chips on the market increases. V4L/DVB
>>>>> has
>>>>> already hit this problem in a big way.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> DVB doesn't probe for i2c devices. The DVB adapter, ie the card knows
>>>> what devices that are present and works under that assumption.
>>>>
>>>> Earlier DVB had the problem with probing. ie a different device is
>>>> found
>>>> at the expected location of another device(In the case of probing) and
>>>> this device doesn't like to be fiddled around with. And "lo" we have a
>>>> perfect freeze.
>>>>
>>>> After many such cases, DVB no longer probes for i2c devices (we now
>>>> longer have anymore i2c issues)
>>>> V4L on the other hand probes for all devices. This is IMHO wrong, due
>>>> to
>>>>
>>>> (1) When the probe list grows long, it takes longer time for the probe
>>>> to succeed (V4L guys themselves would agree to the fact that they have
>>>> seen probes in the order of ~30 minutes ! Yuck)
>>>>
>>>> (2) Probing wrong devices
>>>>
>>>> So in any case probing can never be right, unless the card information
>>>> is passed to the i2c core. But in that sense it is no longer a probe.
>>>> It
>>>> is indeed just an attach method. In that case, it makes no sense to
>>>> make
>>>> i2c core go around in circles.
>>>>
>>>> The proper way to handle this, is that only the right device is
>>>> attached. Rather than making i2c to do this, subsystems should be
>>>> handling this.
>>>>
>>>>
>>> OK, I'll repeat this one more time: for many of the older v4l cards we
>>> have no idea on what addresses the i2c devices are. It was never
>>> documented. And also some devices can move around depending on the card
>>> revision (esp. true for the analog tuner).
>>>
>>>
>> That's no excuse to do things in a wrong way.
>>
>
> Oh please, get real. We want to do it the right way, that's what all these
> i2c patches are about. But there is a whole bunch of cards where we have
> to keep probing since we simply do not know on what address the i2c device
> is. Either because it was never documented, or because the manufacturer
> moves it around (or replaces tuners) without telling anyone or exporting
> that information in an eeprom or something similar. DVB doesn't have to
> deal with legacy devices, we do.
>
From the TSA5059 (it is similar to your analog device, it is a PLL)
datasheet.
It says it has Four selectable I2C-bus addresses
AFAICS, most PLL's and tuners are that way only. I don't think other
PLL's are different either.
Regarding changes based on different revisions of the same card, well
there is nothing more stranger than the AV7110 based DVB cards. The same
cards, with just different revision numbers with slight changes. DVB
does handle this quite efficiently, AFAICS.
The vendor keeps moving devices and addresses around on DVB hardware as
well, It is no different to DVB.
Manu
next prev parent reply other threads:[~2006-06-02 12:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 11:38 [lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow Manu Abraham
2006-06-02 12:05 ` Hans Verkuil
2006-06-02 12:05 ` Hans Verkuil
2006-06-02 12:17 ` Manu Abraham
2006-06-02 12:23 ` Manu Abraham
2006-06-02 12:29 ` Hans Verkuil
2006-06-02 12:42 ` Manu Abraham [this message]
2006-06-02 13:20 ` Hans Verkuil
2006-06-03 2:33 ` Mark M. Hoffman
2006-06-03 9:52 ` Johannes Stezenbach
2006-06-03 11:21 ` Manu Abraham
2006-06-06 12:00 ` Mark M. Hoffman
2006-06-06 12:04 ` Mark M. Hoffman
2006-06-06 12:38 ` Manu Abraham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44803240.1010108@gmail.com \
--to=abraham.manu@gmail.com \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.