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

[abraham.manu@gmail.com (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