From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 28 Nov 2006 13:25:07 -0500 Subject: [U-Boot-Users] Please pull u-boot-83xx.git (I2C rework) In-Reply-To: <1164737878.31193.38.camel@saruman.qstreams.net> References: <456C7A18.1090309@freescale.com> <1164737878.31193.38.camel@saruman.qstreams.net> Message-ID: <456C7F03.9060409@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Ben Warren wrote: > On Tue, 2006-11-28 at 12:04 -0600, Timur Tabi wrote: >> Joakim Tjernlund wrote: >> >>> I think that the I2C_READ and I2C_WRITE #defines in fsl_i2c.h conflicts >>> with >>> soft I2C. >> Can you be more specific? These two macros are defined in a variety of ways in >> U-Boot. Soft I2C is not used on any Freescale parts (AFAIK). >> > While it's not used on any Freescale evaluation boards, it could > certainly be implemented on boards with Freescale CPUs. I'm not sure > why you'd bit-bang I2C if you have nice hardware controllers, but there > may be situations where this makes sense. On the other hand, I don't > know if SOFT_I2C and HARD_I2C can co-exist. > > Either way, I don't think we should preclude the use of SOFT I2C on > Freescale CPUs. > > regards, > Ben It is used on some boards with Mot/Freescale CPUs, the WindRiver (EST) SBC8260 for example (although configurable hard vs. soft IIRC). The hardware i2c can be more effort than it is worth compared to bit-banging it. Perhaps the new QUICCs are easier to use, perhaps y'all are just smarter than we were back then. :-) gvb