On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony <tony.luck@xxxxxxxxx> wrote: >> (I'm c/c Tony here, as he also shared the same concern that I had on a >> previous feedback about using I2C to talk with the DIMM). > > Correct - I've heard the same issues that reads on I2C can be misinterpreted > as writes ... and oops, you have a brick. Is this true on DDR3 DIMMs, i.e. anything that's compatible with LGA2011? If you plug a DIMM into an LGA2011 board's memory slot, then, one way or another, it's very likely that there will be TSOD traffic, if for no other purpose than to determine that there is no TSOD present. TSOD traffic consists of reads and writes, both with and without register numbers. (Sorry, I can never remember the smbus terminology here -- the relevant transactions are two-byte reads and two-byte writes, both with a command specified and without one. One of the bits in the iMC SMBUS registers tells the controller which kind of read to use to probe the thermometer.) > > What is the larger context/ What problem are we trying to solve? NV-DIMM control registers are exposed via i2c, presumably because trying to access them through the memory pins would be a giant mess. So, one way or another, something needs to be able to initiate transactions to access those registers. BIOS will do some initial setup, but the OS will need to poke at these registers, too. (The actual docs are covered by NDA. I suspect that this will change if the manufacturers ever want these things to be widely used, though, since these things really want a full-featured kernel driver so that things like pmfs will work cleanly.) As a secondary benefit, having access to the TSOD and SPD is nice, albeit far from critical. AFAICT Intel actively working on NV-DIMM-related things, so maybe Intel will contribute an engineer who help :) --Andy > > -Tony -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
