At 18 Feb 2002 07:29:02 -0000, eeh@netbsd.org wrote:
> | around SMBus commands and smarter controllers.
> 
> Yes.  Providing SMBus compatibility will make it completely impossible
> to talk to devices that do not use the SMBus command protocols.

That's not true.


> | What that means is that when somebody comes along and does the single
> | interface for both smbus and i2c _right_, they'll probably have to
> | completely redo the interface between command issuers and command
> | processors, specifically to accomodate representation of
> | 'standardized' commands so that the front-end doesn't have to
> | transform them into byte-ops, and the back-end doesn't have to
> | recognize patterns of byte-ops and optimize them.
> 
> While an SMBbus framework can be built upon an I2C framework, just 
> as a generic I2C framework can be built on the existing i2c_bus bitbang
> operations, the opposite is not true.  SMBus controllers that handle
> complete command sequences are incompatible with I2C.

You should really follow my suggestion, and, for instance, look at the
BCM1250 user manual (which you have under NDA, as I mentioned before).
And also the SMBus spec.

Or, just look at the table I mentioned in the previous:

While there are standardized SMBus commands, devices also implement
operations which are not standardized, and controllers implement
bitbang interfaces to accomodate them.

(Like I believe I said) you still need the bitbang-handling code for
smbus.

But you also can use a smart command interface, and are remiss if you
don't on hardware where it's available.

What you want from a smart controller interface is something like:

	if (standard command implemented in smart controller)
		do it the smart way

	if (byte-oriented command like what your current interface handles
	    && controller does that)
		call a function to drive the byte-banging through the
		    controller.

	call the function which drives the clock and data lines to
		bit-bang it the slow way.

For dumber controllers, you can just jump into one of the latter two.

But if the interface to do the former isn't there to begin with, all
of the back-ends have to rototilled to handle it, when somebody does
the right thing.


BTW, you seem to be creating theories (e.g. the first comment in your
msg, quoted at the top of this one) from thin air without much
knowledge of the facts of the matter...  That reinforces the notion
that, really, you should do some more research in the matter...
	

> | Don't make some poor sucker have to do a whole bunch of extra work
> | re-doing the existing drivers down the road because of
> | shortsightedness now.
>
> If your company wants to contract development of an SMBus, that
> can always be arranged.....

Indeed, it can.


However, I will note that that the NetBSD project's goals don't follow
what a particular company wants implemented, even if that company
happens to be Wasabi Systems or someone who has contracted with them
for support of some particular hardware.

Just because you've written some code for your employer doesn't give
you any right to put it into NetBSD, especially when it's
machine-independent 'subsystem'-ish interface code.  However, that's
what you said was going on here: you'd written it, here was the
description, and you were about to commit it.

The way I see it -- and I really don't think i'll get much
disagreement here -- the NetBSD project's goals include implementing
portable, clean, stable, and performant software interfaces.  They
include sharing code.

You can define the task at hand to be i2c, and ignore SMBus.  But, if
you do, you either exclude an interface which achieves the performance
supported by certain hardware (smart smbus controllers), or exclude
sharing code (separate i2c and smbus layers), or you significantly
increase developer effort in the future -- after a bunch of this code
has been deployed -- because you were too short-sighted to do the
right thing up front (some developer gets to rototill all of the
drivers because you did the wrong thing now.)


And, by the way, if I want to contract development of a piece of code,
I'm going to bloody well do so with a person or organization that
respects the values of the community in which they're developing.

That can take many forms.  In general, it means getting the code back
into the master sources of the project in question while meeting the
community standards for code development.

For instance, for GNU projects like GCC or binutils, that means
getting the code back into the master source trees for the projects,
complying with the coding standards, providing test cases where
appropriate, etc.

In this case, completely ignoring closely-related (compatible,
even!!!) hardware when implementing a driver is, from my personal
vantage point, _not_ meeting NetBSD community standards for code
development.  Doing the same while implementing an interface to be
shared by numerous drivers is even worse.  It's downright
irresponsible.



cgd
--
Not speaking for Broadcom Corporation, of course.