NCLV-D SMBus - proposal to a solution

Mark Studebaker mds at mds.gotdns.com
Mon Apr 18 21:28:47 CEST 2005


Jean Delvare wrote:
> Hi Mark,
> 
> 
>>This is a good time to bring up the i2c-virtual driver as an
>>alternative to the -s4882.c style of multiplexing driver. I believe
>>this is a cleaner and more general approach to bus multiplexing.
> 
> 
> I agree it is more general, and possibly cleaner as a result. However,
> it will fail to be as flexible as the s4882 style approach.
> 
> The S4882 has 8 busses, 2 for each CPU. The 2 busses of each CPU are
> "compatible" (no common address) so I merged them, which results in
> better performance (less switching required) and lower memory footprint.
> I don't think you'll be able to do that with the i2c-virtual approach.
> 
> In the NCLV-D case, it has 4 different bus lines, but we only really
> want to handle 2. How can you do that with i2c-virtual?
> 

i2c-virtual is the generic part. It would be handled in a new
nclv-d  module for the specifics of that board.

> Also, I think I remember that i2c-virtual somehow assumes that the
> multiplexer itself is an i2c chip, right? This is not the case for the
> NCLV-D.
> 

no the mux itself can be anything. 
It is controlled by another driver which does the  specific
switching. See pca954x.c.
i2c-virtual.c only contains the generic part.

While pca954x is large, it is overly complex and needs a lot of cleanup.
I belive a module for NCLV could be fairly small.

> 
> 
>>The i2c-virtual driver is checked in to sensors but the small changes
>>required to i2c-core.c are not checked in. I held off late last year
>>because 2.9.0 was coming out soon. Now that 2.9.1 is out it's  time to
>>look at it again. I have to rework the i2c-core changes because they
>>conflicted with other recent changes to i2c-core.
> 
> 
> Yeah, I remember that.
> 
> The more I think of it, the more obvious it is that such a change
> doesn't belong to the 2.4 kernel, but 2.6. I do not want any more
> changes to the i2c subsystem of Linux 2.4 (except for bug fixes and
> documentation updates, of course). It's more than time to move the
> development effort to 2.6, and only do support on 2.4.
> 
> 

well it's a modest change and CVS / 2.4 is a better sandbox to
test out the changes, at least for  me. 2.4 was where the virtual driver was developed
by the original submitter Ken Harrenstein.

>>attached are the proposed changes to i2c-core for comment.
> 
> 
> Eerk. By brain doesn't read non-unified patches very well, sorry.
> 

eerk :) here is unified diff


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: i2c-core.diff
URL: <http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050418/2660b11b/attachment.ksh>


More information about the lm-sensors mailing list