[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

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.


my 2 cents


Manu
 

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Hans Verkuil]

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

There are also cards where the only way to determine which model it is is
by probing addresses to see if a chip is present as there is no other way
to detecting this. And I'm sure I've missed lots of other horrible
situations where probing is the only way to do discover what card you are
talking to.

And the whole idea of these patches is to at least allow v4l drivers to be
more precise in their probing (or use the precise i2c address if known) to
make the startup faster and to prevent misdetections, which are becoming a
major problem. BTW, I've never heard of 30 minute probes, compared to
things like firmware uploads over i2c the probe time is negligible.

Regards,

         Hans

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Hans Verkuil]

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

There are also cards where the only way to determine which model it is is
by probing addresses to see if a chip is present as there is no other way
to detecting this. And I'm sure I've missed lots of other horrible
situations where probing is the only way to do discover what card you are
talking to.

And the whole idea of these patches is to at least allow v4l drivers to be
more precise in their probing (or use the precise i2c address if known) to
make the startup faster and to prevent misdetections, which are becoming a
major problem. BTW, I've never heard of 30 minute probes, compared to
things like firmware uploads over i2c the probe time is negligible.

Regards,

         Hans

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

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.


Manu

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

Hans Verkuil wrote:
> BTW, I've never heard of 30 minute probes, compared to
> things like firmware uploads over i2c the probe time is negligible.
>
>   

There was a discussion about this on the v4l IRC channel, regarding a 16 
channel (DVR) capture card (bttv driver)
Sorry it was slightly less than 30 minutes, maybe 27 minutes


Manu

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Hans Verkuil]

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

Regards,

        Hans

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

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

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Hans Verkuil]

> Hans Verkuil wrote:
>>> Hans Verkuil wrote:
>> 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.

Now I'm confused. In v4l we also use I2C address ranges (e.g. msp3400 can
be on 0x80 or 0x88). Unfortunately the tuner module has 20 addresses to
probe :-(. Can I conclude from your statement that DVB does similar
probing? If so, then the only difference between v4l and dvb is that since
v4l uses the i2c high level probing functions it is less efficient than
dvb because that i2c probe will probe all loaded i2c modules instead of
only the modules that the card driver needs. So too much work is being
done (and misdetections occur). And that's what these patches aim to
correct.

In other words, I really don't see what is wrong about this compared to
the dvb way. The end result will be the same.

        Hans

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Mark M. Hoffman]

Hi Manu:

* Manu Abraham <abraham.manu at gmail.com> [2006-06-02 15:38:01 +0400]:
> 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 driver model code itself has a lot of back-and-forth delegation, i.e.
'around in circles'.  If the i2c core can be made flexible enough to
address all the requirements, why wouldn't that be the best place for it?

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

Are you saying that the probing which is absolutely necessary for hwmon
should be moved out of i2c-core and into a separate hwmon subsystem?
If so, that's interesting, I guess... do you then disagree with the
*premise* of Nathan's patches?  I mean, "DVB which no longer probes"
is one of its goals after all.

Actually, Manu: may I ask a favor?  Could you please point out what are
some of the most difficult and/or sticky "problem drivers" regarding
DVB vs. I2C, and perhaps even describe what makes each particular
instance such a pain for you?  I would appreciate it.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Johannes Stezenbach]

On Fri, Jun 02, 2006, Mark M. Hoffman wrote:
> * Nathan Lutchansky <lutchann at litech.org> [2006-06-01 16:48:58 -0400]:
> > So, that's why the patch is as limited as it is.  It takes care of all the
> > obvious parts of adapting the I2C subsystem to the device model and leaves
> > the existing probing mechanism the way it is, but provides a clean path 
> > for embedded platforms to explicitly instantiate their devices without 
> > probing.
> > 
> > I hope that makes my motivations more clear.  -Nathan
> 
> I already understood these two goals:
> (1) Adapt I2C to better fit the kernel driver model.
> (2) Allow client devices to be attached without probing.
> 
> I am beginning to get the impression, from later emails in this thread
> by Hans and Manu, that (2) is really closer to...
> 
> (3) Allow precise control over I2C bus traffic for adapters that require it.
> 
> What I have in mind should satisfy these goals.  Again, I'll try to get out
> some patches as soon as I can.

Sorry, I've been busy and not paying attention to this thread.

I once tried to summarize DVB probing mechanism / requirements
in an old mail:
http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-March/000779.html


HTH,
Johannes

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

Mark M. Hoffman wrote:
> Hi Manu:
>
> * Manu Abraham <abraham.manu at gmail.com> [2006-06-02 15:38:01 +0400]:
>   
>> 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 driver model code itself has a lot of back-and-forth delegation, i.e.
> 'around in circles'.  If the i2c core can be made flexible enough to
> address all the requirements, why wouldn't that be the best place for it?
>
>   
>> 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.
>>     
>
> Are you saying that the probing which is absolutely necessary for hwmon
> should be moved out of i2c-core and into a separate hwmon subsystem?
>   

When i say we don't do probing, i mean that the environment that which 
hosts the device, knows what device is present. DVB does that way. There 
might be people who doesn't like this way, but it is a fool proof 
system, where it doesn't fail under any circumstances.

When i say probing, we search for something known. In the case of the 
PCI subsystem this exists, but for i2c this does not exist in many 
cases, ie the device id does not exist in many cases. So a probe is 
meaningless, technically the other name for it is just say attach to 
this address , rather than calling it probe, since it doesn't really probe.


When this discussion comes along it reminds me of the PCI - ISA 
discussions, why not probe for ISA devices like PCI devices ..

> If so, that's interesting, I guess... do you then disagree with the
> *premise* of Nathan's patches?  I mean, "DVB which no longer probes"
> is one of its goals after all.
>
> Actually, Manu: may I ask a favor?  Could you please point out what are
> some of the most difficult and/or sticky "problem drivers" regarding
> DVB vs. I2C, and perhaps even describe what makes each particular
> instance such a pain for you?  I would appreciate it.
>
>   

Well Johannes has really clarified the issues in  the other post.

Other than what he mentioned, there are newer devices too which work 
differently, we may like to to classify them as buggy hardware, but 
these are not buggy (believe me)

well, these issues come up as new devices churn out, it is not becoming 
lesser, but in fact it is just increasing. Trying to figure out 
workarounds for all these in i2c core seems to be something that doesn't 
seem to work at all.

What i would make it in short, would be that in the end, a new device 
comes out, and lo  patch [5/20] make i2c core adaptable to device "x" 
This will keep on repeating and at one stage, and thus we have a huge 
fight, i2c guys stating that this should not go into i2c. Well, where 
else should it go then ?

Just stating that don't use the devices, or that manufacturers have to 
make devices complying to Linux subsystems is no way to go about. Or 
cripple the device such that we don't use features 1 --- 9 out of the 
supported 10 too is not the way to go. (Just got a bit carried away, 
been annoyed with these problems lately, eventhough not relating to this 
discussion)

Other than what Johannes said and my statement above, there are 
multiplexed devices, which the i2c core can never find out without 
knowing the host environment, ie what card it is. So in fact to make it 
work, we will be passing DVB subsystem specifics to i2c subsystem, which 
is IMHO wrong.


Manu

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Mark M. Hoffman]

Manu:

* Manu Abraham <abraham.manu at gmail.com> [2006-06-03 15:21:58 +0400]:
> Mark M. Hoffman wrote:
> > Hi Manu:
> >
> > * Manu Abraham <abraham.manu at gmail.com> [2006-06-02 15:38:01 +0400]:
> >> 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.
> >>     
> >
> > Are you saying that the probing which is absolutely necessary for hwmon
> > should be moved out of i2c-core and into a separate hwmon subsystem?
> >   
> 
> When i say we don't do probing, i mean that the environment that which 
> hosts the device, knows what device is present. DVB does that way. There 
> might be people who doesn't like this way, but it is a fool proof 
> system, where it doesn't fail under any circumstances.
> 
> When i say probing, we search for something known. In the case of the 
> PCI subsystem this exists, but for i2c this does not exist in many 
> cases, ie the device id does not exist in many cases. So a probe is 
> meaningless, technically the other name for it is just say attach to 
> this address , rather than calling it probe, since it doesn't really probe.
> 
> 
> When this discussion comes along it reminds me of the PCI - ISA 
> discussions, why not probe for ISA devices like PCI devices ..

Yes, I understand that some devices are difficult or impossible to
detect.  And of course it is better, if you already know what device
is present, to simply attach to it rather than try to detect it on
the bus.  Nathan's patch would allow for this.  What is the problem?

> > If so, that's interesting, I guess... do you then disagree with the
> > *premise* of Nathan's patches?  I mean, "DVB which no longer probes"
> > is one of its goals after all.
> >
> > Actually, Manu: may I ask a favor?  Could you please point out what are
> > some of the most difficult and/or sticky "problem drivers" regarding
> > DVB vs. I2C, and perhaps even describe what makes each particular
> > instance such a pain for you?  I would appreciate it.
> >
> >   
> 
> Well Johannes has really clarified the issues in  the other post.

Let me first say:  if DVB people are content to use i2c_transfer() directly,
then I'm not interested in forcing anyone otherwise.  Nonetheless, there
are other people who are interested in moving the I2C subsystem forward.

I repeat: I'm not interested in forcing anyone to change their code!

> Other than what he mentioned, there are newer devices too which work 
> differently, we may like to to classify them as buggy hardware, but 
> these are not buggy (believe me)

non-sequitor

> well, these issues come up as new devices churn out, it is not becoming 
> lesser, but in fact it is just increasing. Trying to figure out 
> workarounds for all these in i2c core seems to be something that doesn't 
> seem to work at all.

What workarounds?  If you have an example driver, something *concrete*,
please point me to it.

> What i would make it in short, would be that in the end, a new device 
> comes out, and lo  patch [5/20] make i2c core adaptable to device "x" 
> This will keep on repeating and at one stage, and thus we have a huge 
> fight, i2c guys stating that this should not go into i2c. Well, where 
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> else should it go then ?

I was about to write "show me where this happened" but I guess you're
talking about the i2c_client 'command' method.  Is there anything else?

> Just stating that don't use the devices, or that manufacturers have to 
> make devices complying to Linux subsystems is no way to go about. Or 
> cripple the device such that we don't use features 1 --- 9 out of the 
> supported 10 too is not the way to go. (Just got a bit carried away, 
> been annoyed with these problems lately, eventhough not relating to this 
> discussion)

irrelevant strawman

> Other than what Johannes said and my statement above, there are 
> multiplexed devices, which the i2c core can never find out without 
> knowing the host environment, ie what card it is. So in fact to make it 
> work, we will be passing DVB subsystem specifics to i2c subsystem, which 
> is IMHO wrong.

No.  DVB would be passing I2C subsystem specifics to the I2C subsystem.
That makes perfect sense to me.  PCI is able to self-discover and doesn't
need any help.  I2C core needs help to do that.  So what?  We do what we
have to do.  Especially with bus muxes, I don't see why you would want
every I2C-using subsystem to have to solve that problem separately.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Mark M. Hoffman]

Johannes:

* Johannes Stezenbach <js at linuxtv.org> [2006-06-03 11:52:17 +0200]:
> I once tried to summarize DVB probing mechanism / requirements
> in an old mail:
> http://www.linuxtv.org/pipermail/v4l-dvb-maintainer/2006-March/000779.html

Thanks for the pointer.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] [v4l-dvb-maintainer] Re: [PATCH 1/3] i2c: allow

[Manu Abraham]

Mark M. Hoffman wrote:
>> When this discussion comes along it reminds me of the PCI - ISA 
>> discussions, why not probe for ISA devices like PCI devices ..
>>     
>
> Yes, I understand that some devices are difficult or impossible to
> detect.  And of course it is better, if you already know what device
> is present, to simply attach to it rather than try to detect it on
> the bus.  Nathan's patch would allow for this.  What is the problem?
>   

For a device that which does not have any identification, when a third 
party does attach the device, even more chances are there that it could 
possibly be wrong. (I mean for devices that do not have any identification)

In such a case, to handle such a case the subsystem can handle this 
difficult case more efficiently, since it can determine what device it 
is through some way or the other (since it is there within the same 
subsystem). This would be harder when such information has to be passed 
on to another subsystem in a generic way.


>>> If so, that's interesting, I guess... do you then disagree with the
>>> *premise* of Nathan's patches?  I mean, "DVB which no longer probes"
>>> is one of its goals after all.
>>>
>>> Actually, Manu: may I ask a favor?  Could you please point out what are
>>> some of the most difficult and/or sticky "problem drivers" regarding
>>> DVB vs. I2C, and perhaps even describe what makes each particular
>>> instance such a pain for you?  I would appreciate it.
>>>
>>>   
>>>       
>> Well Johannes has really clarified the issues in  the other post.
>>     
>
> Let me first say:  if DVB people are content to use i2c_transfer() directly,
> then I'm not interested in forcing anyone otherwise.  Nonetheless, there
> are other people who are interested in moving the I2C subsystem forward.
>
> I repeat: I'm not interested in forcing anyone to change their code!
>   


Cool, no issues. Some discussions made many people think that these 
changes were being forced down.


> No.  DVB would be passing I2C subsystem specifics to the I2C subsystem.
> That makes perfect sense to me.  PCI is able to self-discover and doesn't
> need any help.  I2C core needs help to do that.  So what?  We do what we
> have to do.  Especially with bus muxes, I don't see why you would want
> every I2C-using subsystem to have to solve that problem separately.
>
>   

Because that wouldn't be part of I2C at all, but a part of the device 
itself, which requires a separate command to the device.


Manu