NCLV-D SMBus - proposal to a solution

Mark Studebaker mds at
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

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

More information about the lm-sensors mailing list