ron minnich wrote:
On Wed, Feb 27, 2008 at 3:28 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
The "multiple SPD" patch is next on my list once I know whether you want to simulate multiple independent SPD EEPROMS (for multiple RAM chips) or multiple related SPD EEPROMS.
Good question!
I think both. One board I at least has soldered-on and DIMMs. So the array might be:
struct dimarray { u8 dimm_address; struct spd_entry *table; int tablesize};
struct valid_spd_devices spd_table = { {0xa0, spd_table_onboard, nelem(spd_table_onboard)}, {0xa1, NULL,}, {0,0}};
Note that if we go to a generic function we need to have the size in the struct.
This starts to raise the question: is the generic function more trouble that it is worth? I am now beginning to think so. What if the second DIMM is an spd device? There are lots of variations possible, and it may just be simpler not to get too fancy.
ron
There are platforms with soldered-on and a dimm slot. That and the smbus addressing switching in k8 is why it is in mainboard.
As for the SPD in the dts (which I assume means in the statictree), I don't think so but for very minor reasons. It would take up a bunch of space in the statictree when it is only needed by initram. It would also be more convoluted to access it in the statictree. If someone has a good reason, I could be convinced that it should go in the dts.
Marc