On Thu, Feb 20, 2014 at 8:42 AM, Luck, Tony <tony.l...@intel.com> wrote: >> 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 :) > > Yes - we have people looking at pmfs and NV-DIMMs. I don't know > the internal details ... to keep these accesses safe may require letting > the platform BIOS code perform them (via some ACPI thingy) ... messy > and slow - but probably workable if these registers are only required > for some maintenance/configuration usage patterns. Not so good if > they are in the high frequency read/write path (but I2C in the critical > path sounds like a recipe for failure).
As far as I know, they're not involved in reads and writes, but they are useful periodically to keep everything happy. I suppose that *shudder* calling an ACPI method to initiate an i2c transaction aimed at a DIMM slot isn't *that* bad. On the other hand, if we're supposed to issue an ACPI call to ask "is it okay to start using this device now", then won't we need to reflash firmware every time we switch NV-DIMM vendors? Ugh! In any case, let's hold off on merging this until Intel and/or the ACPI people figure out what's going on. This driver is IMO not worth it just to access SPD and TSOD. (Actually, I think I could write a separate TSOD driver that just asks the memory controller to report cached temperature values. That should be almost entirely non-scary.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
