Eeprom driver optimization

Jean Delvare khali at linux-fr.org
Sat Aug 16 14:13:51 CEST 2003


Hi all,

As I was working on the eeprom driver, one thing came to my mind. If
should be possible to significantly speed the eeprom module up. As it is
now, requesting one single byte from the eeprom cause the whole eeprom
(256 bytes) to be read. Of course, we don't want to refresh bytes
one-by-one, it would be too complex. But maybe we could define subsets
of bytes that should be refreshed at once. In a way, this joins a
previous discussion about driver design
(http://archives.andrew.net.au/lm-sensors/msg03657.html). Philip Pokorny
already did something similar in the adm1026 driver, introducing a
second refresh frequency for limits, as opposed to measured values.
Still there is a single update function in the adm1026 driver, and this
too could be discussed. And a general discussion about these policies
would be welcome for sensor drivers.

But let's stick to the eeprom module for now (my train leaves in less
than 3 hours now so I'm a bit short in time).

When sensors is called for regular memory eeproms, the rows that will be
accessed (to return the memory type and the memory size) are 1 and 2
(counting rows from 1 to 16). When called for a Sony Vaio EEPROM, it
will read rows 9, 13 and 14. For an EDID it will read rows 1 and 9 (but
this could be changed to row 1 only). Likewise, running the
decode-eeprom, decode-vaio and decode-edid scripts will only access
subsets of the eeprom. At the very least, I believe we should divide the
eeprom in two subsets: rows 1-2 and rows 3-16. That would make sensors
far faster on memory eeproms. Additionally, I think I remember these
eeproms are usually 64-byte or 128-byte long (EDIDs are), only the
Vaio's are 256-byte long. So we could define 4 subsets instead: rows
1-2, rows 3-4, rows 5-8 and rows 9-16. I believe that this would speed
up sensors and scripts much. This would require to add separated refresh
timers, but I think it's worth it.

I don't know if it's worth it defining more complex subsets. For example
we could define a subset for the 5 bytes used by sensors for memory
eeproms. This would make things even faster, but OTOH too many subsets
will be difficult to optimize, especially if more and more eeprom types
appear (I think I remember see many unknown eeproms in user reports
these last months).

I'll try this while in the train, but I still would like to hear
opinions about this.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/



More information about the lm-sensors mailing list