Hi,
the two config variables SMBUS_MEM_DEVICE_START and SMBUS_MEM_DEVICE_END are only used by ./src/sdram/generic_dump_spd.c.
Does it make sense to keep those? dump_spd_registers() could use the ram_controller struct to get the values. Then I would remove SMBUS_MEM_DEVICE_[START|END] occurences in the code.
Stefan
On Mon, 6 Oct 2003, Stefan Reinauer wrote:
the two config variables SMBUS_MEM_DEVICE_START and SMBUS_MEM_DEVICE_END are only used by ./src/sdram/generic_dump_spd.c.
Kill 'em1
Does it make sense to keep those? dump_spd_registers() could use the ram_controller struct to get the values. Then I would remove SMBUS_MEM_DEVICE_[START|END] occurences in the code.
yeah, good idea.
ron
* ron minnich rminnich@lanl.gov [031006 17:24]:
On Mon, 6 Oct 2003, Stefan Reinauer wrote:
the two config variables SMBUS_MEM_DEVICE_START and SMBUS_MEM_DEVICE_END are only used by ./src/sdram/generic_dump_spd.c.
Kill 'em1
They're gone. generic_dump_spd.c seems to be duplicate in every opteron board's debug.c file. I used the opteron version, but replaced smbus_read_byte by spd_read_byte since some motherboards might need additional ops to access spd. Since the code in ./src/sdram/generic_dump_spd.c is not used at all currently, it might stay there getting used, or rather go away. Where's a good place for the functions from the motherboards' debug.c? Those seem to be pretty much the same across the different supported boards.
Stefan
-
ron minnich -
Stefan Reinauer