Eeprom driver optimization

Philip Pokorny ppokorny at penguincomputing.com
Sun Aug 17 06:37:57 CEST 2003


I would suggest that the chance of eeprom contents changing during normal 
running is *very* small.

Therefore, you could set the refresh time to be *very* long by default (and 
make it configurable if the VAIO BIOS is changing the eeprom underneath us. 
Gosh I hope not...)  Say 10 minutes or more.  Then read the contents once, and 
cache the results.

An alternative would be to just divide the eeprom into 16-byte subsets and 
assign a refresh timer to each.  This matches the /proc organization pretty 
well. (16 bytes per file)

But since sysfs is coming soon and Greg KH's proposal is a single binary file 
for eeprom's, I think my first suggestion is better for the future...

:v)

Jean Delvare wrote:

> 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.
> 
> 




More information about the lm-sensors mailing list