On 6/3/08, Trent Piepho <[EMAIL PROTECTED]> wrote: > On Tue, 3 Jun 2008, Jon Smirl wrote: > > > > drivers/i2c/busses/i2c-elektor.c | 2 +- > > > > drivers/i2c/busses/i2c-gpio.c | 2 +- > > > > drivers/i2c/busses/i2c-i801.c | 2 +- > > > > drivers/i2c/busses/i2c-ibm_iic.c | 4 ++-- > > > > drivers/i2c/busses/i2c-iop3xx.c | 2 +- > > > > drivers/i2c/busses/i2c-isch.c | 2 +- > > > > drivers/i2c/busses/i2c-mpc.c | 2 +- > > > > Freescale embedded, no sticks > > > I know you're wrong about this one, because I have a Freescale board with > an mpc i2c adapter with SPD SODIMMs on the I2C bus sitting right in front > of me. The whole reason I added hexdump support the I2C tools' SPD parser > was so I could parse the SPD data by hexdumping the eeproms with busybox.
Which CPU are you using? Maybe we should change to a socket. > Using SPD with embedded boards isn't uncommon. It's much easier to design > a board with a SO-DIMM slot than actual chips. In small quantities at > least, it's cheaper too. Using SPD is much more flexiable when you want to > change memory size or speed, even if the memory isn't socketed. If you > look at U-Boot, most platforms are using SPD for DRAM controller setup and > not hard coded values. > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
